Как посмотреть список запросов MySQL во время «Too many connections»?

mysqladmin цепляется на общих основаниях и поэтому при заполнении очереди запросов присоединится не может.

Всякие slowlog не помощник, потому что когда забивается очередь на 500 коннектов, то лог потом забит тысячами запросов, найти виновника там нереально. Да и задача найти не виновника, а в том числе и откуда лезут эти 500 коннектов.

После прочихивания очередь выполняется за секунды, так что поймать после ухода тяжёлого запроса что там за ним тоже почти нереально.

даже через сокет-фаил не коннектится?

Да. Ограничение на число соединений — общее.

может если мониторить через mtop , mytop то получится вичислить?

Нет, они при переполнении по числу соединений точно также отваливаются и не позволяют присоединиться, пока очередь освободится.

1) у slowlog есть настройка - на сколько именно слоу: там можно увеличивать время в секундах. Ты увеличивай потихоньку. Их там в результате обозримое кол во останется, ибо они попадают в очередь ведь и висят. Большинство исчезнет начиная с какого то лимита.

2) там ситуация какая: один запрос делает что то и блокирует остальные. Поэтому там и 500 коннектов утебя висит. Вроде бы там в слоу логе есть стейт (или мне изменяет память)? тебе нужен не тот который локед или вейтинг (я уже не помню за давностью лет), а тот который что то реально делает.

я в подобной ситуации либо подбирал таймаут для слоулог и глядел что там, либо просто коннектился phpmyadmin-ом (надо успеть до полной жопы) и глядел запрос который в состоянии «работают» а не «жду своей очереди».

у slowlog есть настройка - на сколько именно слоу

Я же писал, не поможет. Скажем, поставлю 10 секунд. Появится проблемный запрос например, на 20 секунд. Через 20.3 секунды он срубится. За ним в очередь запишутся запросы в 20.29, 20.28, 20.27. И так 1000 штук :) К сожалению, slow срабатывает только по общему времени обработки запроса, включая ожидание, а не одно только время обработки запроса.

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

Нет инструмента, который позволит это в нормальном виде разобрать. И просто отгрепать не получится, потому что лог многострочный.

Через 20.3 секунды он срубится. За ним в очередь запишутся запросы в 20.29, 20.28, 20.27. И так 1000 штук :)

ну так то так, но, у тебя ведь 500 коннекшинов то, откуда там 1000 запросов? :)

Так то оно так, но 500 запросов можно и проглядеть глазами на крайний случай. И они ведь всё таки в порядке логятся, вероятно. Гляди сверху вниз. Там обычно глазами хорошо видно что можно отсеивать. За час имхо реально проглядеть. Обычно он где то в начале всё таки, на сколько помню, поэтому там минут 5 не уходило у меня. Хотя лог был большой.

Только не забудь включить и те запросы которые индексы не используют. Мне кажется иногда можно время из за этого потратить.

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

А сколько клиентов ? Если зайти с другой стороны и посмотреть trafshow каким-нибудь ? Но это если он на sending data висит каком-нибудь. Или просто клиентом mysql зацепиться заранее.

да, кстати, а если, например, по ssh с консольки зайти с помощью mysql и оставить это дело висеть (в screen например)? соединение ведь живое будет и ты сможешь запросы выполнять.

ну так то так, но, у тебя ведь 500 коннекшинов то, откуда там 1000 запросов? :)

Уже 1000 коннекшнов :) При чём, что забавно, max_user_connections = 200 (в надежде, что root'у достанется), но уши те же. При чём в логах в основном попадается превышение max_connections, и очень редко — max_user_connections.

Так то оно так, но 500 запросов можно и проглядеть глазами на крайний случай.

В том-то и дело, что там блокирующих запросов куча, но они не должны блокировать всех.

Проблема ещё в том, что там 40 баз данных, 1900 таблиц и два десятка юзеров из десятка толстых проектов. Поэтому и сложно сыскать концы, не имея возможности посмотреть processlist в момент затыка.

да, кстати, а если, например, по ssh с консольки зайти с помощью mysql и оставить это дело висеть (в screen например)? соединение ведь живое будет и ты сможешь запросы выполнять

Сбрасывается оно по таймауту ожидания. А без таймаута нельзя, так как при большом числе клиентов кто-то нет-нет, да не закроет соединений, и все соединения понемногу заполняются Sleep'ами.

Сбрасывается оно по таймауту ожидания.

Сам не пробовал никогда, но подумалось, что screen должен уметь вовнутрь передать что-то. Почитал - вроде может. Но почитал бегло, может и ошибся. Если может, делай в него show processlist по крону.

отключать проекты (юзеров) по очереди если быстро проблема появляется, то и быстро юзер обнаружится. перевести на TCP сокеты и посмотреть tcpdump. какой нить proxy на сокет повевсить с логированием

Запили скрипт который будет держать коннект и делать show processlist каждые 25 секунд и дампить в файл. Как затык случится - найдёшь виновника.

Репликацию и бэкапы исключил?

отключать проекты (юзеров) по очередиесли быстро проблема появляется

В том-то и проблема, что проекты важные, коммерческие, затыки бывают относительно не часто. Вчера вылезали несколько раз в час, но я оптимизировал несколько тяжёлых запросов, которые отловил по другим признакам и теперь проблема вылезает раз в несколько часов.

Запили скрипт который будет держать коннект и делать show processlist каждые 25 секунд и дампить в файл

Да, так и сделаю.

Угу, репликация отключена вообще, бэкапы делаются по ночам.

Повесить в screen что-то по типу

Была какая-то поделка проксирующая через себя все запросы к мускулю. Абсолютно прозрачно для клиентов. Какраз для сбора статистики и отлову медленных. Такой себе мускульный фаербаг. Помню на швабре даже статья была. Но не помню как называется. Я даже палочкой её тыкал один раз, но оно мне не понадобилось.

Короче вбил я в гугл «проксирование mysql site:habrahabr.ru» а там их уже море, выбирай короче сам какой понравится и подойдет.

mysqladmin явно умеет коннектиться под каким то определенным пользователем?

Посмотреть у кого привилегии:

Собственно одно из достоинств такого суперпользователя:

Enables you to connect (once) even if the connection limit controlled by the max_connections system variable is reached.

Я думаю. самый логичный способ создать пользователя и пользуйтесь mysqladmin'ом дальше на здоровье.

max_user_connections выставлено меньше, чем max_connections. На время тестов — значительно меньше (300 из 1500). Не помогало.

Сейчас, увы, ловить проблему стало гораздо сложнее, поскольку систему соптимизировал и затыки теперь проходят раз в несколько часов. И длятся секунды.

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

Ты читать не умеешь или не обучаемый в принципе? Написали ведь про трассировщики, для них и миллисекунды не проблема, можно обозначить диапазоны продолжительности выполнения запроса которые будут записываться и ещё 100500 условий, чтобы сократить список. конкретно в том скрипте будут записи вида:

попробуй поснифить тем же tcpdump с флагом -s 0 и потом анализируй файл записи потом в wireshark

попробуй поснифить тем же tcpdump

день ото дня не легче, всё матёрей и матёрей советчики, один прокси поднять, другой предлагает дампить архаичные данные каждые 25 секунд, теперь вот tcpdump, осталось дождаться предложений о hexdump и закрыть тред за ненадобностью.

это я как вариант предложил, а так в качестве прокси можно посмотреть в сторону greensql

можно посмотреть в сторону greensql

но зойчем. всё это элементарно решается использованием трассировщиков без остановки и перенастройки процесса, см коммент выше.

📎📎📎📎📎📎📎📎📎📎