Сегодня у меня внезапно возникли проблемы с MySQL.
Подробности:
Шаги, которые я выполнил для диагностики:
Например:
UPDATE `catalogsearch_query` SET `query_text` = 'EW 90', `num_results` = '7532', `popularity` = '99180', `redirect` = NULL, `synonym_for` = NULL, `store_id` = '1', `display_in_terms` = '1', `is_active` = '1', `is_processed` = '1', `updated_at` = '2012-05-08 21:38:31' WHERE (query_id='31');
Один раз для выполнения этого запроса потребовалось 17 секунд, в остальное время около 0,079 секунды. Но варьируется, иногда 1 секунда, иногда 0,004 секунды. Он запускает один и тот же запрос снова и снова с интервалом в пару секунд между каждым.
Большинство таблиц являются innodb, и иногда я замечал, что время блокировки занимает 90% времени выполнения запроса, но большую часть времени блокировки времени несущественно.
Есть идеи, что здесь происходит?
Звучит почти определенно как периферийная проблема, влияющая на то, что происходит, и довольно типично для запуска Magento в ограниченной и конфликтной среде, такой как VPS.
Если ваша конфигурация ранее работала хорошо, и вы не меняли код или не устанавливали какие-либо расширения - тогда это будет внешнее влияние, скорее всего, увеличение трафика - но с VPS это, скорее всего, увеличение активности ввода-вывода. .
Это похоже на ожидание ввода-вывода - простая установка графического инструмента, такого как Munin, убедительно докажет это (показывая корреляцию в MySQL медленных запросов с активностью / ожиданием ввода-вывода).
Я буду ссылаться на несколько других сообщений о том же самом напрасном - поскольку запуск Magento на VPS всегда приводит к аналогичному поведению.
Что значит :
SHOW CREATE TABLE catalogsearch_query\G
SHOW INNODB STATUS;
SELECT * FROM information_schema.PROCESSLIST WHERE State='Locked' ORDER BY Time;
выглядит как ?
Я подозреваю, что вы столкнулись с проблемой зависания «столов открытия / закрытия». Я бы не стал слишком часто перезагружать вашу БД, ей нужно время, чтобы разогреться, особенно при большом количестве обновлений.
Для полноты картины мне тоже хотелось бы это увидеть:
SHOW STATUS LIKE '%cache%';
SHOW STATUS LIKE '%table%';
И все это в трудную минуту, я готов поспорить, что когда вы в беде и будете делать «флеш-столы»; , это займет много времени.
Несколько важных параметров конфигурации, которые ускорят обработку:
innodb_log_buffer_size = 16M
innodb_file_per_table = 1
innodb_open_files = 16000
innodb_io_capacity = 400
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_thread_concurrency=8
innodb_lock_wait_timeout = 90
Имейте в виду, что это происходит из MariaDB, поэтому mysql на стероидах. (XtraDB) В частности, настройка per_table радикальна, но повлияет только на новые таблицы, вам нужно будет воссоздать таблицы проблем, если вы хотите, чтобы они были в их собственном innodb . Это вместе с методом очистки O_DIRECT и trx_commit = 2 (сначала прочтите об этом!) Значительно ускорит процесс, особенно с большими обновлениями / вставками.
Надеюсь это поможет.
Две наиболее вероятные проблемы:
1) ваш запрос блокируется другим - проверьте журнал медленных запросов, что было запущено, когда вы начали обновление
2) ваша виртуальная машина не расписывается на хост-машине. Настройте сторожевой таймер для записи пульса в файл журнала.
Могут быть и другие причины, но если вы не устраните две из перечисленных выше, нет смысла их обсуждать.
Что касается решения проблем, первое - это просто вопрос настройки запроса, для второго вам нужно будет поговорить с тем, кто управляет хост-машиной.