MySQL грузит все ядра проца. Глюк?
Лучше всего проблему иллюстритует сия картинка
Если описать это словами, то выходит так. Сервер работает как ни в чём ни бывало. Нагружено около половины ядер. И не на 100%, а на 50-70%. Потом внезапно нагрузка улетает в космос. При этом база встаёт раком, ответы происходят очень долго. Всё это длится 10-50 секунд, и потом опять перерыв на минутку.
И я никак не могу понять в чём причина этой беды. Ибо эту картинку я вижу не в первый раз. На нее я натыкался и ранее, еще лет 5 назад. То есть собственно версия ядра, дистрибутива или даже мускуля скорее всего не причем.
Причем по мониторингу (htop) видно что проц то загружен системным вызовом. Т.е. это или огромное количество некоторых вызовов к ядру, или интенсивное выделение-забирание памяти, или ввод-вывод.
Но как промониторить самые топовые вызовы ядра я не знаю. Память судя опять же по мониторингу массово не выделяется и не забирается (по меньшей мере гигабайтами, чтобы это было заметно).
iotop показывает ввод-вывод не сильно отличающийся от такового в нормальном состоянии.
Запросы во время глюка выполняются самые обычные. Не сказать чтобы как-то менялась пропорция выбор/обновление, или запрашивались особые таблицы. Думал может что-то по крону запускается из переодических заданий. Но я пробовал останавливать их все на время. Проблема остается.
К слову о сервере и системе: 2 x Xeon E5-2680v3 @2.5GHz (24 реальных ядра), 64Гб DDR4. SSD энтерпрайз уровня на 960Гб. Быстрые. Ну то есть сервер очень даже ничего. ОС Centos 7 (ядро 3.10), юзаю Percona 5.7. База на отдельном разделе (впрочем рояли это особо не должно играть). Кроме мускуля на сервере не стоит вообще ничего.
Собственно неделя как переехали со старого сервака, который был ровно в 2 раза слабее и перестал тянуть нагрузку.
Так вот на нём по началу я тоже видел такую же картину переодически. Но потом подобрал такие параметры в конфиге мускула, что всё вроде как улеглось. Но все ж сервак перестал тянуть, и мы переехали на новый… а тут опять эта проблема.
И тут время перейти к тому, чтобы рассказать что я УЖЕ делал:
1) Рестарт мускула — спасает ситуацию на минуту
2) Рестарт сервера ни на что не влияет
3) Тюнинг параметров. Пробовал дефолтные. Пробовал со старого сервака. Пробовал поднимать до разумных значений. Пробовал до неразумных. Пробовал тюнить по советам утилиты mysqltuner. Ничего не помогает.
Важное замечание: проблема наблюдается только в час пик. Так что всё это явно коррелирует с нагрузкой на мускул сервер. В остальное время дня всё окей.
Что еще я хочу сказать… я не настоящий сварщик. В смысле не DBA. Просто рядовой Linux-админ. Я плохо понимаю как внутри устроен mysql, innodb и так далее. Поэтому и прошу помощи. Разобраться сам не смог.
Ниже прикреплю на всякий случай шапку от mytop:
MySQL on localhost (5.7.18-16) up 0+00:38:59 [00:32:19] Queries: 26.1M qps: 11695 Slow: 0.0 Se/In/Up/De(%): 66/09/04/00 qps now: 11493 Slow qps: 0.0 Threads: 180 ( 5/ 8) 66/09/04/00 Key Efficiency: 93.0% Bps in/out: 11.0M/89.7M Now in/out: 10.7M/90.5M
Сейчас конечно не час-пик уже. Но хоть какая-то инфа.
И заодно конфиг мускула
[mysqld] bind-address=xxxx datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql symbolic-links=1 innodb_buffer_pool_size=16384M #пробовал всякое. от 8 до 32гб. разницы нет innodb_log_file_size=1024M # тоже всякое. вплоть до комментирования innodb_flush_method = O_DIRECT innodb_flush_log_at_trx_commit = 0 sql-mode="" query_cache_size = 4096M # тоже менял от 0 до 4гб join_buffer_size = 64M thread_cache_size = 8 max_connections=8192 open_files_limit=8192 explicit_defaults_for_timestamp=1 max_allowed_packet=128M log-error=/var/log/mysqld.log log_error_verbosity=2 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid open_files_limit=4096 innodb_buffer_pool_populate = yes flush_caches = yes numa_interleave = yes
Если интересно, могу опубликовать скрин Mysql Workbench Dashboard во время того когда мускул глючит.
Или Perfomance Statistics. Все равно я в ней ничего особо не понимаю.
Очень хочется разрешить уже этот глюк для себя. И понять почему он возникает.
Пока подозрения на то что у меня мускул сконфигурирован так, что потенциально может запросить больше памяти чем есть. И это как-то сносит крышу ядру.
Если описать это словами, то выходит так. Сервер работает как ни в чём ни бывало. Нагружено около половины ядер. И не на 100%, а на 50-70%. Потом внезапно нагрузка улетает в космос. При этом база встаёт раком, ответы происходят очень долго. Всё это длится 10-50 секунд, и потом опять перерыв на минутку.
И я никак не могу понять в чём причина этой беды. Ибо эту картинку я вижу не в первый раз. На нее я натыкался и ранее, еще лет 5 назад. То есть собственно версия ядра, дистрибутива или даже мускуля скорее всего не причем.
Причем по мониторингу (htop) видно что проц то загружен системным вызовом. Т.е. это или огромное количество некоторых вызовов к ядру, или интенсивное выделение-забирание памяти, или ввод-вывод.
Но как промониторить самые топовые вызовы ядра я не знаю. Память судя опять же по мониторингу массово не выделяется и не забирается (по меньшей мере гигабайтами, чтобы это было заметно).
iotop показывает ввод-вывод не сильно отличающийся от такового в нормальном состоянии.
Запросы во время глюка выполняются самые обычные. Не сказать чтобы как-то менялась пропорция выбор/обновление, или запрашивались особые таблицы. Думал может что-то по крону запускается из переодических заданий. Но я пробовал останавливать их все на время. Проблема остается.
К слову о сервере и системе: 2 x Xeon E5-2680v3 @2.5GHz (24 реальных ядра), 64Гб DDR4. SSD энтерпрайз уровня на 960Гб. Быстрые. Ну то есть сервер очень даже ничего. ОС Centos 7 (ядро 3.10), юзаю Percona 5.7. База на отдельном разделе (впрочем рояли это особо не должно играть). Кроме мускуля на сервере не стоит вообще ничего.
Собственно неделя как переехали со старого сервака, который был ровно в 2 раза слабее и перестал тянуть нагрузку.
Так вот на нём по началу я тоже видел такую же картину переодически. Но потом подобрал такие параметры в конфиге мускула, что всё вроде как улеглось. Но все ж сервак перестал тянуть, и мы переехали на новый… а тут опять эта проблема.
И тут время перейти к тому, чтобы рассказать что я УЖЕ делал:
1) Рестарт мускула — спасает ситуацию на минуту
2) Рестарт сервера ни на что не влияет
3) Тюнинг параметров. Пробовал дефолтные. Пробовал со старого сервака. Пробовал поднимать до разумных значений. Пробовал до неразумных. Пробовал тюнить по советам утилиты mysqltuner. Ничего не помогает.
Важное замечание: проблема наблюдается только в час пик. Так что всё это явно коррелирует с нагрузкой на мускул сервер. В остальное время дня всё окей.
Что еще я хочу сказать… я не настоящий сварщик. В смысле не DBA. Просто рядовой Linux-админ. Я плохо понимаю как внутри устроен mysql, innodb и так далее. Поэтому и прошу помощи. Разобраться сам не смог.
Ниже прикреплю на всякий случай шапку от mytop:
MySQL on localhost (5.7.18-16) up 0+00:38:59 [00:32:19] Queries: 26.1M qps: 11695 Slow: 0.0 Se/In/Up/De(%): 66/09/04/00 qps now: 11493 Slow qps: 0.0 Threads: 180 ( 5/ 8) 66/09/04/00 Key Efficiency: 93.0% Bps in/out: 11.0M/89.7M Now in/out: 10.7M/90.5M
Сейчас конечно не час-пик уже. Но хоть какая-то инфа.
И заодно конфиг мускула
[mysqld] bind-address=xxxx datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql symbolic-links=1 innodb_buffer_pool_size=16384M #пробовал всякое. от 8 до 32гб. разницы нет innodb_log_file_size=1024M # тоже всякое. вплоть до комментирования innodb_flush_method = O_DIRECT innodb_flush_log_at_trx_commit = 0 sql-mode="" query_cache_size = 4096M # тоже менял от 0 до 4гб join_buffer_size = 64M thread_cache_size = 8 max_connections=8192 open_files_limit=8192 explicit_defaults_for_timestamp=1 max_allowed_packet=128M log-error=/var/log/mysqld.log log_error_verbosity=2 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid open_files_limit=4096 innodb_buffer_pool_populate = yes flush_caches = yes numa_interleave = yes
Если интересно, могу опубликовать скрин Mysql Workbench Dashboard во время того когда мускул глючит.
Или Perfomance Statistics. Все равно я в ней ничего особо не понимаю.
Очень хочется разрешить уже этот глюк для себя. И понять почему он возникает.
Пока подозрения на то что у меня мускул сконфигурирован так, что потенциально может запросить больше памяти чем есть. И это как-то сносит крышу ядру.
Похожие публикации
MySQL: пользователь root без GRANT, что делать?
Ошибка при обращении sl «SQLSERVER:\». Как исправить?
MySQL запрос или вина хостера. Кто прав?
Как добавить свою колонку в раздел пользователи isp manager?
Почему падает mysql и поднять помогает только ребут, иначе daemon failed?
Нет комментариев