MySQL замедляется / замедляется при большой нагрузке

Лично я считаю, что некоторые из этих значений вышли из строя, но это не должно вызывать сбоев.

http://blog.mysqltuner.com/ есть сценарий, который может дать вам некоторые подсказки по настройке, хотя они предполагают, что сервер работает более 48 часов.

Когда вы говорите сбой, вы имеете в виду, что mysqld завершает работу или не отвечает? Система не отвечает или просто mysql? проверьте dmesg, / var / log / messages, дампы ядра и т. д. За исключением проблем с оборудованием, мы предполагаем, что mysql блокируется. Вы не упоминаете время безотказной работы для этих значений выше или версию mysql, которую вы используете, но мы предполагаем относительно короткое время безотказной работы. Таблицы tmp, созданные на диске, могут означать, что размер вашей временной таблицы слишком мал или у вас есть запросы, которые нельзя кэшировать в памяти.

Первое, что я вижу, это table_cache ниже открытых таблиц. Это не обязательно серьезная проблема, но может вызвать большой отток. показывать статус как 'open_tables'; Если это ограничено вашим table_cache, вы можете увеличить table_cache.

Если у вас относительно последняя версия mysql, /var/lib/mysql/hostname.err или /var/log/mysql/mysql.err может содержать некоторую дополнительную информацию. Если вы можете выполнить 'show processlist' во время события или mysqladmin -u root -ppassword processlist> / var / tmp / pl (в некоторую область, которая не очищается при перезагрузке, если ваш сервер необходимо перезагрузить), вы можете иметь возможность проверить, что происходит при аварии. Как насчет журнала медленных запросов mysql? Longquery на 1 может создать массу дополнительных журналов, но, если вы обнаружите, что запросы, занимающие более 300 секунд, должны занять 4 секунды, у вас может быть указание на то, какая таблица зависает.

InnoDB - не лекарство от всего, что вас беспокоит. Программисты, которые не понимают mysql, будут использовать InnoDB, потому что он использует блокировку на уровне строк, а не на уровне таблицы. Заблокируйте меньшую часть таблицы, и вы увидите рост параллелизма. Теория верна, но вещи, которые вы делаете с InnoDB, работают не так, как с MyISAM.

select count(*) from innodbtable where condition='asdf';
select count(*) from myisamtable where condition='asdf';

В первом случае InnoDB заблокирует таблицу и выполнит полное сканирование. Во втором случае MyISAM не будет блокировать таблицу (и ответит из индекса, если условие содержится в индексе).

select count(varname) from table where condition='asdf';

Если имя переменной не является ключом, это заставит сканирование таблицы убедиться, что имя переменной не равно нулю. Если varname является ключом, он все равно проверяет все значения ключей, чтобы убедиться, что они равны нулю.

При выборе таблицы, содержащей текстовое поле, автоматически создается временная таблица диска - вы можете изменить запросы, чтобы этого избежать.

Если вы можете опубликовать немного больше информации о запущенном приложении, о том, что вы имеете в виду под сбоем, выводе из показа переменных / статуса показа, содержимом журналов ошибок и т. Д., Я уверен, что кто-то здесь с немного большими знаниями сможет отладить это дальше.

Я предполагаю, что вы перезапустили сервер с перезагрузкой / включением. В вашем каталоге / var / lib / mysql должно быть несколько файлов, например:

ibdata1
ib_logfile0
ib_logfile1

Я предполагаю, что один из этих файлов содержит неверные данные.

Вы можете перезапустить mysql с innodb_force_recovery = 4 в разделе [mysqld], чтобы увидеть, можно ли восстановить файл innodb. Если нет, загрузите одну из ваших горячих копий или недавних дампов. Возможно, вам не удастся удалить эту таблицу без какой-либо магии, но вы должны иметь возможность переименовать таблицу и повторно импортировать из ваших резервных копий.