Regelmäßige MySQL-Sperre, wenn WordPress stark ausgelastet ist

Ich habe eine MySQL 5.1.61-Datenbank, die hinter zwei lastausgeglichenen Apache-Webservern läuft, die eine ziemlich ausgelastete (100.000 Uniques pro Tag) WordPress-Sites hosten. Ich cache mit Cloudflare, W3TC und Varnish. Meistens verarbeitet der Datenbankserver den Datenverkehr sehr gut. “show full processlist” zeigt 20-40 Abfragen zu einem beliebigen Zeitpunkt an, wobei sich die meisten im Ruhezustand befinden.

Von Zeit zu Zeit (insbesondere bei Verkehrsspitzen oder wenn eine große Anzahl von Kommentaren gelöscht wird) reagiert MySQL jedoch nicht mehr. Ich finde 1000-1500 laufende Abfragen, viele “Senden von Daten” usw. Keine bestimmte Abfrage scheint die Datenbank zu belasten (es sind alles Standard-Wordpress-Abfragen), aber es scheint nur so, als würde das gleichzeitige Volumen von Anfragen alle Abfragen verursachen aufzuhängen. Ich kann mich (normalerweise) immer noch anmelden, “show full processlist” oder andere Abfragen ausführen, aber die über 1000 Abfragen, die bereits darin enthalten sind, sitzen einfach. Die einzige Lösung scheint zu sein, mysql neu zu starten (manchmal heftig über kill -9, wenn ich keine Verbindung herstellen kann).

Alle Tabellen sind innodb, der Server hat 8 Kerne, 24 GB RAM, viel Speicherplatz und das Folgende ist meine 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

Irgendwelche Vorschläge, wie ich die MySQL-Konfiguration möglicherweise verbessern kann, oder andere Schritte, um die Datenbankstabilität unter hoher Last aufrechtzuerhalten?

Denken Sie, wie bereits gesagt, über den Tellerrand hinaus und finden Sie heraus, warum diese Abfragen langsam sind oder irgendwie hängen bleiben. Ein Oldie, aber eine gute Quelle von Problemen, selbst für (angeblich;) intelligente Systemingenieure, ist der Lastausgleich, der Probleme über Webserver- oder Datenbanksitzungen hinweg verursacht. Sind Sie sich bei all dem Caching und Lastenausgleich sicher, dass alles immer wie beabsichtigt End-to-End verbunden ist?

Ich stimme Alditis & Björn zu

Ich bin ziemlich noobish mit mysql, aber das Ausführen von mysqltuner kann einige Konfigurationsoptimierungen basierend auf den letzten Abfragen der DB offenbaren https://github.com/rackerhacker/MySQLTuner-perl

Und wenn möglich, speichern Sie die DB-Dateien auf einer physikalisch getrennten Partition vom Betriebssystem, das Betriebssystem kann IO verbrauchen, was die DB verlangsamt. Wie bei Björns Logrotate-Problem.

Werfen Sie zunächst einen Blick auf das grundlegende Systemverhalten im Moment von Problemen. Verwenden Sie sowohl vmstat als auch iostat, wenn Sie Probleme finden. Prüfen Sie, ob das System mit dem Austauschen beginnt (pi, po-Spalten in vmstat) und ob viele E / A stattfinden. Dies ist der erste Schritt zum Debuggen Ihres Problems.

Eine weitere Quelle nützlicher Informationen ist SHOW INNODB STATUS. Siehe http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/ wie die Ausgabe zu interpretieren ist.

Es kann sein, dass Ihre Schreibvorgänge zu einem bestimmten Zeitpunkt die Leseleistung beeinträchtigen, weil sie den Abfrage-Cache leeren.