Почему потоки MySQL часто показывают состояние «освобождение элементов», когда кеш запросов отключен?

Когда я бегу SHOW PROCESSLIST, часто бывает много потоков INSERT / UPDATE в состоянии «освобождение элементов».

В руководстве по MySQL предполагается, что, по крайней мере, одна из причин, по которой поток находится в этом состоянии, связана с кэшем запросов - вероятно, это приведет к аннулированию кэшированных запросов из-за измененных данных.

Однако my query_cache_sizeимеет значение 0, что должно полностью отключить кэш запросов.

Какие еще причины могут иметь столько потоков в этом состоянии?

В соответствующих таблицах используется механизм хранения InnoDB.

Проверьте значение innodb_thread_concurrency.

Для моей системы увеличение значения с 8 до 32, согласно рекомендациям в документации MySql , привело к заметному уменьшению числа потоков, одновременно сообщающих о состоянии «освобождения элементов». Кроме того, среднее время запроса уменьшилось на порядок.

Несмотря на то, что это сильно повлияло на общую производительность сервера, это была не серебряная пуля «освобождения предметов». Моя аппаратная экосистема заставляет меня предположить, что это состояние чаще всего наблюдается в системах с «медленными» дисками (2x10k дисков, raid 1) и менее распространено в системах с более быстрым хранилищем (12x15k дисков raid 10). Таким образом, проверка производительности диска также может быть оправдана.

Удачи!

Также:

Стоит отметить, что значение по умолчанию innodb_thread_concurrency радикально отличается в зависимости от того, какой выпуск версии 5.0 используется.

Значение по умолчанию менялось несколько раз: 8 до MySQL 5.0.8, 20 (бесконечный) с 5.0.8 до 5.0.18, 0 (бесконечный) с 5.0.19 до 5.0.20 и 8 (конечный) с 5.0.21 на. - источник

Это означает, что, казалось бы, безобидное обновление с 5.0.20 до 5.0.21 изменило значение по умолчанию с бесконечного на 8 и привело к снижению производительности.

Освобождение элементов - это этап выполнения запроса, на котором освобождаются временные структуры, буферы и т. Д. На этом этапе выполняется некоторая работа с кешем запросов, но это не единственное, что там происходит. Я бы предложил использовать SHOW PROFILES, чтобы увидеть, сколько времени занимает этот этап по сравнению с другими этапами, и если время, затрачиваемое на это, заканчивается, устранение неполадок с помощью таких инструментов, как профилировщик и oprofile.

По этой проблеме было сообщение об ошибке, касающейся «освобождения элементов» и кеша запросов . Хотя ошибка закрыта, упоминания о innodb_thread_concurrency не было .

По случайному совпадению я разговаривал с Рональдом Брэдфордом в Percona Live NYC еще в мае. Я рассказал ему о ситуации, когда я настроил innodb_thread_concurrency, потому что множественный буферный пул InnoDB в MySQL 5.5 вызвал тонны блокировки потоков, и я подозревал, что кэшированные данные, которые мне нужны, скорее всего, распространились среди нескольких буферных пулов.

Он прямо сказал мне, что я никогда не должен устанавливать значения против innodb_thread_concurrency. Пусть это всегда будет значением по умолчанию, которое теперь равно нулю (0). Тем самым вы позволяете хранилищу InnoDB решать, сколько innodb_concurrency_tickets сгенерировать самостоятельно. Это то, что делает бесконечный параллелизм.

Скорее всего, «освобождение элементов» происходит чаще, когда мы накладываем ограничения на innodb_thread_concurrency. Это всегда должно быть ноль (0). Я бы рискнул и поднял innodb_concurrency_tickets и посмотрел, помогает это или нет.

У нас была проблема с точно такими же симптомами. Оказалось, что диск с файлами журналов InnoDB заполнен. Стоит проверить.

Еще один совет: это может быть innodb fsync (). Попробуйте установить

innodb_flush_log_at_trx_commit = 2

В my.cnf

Лог-файл innodb затем сбрасывается на диск каждые 1-2 секунды, вместо этого ob при каждом коммите. Небольшое нарушение целостности данных, большой выигрыш в скорости.