Почему резко поднимается Threads connected при слабом росте нагрузки?

Question

[egoranisimov]

Почему может резко подниматься Threads connected до 4 тысяч (лимит) с 50-100 при слабом росте нагрузки? Почему при слабом росте количества запросов (10-15%) может резко взлетать Threads connected? Мне думается, что сервер упирается в какие-то лимиты диска или подобное, но как это понять, куда стоит смотреть? В логе ошибок mysql в такие моменты ничего не попадет кроме уведомлений Aborted connection .. (Got timeout reading communication packets)

Answer 1

[Vitaly Karasik]

Почему при слабом росте количества запросов (10-15%) может резко взлетать Threads connected?

Кол-во запросов почти не связано с нагрузкой. Достаточно к 100 добавить один тяжелый запрос, и нагрузка подскочит в 10-100 раз.
Поэтому: включите slow query log, потом репорт по нему, читайте и оптимизируйте.

https://www.jeffgeerling.com/blog/2018/analyzing-m...

Comments

[egoranisimov]

Он включен, ничего специфичного в эти моменты туда не попадает.

[Vitaly Karasik]

Мониторинг на уровне линукс поможет, но почти уверен, что в slow query log должно быть что-то заметно.
Если есть мониторинг (типа Zabbix и т.п.) хорошо добавить граф https://dev.mysql.com/doc/refman/8.0/en/server-sta... по моему опыту во всех случаях есть корреляция.

[egoranisimov]

Vitaly Karasik, нет, в том-то и дело что туда запросы не попадают, даже если они медленные. Я сделал обычный тайминг microtime - microtime между запросами, там бывает по 10-40 секунд (лог включён на более 2), и они туда не попадают

[Vitaly Karasik]

нет, в том-то и дело что туда запросы не попадают, даже если они медленные

а что-то в лог попадает? если он совсем пустой, надо пройтись по всем настройкам и починить

(лог включён на более 2),

я бы уменьшил до 0.5 или даже 0.1 секунды

[egoranisimov]

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

[egoranisimov]

Vitaly Karasik, уменьшил, попадают обычные запросы UPDATE `users` SET `points` = `points` + 1 WHERE `id` = 4457143; периодически. В целом есть ещё такая особенность, что этих запросов может быть сотни и тысячи в минуту, но почему именно падение происходит в секунду, а не просто потихоньку всё подвисает и подвисает?

[Vitaly Karasik]

но почему именно падение происходит в секунду

насколько я понял из вопроса, у вас mysql. не падает, просто начинает обрывать новые коннекты т.к. уперся в лимит Threads connected?

А на каком (виртуальном) железе это бежит? Что еще на сервере?
Что говорит

top -b -o +%MEM | head -n 15

[egoranisimov]

Да, обрывает. Странно именно то, что это происходит резко с сотен до лимита 4096.
mysql, redis, php-fpm, nginx

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
133672 mysql 20 0 0,233t 0,071t 16748 S 332,4 29,0 48321:07 mysqld
1335 root 20 0 36,728g 0,034t 2460 R 37,4 13,8 46714:28 redis-server
1332 root 20 0 7720428 1,333g 1844 S 0,0 0,5 171:06.39 redis-server
1337 root 20 0 577004 496936 1256 S 0,0 0,2 138:58.52 redis-server
1334 root 20 0 577004 496724 1264 S 0,0 0,2 138:29.44 redis-server
1331 root 20 0 577004 489052 1408 S 0,0 0,2 137:52.30 redis-server
84055 www-data 20 0 1252596 134864 86948 S 29,1 0,1 8333:28 nginx
84056 www-data 20 0 1246700 128864 86864 S 24,9 0,0 6575:24 nginx

[Vitaly Karasik]

Странно именно то, что это происходит резко

а откуда знаете что резко? есть график?

133672 mysql 20 0 0,233t 0,071t 16748 S 332,4 29,0 48321:07 mysqld

А "free -m"?
Наверно можно попробовать добавить памяти для MySQL (innodb_pool)

попадают обычные запросы UPDATE `users` SET `points` = `points` + 1 WHERE `id` = 4457143; периодически.

а что говорит

explain select * from users where id=4457143
?

Мне думается, что сервер упирается в какие-то лимиты диска или подобное, но как это понять, куда стоит смотреть?

А есть мониторинг сервера, в частности графики IO?

[egoranisimov]

Да, графики есть всего и вся.

total used free shared buffers cached
Mem: 258369 201990 56378 4280 561 64053
-/+ buffers/cache: 137375 120994
Swap: 3811 3204 607

explain simple const primary rows 1, всё ок по идее

Вроде оно?

[egoranisimov]

Vitaly Karasik,

[Vitaly Karasik]

egoranisimov,
Посмотрел все, выглядит странно.
- А сколько у вас памяти? Вывод free в чем? Swap выглядит занятым, но память вроде свободна
- Жалко, что граф disk I/O не рисуется

А в целом у меня осталась последняя идея - запустить cron и сохранять processlist - может это поможет понять что происходит во время пиков. Что-то типа

*/5 * * * * echo "show full processlist" | mysql >> /tmp/processlist.out

Answer 2

[Everything_is_not_so_bad]

Нужно установить средства для мониторинга Mysql. Например https://www.percona.com/software/database-tools/pe...