Ich habe einige Probleme mit Percona Server 5.5: Eine plötzliche anormale MySQL-CPU-Auslastung führte dazu, dass das System nicht mehr reagierte, da es mit einer großen Anzahl von Threads die gesamte CPU-Leistung beanspruchte.
Es handelt sich um ein 24-Kern-System mit 64 GB RAM, das normalerweise im Leerlauf ist (durchschnittliche Auslastung etwa 0,xx). Ich habe die Prozessliste überprüft, aber nur wenige Abfragen und eine durchschnittliche Anzahl von Verbindungen gefunden. Außerdem waren nur sehr wenige Besucher auf der Site.
Tatsächlich ist die Hauptdatenbank dort etwa 15 GB groß, etwas fragmentiert und immer gut indiziert (Shop, ich plane, das bald zu beheben). Aber selbst wenn alle Tabellen ausgegeben oder Magento-Crons ausgeführt werden, ist die Belastung ziemlich gering.
Als ich einen Neustart des MySQL-Dienstes durchführte, war das Problem behoben.
Wie kann ich dies am besten debuggen?
Könnte es auch mit einigen Optimierungen zusammenhängen, die ich an my.cnf vorgenommen habe? Ich glaube nicht, dass ich etwas Seltsames hinzugefügt habe, nur Caches, Puffer, offene Tabellen, time_wait und max_packet. Ich habe weder zu viel RAM zugewiesen noch gedankenlos Optionen hinzugefügt.
[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
Ich bin für Vorschläge dankbar, da ich mit Sicherheit besser schlafen werde, wenn ich weiß, dass das System stabil ist ;)