我在使用 Percona Server 5.5 時遇到了一些麻煩：突然異常的 MySQL CPU 使用率導致系統變得無回應，因為它用大量執行緒耗盡了所有 CPU。
它是一個 24 核系統，具有 64GB RAM，通常處於空閒狀態（平均負載約為 0.xx）。我檢查了進程列表，但發現只有幾個查詢和平均連接數。此外，現場的訪客也很少。
事實上，主資料庫大約有 15GB，有點碎片化，而且索引總是很好（商店，計劃盡快修復這個問題）。但即使轉儲所有表或運行 magento crons，負載也相當低。
當我重新啟動 mysql 服務時，問題就消失了。
調試這個的最好方法是什麼？
另外，這是否與我對 my.cnf 進行的一些優化有關？我不認為我添加了一些奇怪的東西，只是快取、緩衝區、打開表、time_wait 和 max_packet。我沒有過度使用 RAM 或不假思索地將選項放在那裡。
[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
我將不勝感激您的建議，因為知道系統是穩定的，我肯定會睡得更好；）