Eu tive alguns problemas com o Percona Server 5.5: o uso repentinamente anormal da CPU do MySQL fez com que o sistema parasse de responder, pois estava consumindo toda a CPU com um grande número de threads.
É um sistema de 24 núcleos com 64 GB de RAM que geralmente está ocioso (carga média em torno de 0,xx). Verifiquei a lista de processos, mas encontrei apenas algumas consultas e um número médio de conexões. Além disso, havia poucos visitantes no site.
Na verdade o banco de dados principal tem cerca de 15GB um pouco fragmentado e sempre bem indexado (compre, pretendo consertar isso em breve). Mas mesmo ao despejar todas as tabelas ou executar crons magento, a carga é bastante baixa.
Quando reiniciei o serviço mysql, o problema desapareceu.
Qual é a melhor maneira de depurar isso?
Também poderia estar relacionado a algumas otimizações que apliquei ao my.cnf? Não acho que adicionei algo estranho, apenas caches, buffers, tabelas abertas, time_wait e max_packet. Não comprometi demais a RAM nem coloquei opções lá sem 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
Ficarei grato por sugestões, pois certamente dormirei melhor sabendo que o sistema está estável ;)