Picos repentinos en el uso de CPU del servidor MySQL/Percona

Picos repentinos en el uso de CPU del servidor MySQL/Percona

Tengo algunos problemas con Percona Server 5.5: de repente, un uso anormal de la CPU de MySQL hizo que el sistema dejara de responder porque estaba consumiendo toda la CPU con una gran cantidad de subprocesos.

Es un sistema de 24 núcleos con 64 GB de RAM que normalmente está inactivo (carga promedio alrededor de 0,xx). Revisé la lista de procesos pero encontré solo unas pocas consultas y un número promedio de conexiones. Además, el sitio recibió muy pocos visitantes.

De hecho, la base de datos principal tiene alrededor de 15 GB, un poco fragmentada y siempre bien indexada (compre, planee arreglar eso pronto). Pero incluso cuando se descargan todas las tablas o se ejecutan crons de Magento, la carga es bastante baja.

Cuando reinicié el servicio mysql, el problema desapareció.

¿Cuál es la mejor manera de depurar esto?

¿También podría estar relacionado con algunas optimizaciones que apliqué a my.cnf? No creo que haya agregado algo extraño, solo cachés, buffers, tablas abiertas, time_wait y max_packet. No comprometí demasiado la RAM ni puse opciones allí sin pensar.

[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

Agradecería sugerencias ya que ciertamente dormiré mejor sabiendo que el sistema es estable;)

información relacionada