Назад | Перейти на главную страницу

Внезапные скачки загрузки ЦП MySQL / Percona Server

У меня возникли проблемы с Percona Server 5.5: внезапно ненормальное использование ЦП MySQL привело к тому, что система перестала отвечать, так как она поглощала весь ЦП большим количеством потоков.

Это 24-ядерная система с 64 ГБ оперативной памяти, которая обычно простаивает (средняя нагрузка около 0.xx). Я проверил список процессов, но нашел лишь несколько запросов и среднее количество подключений. Также на сайте было очень мало посетителей.

На самом деле основная БД составляет около 15 ГБ, немного фрагментирована и всегда хорошо индексируется (купите, планируйте исправить это в ближайшее время). Но даже при сбросе всех таблиц или запуске magento crons нагрузка довольно низкая.

Когда я перезапустил службу mysql, проблема исчезла.

Как лучше всего это отладить?

Также может быть связано с некоторыми оптимизациями, которые я применил к my.cnf? Не думаю, что я добавил что-то странное, только кеши, буферы, открытые таблицы, time_wait и max_packet. Я не перегружал оперативную память и не выставлял там варианты бездумно.

[mysqld]
# * Basic Settings
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/sql/
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking

## security
local-infile=0
## disable for security
old_passwords = no
## combat lock wait timeouts
wait_timeout=300
##innodb_lock_wait_timeout set to debug transaction wait timeout (default 50)
innodb_lock_wait_timeout=200

# * Fine Tuning
key_buffer              = 16M
thread_stack            = 192K
thread_cache_size       = 8
## increased to combat server has gone away issue with magento (usually sign of MP)
max_allowed_packet      = 32M

## increased
max_connections        = 400
## skipped, synonym for table_open_cache
#table_cache            = 128
## don't use this it's a waste of time
#thread_concurrency     = 10
## keep this fair
table_open_cache       = 1500
## generally high enough to match pref table sum
table_definition_cache = 5000

# * Query Cache Configuration
## if frequent prunes happen: decrease to prevent performance hog (defaults to 1M)
query_cache_limit       = 256K
## doubled to 32MB - monitor hitrate and adapt accordingly in 12MB steps
query_cache_size        = 64M
## don't increase too much as inefficient queries will perform even worse
#tmp_table_size = 32M
#max_heap_table_size = 32M

## Feed the beast!
innodb_buffer_pool_size = 24G
## enable stats (debug + BF prevention)
userstat = 1

Буду благодарен за предложения, так как я, конечно, буду спать лучше, зная, что система стабильна;)