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

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

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

может если мониторить через 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 что-то по типу

#!/usr/sbin/dtrace -s

#pragma D option quiet

dtrace:::BEGIN
{
   printf("%-20s %-20s %-40s %-5s\n", "Who", "Database", "Query", "Time");
}

mysql*:::query-start
{
   self->query = copyinstr(arg0);
   self->connid = arg1;
   self->db    = copyinstr(arg2);
   self->who   = strjoin(copyinstr(arg3),strjoin("@",copyinstr(arg4)));
   self->querystart = walltimestamp;
   printf("%-20s %-20s %-40s %Y\n",self->who,self->db,self->query,self->querystart);
}

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

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

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

вам бы вот это надобно: https://dev.mysql.com/doc/refman/5.5/en/privileges-provided.html#priv_super

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

SELECT user,host FROM mysql.user
WHERE super_priv='Y' AND
CONCAT(user,'@',host) <> 'root@localhost';

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

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 условий, чтобы сократить список. конкретно в том скрипте будут записи вида:

Who                  Database             Query                                    Time
root@localhost                            select * from mysql.user                 2017 Jul 10 14:00:15

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

mysql

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

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

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

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

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

да , я просто вариант предложил