Wordpress의 부하가 높을 때 MySQL이 정기적으로 행업합니다.

Wordpress의 부하가 높을 때 MySQL이 정기적으로 행업합니다.

MySQL 5.1.61 데이터베이스를 로드 밸런싱된 Apache 웹 서버 두 대 뒤에서 실행하고 있으며, 사용 빈도가 상당히 높은 워드프레스 사이트를 호스팅하고 있습니다.Cloudflare, W3TC 및 Varnish와 캐싱하고 있습니다.대부분의 경우 데이터베이스 서버는 트래픽을 매우 잘 처리합니다."show full process list"는 항상 20~40개의 쿼리를 표시합니다.대부분은 sleep 상태입니다.

단, 정기적으로(특히 트래픽이 급증하거나 다수의 코멘트가 클리어되는 경우) MySQL은 응답을 정지합니다.1000~1500개의 쿼리가 실행 중이고, 다수의 "데이터 전송" 등이 있습니다.데이터베이스에는 특별한 쿼리가 없는 것 같습니다(모두 표준 Wordpress 쿼리입니다).다만, 동시 요청 볼륨으로 인해 모든 쿼리가 끊어지는 것 같습니다.로그인(통상)하거나 "전체 프로세스 목록 표시" 또는 기타 쿼리를 실행할 수 있지만 이미 1000개 이상의 쿼리는 그대로 유지됩니다.유일한 해결책은 mysql을 재시작하는 것 같습니다(접속할 수 없는 경우 kill-9을 통해 격렬하게 재시작하는 경우도 있습니다).

모든 테이블은 innodb, 서버는 8개의 코어, 24GB RAM, 넉넉한 디스크 용량으로 my.cnf:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
port=3306
skip-external-locking
skip-name-resolve
user=mysql
query_cache_type=1
query_cache_limit=16M
wait_timeout = 300
query_cache_size=128M
key_buffer_size=400M
thread_cache_size=50
table_cache=8192
skip-name-resolve
max_heap_table_size = 256M
tmp_table_size = 256M
innodb_file_per_table
innodb_buffer_pool_size = 5G
innodb_log_file_size=1G
#innodb_commit_concurrency = 32
#innodb_thread_concurrency = 32
innodb_flush_log_at_trx_commit = 0
thread_concurrency = 8
join_buffer_size = 256k
innodb_log_file_size = 256M
#innodb_concurrency_tickets = 220
thread_stack     = 256K
max_allowed_packet=512M
max_connections=2500
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

#2012-11-03
#attempting a ram disk for tmp tables
tmpdir = /db/tmpfs01

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

MySQL 구성을 개선할 수 있는 방법이나 부하가 높은 상황에서 데이터베이스의 안정성을 유지하기 위한 다른 방법이 있습니까?

이미 말했듯이, 틀에서 벗어나서 왜 이 질문들이 느리거나 행업하는지를 찾아보세요.오래되었지만 인텔리전트한 시스템 엔지니어(전제로)에게도 문제의 원인이 되는 것은 웹 서버 또는 데이터베이스 세션 간의 로드밸런싱입니다.캐싱과 로드 밸런싱이 모두 진행 중인데, 모든 것이 의도한 대로 항상 엔드 투 엔드로 연결되어 있다고 확신하십니까?

Alditis & Bjoern에 동의합니다.

mysql에 대해서는 잘 모르지만 mysqltuner를 실행하면 DB https://github.com/rackerhacker/MySQLTuner-perl의 최근 쿼리에 따라 몇 가지 구성이 최적화될 수 있습니다.

또한 가능하면 OS와는 물리적으로 다른 파티션에 DB 파일을 저장하면 OS가 IO를 소비하여 DB가 느려질 수 있습니다.Bjoern의 Logrotate 문제처럼요.

먼저 문제 발생 시 기본적인 시스템 동작을 살펴봅니다.문제가 발견되면 vmstat과 iostat을 모두 사용합니다.시스템이 스왑을 시작하는지 여부(vmstat의 pi,po 열)와 많은 IO가 발생하고 있는지 확인합니다.이것은 문제를 디버깅하기 위한 첫 번째 단계입니다.

또 다른 유용한 정보원은 SHOW INNODB STATUS입니다.출력의 해석 방법에 대해서는, http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/ 를 참조해 주세요.

특정 시점에 쓰기가 쿼리 캐시를 플러시하기 때문에 읽기 성능이 저하될 수 있습니다.

언급URL : https://stackoverflow.com/questions/13640127/periodic-mysql-lockup-when-wordpress-is-under-heavy-load