Самостоятельно решил.
Таким образом, я понял, что пытался использовать connect_xtrace=1023, но установил его как глобальную переменную и не установил как переменную сеанса, поэтому его эффект не был немедленным. После установки его в качестве переменной сеанса удалось отследить его до сбоя выделения памяти.
После использования таблиц JDBC механизма CONNECT для извлечения данных за день или 2 ошибка при выборе из внешней таблицы JDBC механизма хранения CONNECT: «ОШИБКА 1296 (HY000): получена ошибка 122 «Не удается получить сообщение об ошибке» из CONNECT».. ... и ошибка при попытке создать внешнюю таблицу JDBC механизма хранения CONNECT: «ОШИБКА 1030 (HY000): ошибка 122 «Внутренняя (неуказанная) ошибка в обработчике» от механизма хранения CONNECT»
Недавно я заметил, что в mysqld.log появилось несколько следующих строк: Рабочая область: Ошибка выделения памяти: malloc вернул Null
Итак, снова попытался устранить неполадки...
Возможно, я ранее использовал set global connect_xtrace=1023; который изменяет настройки только для глобального, но не для текущего сеанса. Следовательно, на этот раз вместо этого попытались установить сеанс connect_xtrace=1023, и соответствующие записи в журнале начали появляться ниже.
Таким образом, ключевым моментом было установить connect_xtrace=1023 для сеанса. Виноват.
Во всяком случае, записи mysqld.log теперь содержат больше информации: ... New CONNECT 0x7fc46403de80, таблица: mssql_CURRENCY_RATE open: name=./_TMP_D/mssql_CURRENCY_RATE mode=2 test=18 PlugInit: Language='Null' SareaAlloc: Ошибка выделения памяти: malloc возвращен Null Удалить CONNECT 0x7fc46403de80, таблица: mssql_CURRENCY_RATE, xp=(nil) count=0 ... PlugInit: Language='Null' SareaAlloc: Ошибка выделения памяти: malloc вернул Null New CONNECT 0x7fc46403de80, таблица: mssql_CURRENCY_RATE open: name=./ _TMP_D/mssql_CURRENCY_RATE режим=2 тест=18 ...
Поэтому попытался установить гораздо меньшее значение connect_work_size: 64 МБ (по умолчанию), и все снова заработало! Нет больше ошибок.
Таким образом, вывод, который может показаться, заключается в том, что механизм CONNECT перестал быть в состоянии выделять на основе connect_work_size через некоторое время, поскольку mysqld и ОС со временем использовали все больше и больше памяти.
Затем попытался установить connect_work_size на 1 ГБ и снова попытался выбрать, все еще работает. Увеличил еще 1 ГБ и снова выбрал, повторив еще несколько раз. Начал замечать из mysqld.log, что набор памяти для connect_work_size перестает отслеживаться через некоторое время, и используется последнее успешное значение. (это похоже на документацию).
Поскольку я не встречал более подробного руководства о том, сколько установить connect_work_size, создал хранимую процедуру, которую я буду вызывать для установки connect_work_size непосредственно перед использованием механизма CONNECT, попробуйте размер, который я хочу, затем попробуйте модуль CONNECT, если не удается, попробуйте меньшего размера и попробуйте ПОДКЛЮЧИТЬ двигатель, если не получится, повторяйте, пока все не заработает.
Было бы здорово, если бы: а) connect_work_size был реализован аналогично: innodb_buffer_pool_instances, innodb_buffer_pool_chunk_size, innodb_buffer_pool_size б) было бы неплохо иметь что-то вроде connect_work_size_guaranteed, который мог бы быть объемом выделенной, но никогда не освобождаемой памяти, чтобы иметь минимальную гарантию память для плагина. в) иметь более подробную документацию; т. е.: если примерный размер строки таблицы равен xxx, а строки, запрашиваемые в памяти в любой момент времени, равны yyy, то connect_work_size должен быть (xxx * yyy) * 1.1.
person
Chan Kar Heng
schedule
17.04.2020
