Подтвердить что ты не робот

В MySQL указано множество "Query End", все соединения, используемые в считанные минуты

Сегодня утром я заметил, что наша загрузка MySQL-сервера идет высоко. Макс должен быть 8, но он поражает более 100 в одной точке. Когда я проверил список процессов, я обнаружил множество запросов обновления (простых, увеличив "hitcounter" ), которые находились в состоянии query end. Мы не могли убить их (ну, можно, но они остались в состоянии killed неопределенно), и наш сайт остановился.

У нас было много проблем с перезагрузкой службы и пришлось принудительно убить некоторые процессы. Когда мы это сделали, нам удалось вернуть MySQLd, но процессы начали быстро расти. Насколько нам известно, на данный момент никакая конфигурация не была изменена.

Итак, мы изменили innodb_flush_log_at_trx_commit с 2 на 1 (обратите внимание, что нам необходимо соответствие ACID) в надежде, что это решит проблему и установит связи в PHP/PDO, чтобы они были постоянными. Кажется, что это работает около часа или около того, а затем соединения снова начали работать.

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

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

Помощь!:)

4b9b3361

Ответ 1

Я отвечу на свой вопрос здесь. Я проверил размеры раздела с помощью простой команды df, и я мог видеть, что /var на 100% заполнен. Я нашел архив, который кто-то оставил, размером 10 ГБ. Удалив это, запустил MySQL, выполнил запрос PURGE LOGS BEFORE '2012-10-01 00:00:00', чтобы очистить загрузку пространства и уменьшить размер каталога /var/lib/mysql с 346 до 169 ГБ. Отправлено назад к мастеру, и все снова работает отлично.

Из этого я узнал, что наши файлы журналов становятся ОЧЕНЬ большими, ОЧЕНЬ быстро. Поэтому я буду устанавливать процедуру обслуживания, чтобы не только сохранить файлы журнала, но и предупредить меня, когда мы приближаемся к полному разделу.

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

Ответ 2

У нас была очень похожая проблема, в которой процессный список mysql показал, что почти все наши соединения застряли в состоянии "конец запроса". Наша проблема также была связана с репликацией и написанием binlog.

Мы изменили переменную sync_binlog от 1 до 0, что означает, что вместо того, чтобы сбрасывать binlog на диск на каждой фиксации, он позволяет операционной системе решать, когда fsync() в binlog. Это полностью разрешило проблему "конец запроса" для нас.

Согласно этот пост от Mats Kindahl, запись в binlog не будет такой же проблемой в версии 5.6 MySQL.

Ответ 3

В моем случае это указывало на максимальную отдачу ввода-вывода на диске. Я уже сократил fsyncs до минимума, так что это было не так. Другими признаками являются файлы "log *.tokulog *", которые начинают накапливаться, потому что система не может догнать все записи.