Назад | Перейти на главную страницу

Поток MySQL застревает в конечном состоянии

Один из наших главных производственных серверов репликации показывает действительно странное поведение, для которого я не могу найти решения.

Некоторые потоки на этом сервере застревают в состоянии «конец». Это происходит чисто случайно, но когда это происходит, поток всегда обновляет или вставляет строки в таблицу. Таблицы, в которых выполняется запрос, различаются, но всегда находятся в таблицах MyISAM и в диапазоне трех разных таблиц.

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

Веб-серверы продолжают ставить запросы к серверу базы данных, не получая ответа. Это в конечном итоге приводит к тому, что на веб-серверах заканчиваются сокеты. В этот момент все запросы к доменам отклоняются. Серверы баз данных не показывают операций ввода-вывода или процессора, пока поток находится в состоянии «конец». Когда возникает эта проблема, я должен убить поток вручную. Даже это не делает ничего другого, кроме как изменить статус команды на «убит». Большинство потоков исчезают примерно через 100 секунд.

Таблицы, в которых потоки выполняют запросы, когда они переходят в конечное состояние, различаются по размеру, но составляют от 20 до 100 МБ. В настоящий момент, когда возникает эта проблема, эти таблицы часто обновляются, но не очень сильно. Я думаю, что обновления варьируются от 3 до 10 в секунду.

Некоторые характеристики сервера. ОС - CentOS 5.4 с MySQL 5.0.77-log. Процессор - AMD Opteron 2378, жесткие диски - массив RAID 1 + 0 SSD Corsair X32 32 ГБ.

Я думаю, что SSD может быть частью причины проблемы, но я не могу найти никаких данных, подтверждающих это. Какое-то время диски работали довольно стабильно.

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

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

Мне не удалось воспроизвести проблему с некоторыми из моих тестовых скриптов. При чтении, записи и обновлении таблиц, вызывающих серьезные проблемы, проблема не возникает. Возникновение этой проблемы чисто случайное.

После дальнейшего расследования выяснилось, что проблема была вызвана кешем запросов. Из-за большого размера кеша запросов MySQL, кажется, запутывается при очистке кеша. Уменьшение кеша запросов с нескольких ГБ до примерно 512 МБ решило проблему. Подробную информацию см .: http://bugs.mysql.com/bug.php?id=39091