Percona Server 5.5에 문제가 있습니다. 갑자기 비정상적인 MySQL CPU 사용으로 인해 많은 수의 스레드로 모든 CPU를 소모하면서 시스템이 응답하지 않게 되었습니다.
일반적으로 유휴 상태(평균 로드 약 0.xx)인 64GB RAM을 갖춘 24코어 시스템입니다. 프로세스 목록을 확인했지만 몇 개의 쿼리와 평균 연결 수만 발견되었습니다. 또한 사이트 방문자도 거의 없었습니다.
실제로 메인 DB에는 약 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
시스템이 안정적이라는 것을 알고 잠을 더 잘 수 있을 것이기 때문에 제안해 주시면 감사하겠습니다. ;)