Percona Server 5.5 で問題が発生しました。突然、MySQL CPU 使用率が異常に高くなり、多数のスレッドで CPU がすべて消費されてシステムが応答しなくなりました。
これは、通常アイドル状態 (平均負荷は約 0.xx) の 64 GB RAM を搭載した 24 コア システムです。プロセス リストを確認しましたが、クエリはわずかしかなく、接続数は平均的でした。また、サイトへの訪問者もごくわずかでした。
実際、メイン DB は約 15 GB あり、少し断片化されていますが、常に適切にインデックス化されています (ショップ、すぐに修正する予定です)。ただし、すべてのテーブルをダンプしたり、Magento cron を実行したりしても、負荷はかなり低くなります。
service mysql restart を実行すると、問題は解消されました。
これをデバッグする最善の方法は何ですか?
また、これは私が 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
システムが安定していることがわかれば、きっと安心して眠れるので、ご提案いただければ幸いです ;)