MySQL hängt sich sporadisch auf

Mr.Check

New Member
Moin moin,

ich habe ein Problem mit einem MySQL Server (dedizierter Server mit 16GB RAM, Festplatte SSD). Die Web-Applikation, die diesen Server nutzt, ist ein sehr gut besuchter WordPress-Blog, welcher auf dem selben Server liegt. Alle Tabellen des WordPress-Blogs nutzen MyISAM.

Von der Einstellung des MySQL-Dienstes scheint alles in Ordnung zu sein. Tuning-Primer hat nur die üblichen Kleinigkeiten zu bemängeln, aber die Website läuft bei jeder Besucherzahl flüssig und der MySQL-Dienst macht sich von der Last her kaum bemerkbar.

Von Zeit zu Zeit kommt es allerdings vor, dass der MySQL-Dienst offenbar nicht mehr in der Lage ist, Anfragen zu beantworten. Die CPU-Last geht auf 600% und laut mytop warten etliche Anfragen auf Beantwortung, die Anzahl der MySQL-Threads steigt sprunghaft von sonst ca 2-5 auf >150 an. Die Anzahl der qps bleibt dabei in etwa stabil. Dies führt dazu, dass nach und nach die Anzahl der laufenden PHP-Threads steigt, bis der Server letztendlich keine Anfragen mehr entgegennehmen kann. Ich schalte dann den Webserver aus, starte die Datenbank neu und starte den Webserver wieder. Danach ist die Welt wieder in Ordnung. Ein Zusammenhang zwischen Besucherzahlen und dem Auftreten dieses Problems konnte ich bisher nicht feststellen.

Meine Theorie: Sporadisch wird eine Abfrage an den MySQL-Dienst gestellt, welche eine der Tabellen lockt und aufgrund unerklärlicher Umstände nicht (vernünftig) beendet werden kann. Dadurch bleibt die Tabelle im Locked-Status und alle weiteren (SELECT-)Anfragen an den Server reihen sich geduldig in eine Warteschlange ein, welche aufgrund des anhaltenden Lockings nicht mehr abgearbeitet wird.

Könnte es sich so in etwa darstellen? Bisher habe ich als Logfile nur das Error-Log aktiviert, aus dem leider gar nichts hervorgeht. Ich habe jetzt mal das Slow-Query-Log eingeschaltet und erhoffe mir dadurch neue Erkenntnisse nach dem nächsten Fehler.

Was könntet ihr mir sonst noch empfehlen, um ggf. die fehlerverursachende(n) Abfrage(n) ausfindig zu machen? Oder hat jemand vielleicht eine andere Idee, was diesen Fehler verursachen könnte?
 
Wie lange läuft der Server schon? Was für eine SSD ist verbaut? Evtl. ist die SSD hinüber und erlaubt keine Schreibzugriffe mehr?
 
Wenn es wieder hakt bitte mal Folgendes ausführen und die Ausgabe posten:
Code:
mysql -uroot -p -e 'SHOW PROCESSLIST; SHOW STATUS;'
 
Last edited by a moderator:
Wenn es wieder hakt bitte mal Folgendes ausführen und die Ausgabe posten:
Code:
mysql -uroot -p -e 'SHOW PROCESSLIST; SHOW STATUS;'

Mach ich. Seit gestern Abend ist es nicht mehr vorgekommen, mal gucken wann es wieder soweit ist.

Das Problem tritt seit rund zwei Wochen auf, zwischenzeitlich habe ich den Blog samt Datenbank auf einen neuen Server umgezogen - an der Hardware oder am OS wird es also wahrscheinlich nicht liegen.

Sowohl im alten als auch im neuen Server ist eine Intel 320 mit 160GB im Einsatz.
 
Müsste noch etwas aussagekräftiger sein:
Code:
mysql -uroot -e 'SHOW PROCESSLIST\G; SHOW STATUS;'
 
.. wenn man darauf wartet, tritt das Problem natürlich nicht (mehr) auf.

Ich habe nach dem letzten Hänger am Samstagabend in der my.cnf folgende Zeile ergänzt, um evtl. dem genannten Locking-Problem entgegenzuwirken:

Code:
low_priority_updates=1

Kann das tatsächlich schon die Lösung gebracht haben? Eigentlich sollte damit ja nur die Priorität der Updates gegenüber den Selects zurückgestellt werden, das Sperren der Tabelle wird dadurch ja nicht verhindert.
 
Nachdem der Fehler nun über eine Woche nicht mehr aufgetreten ist, kann man wohl davon ausgehen, dass die Option low_priority_updates=1 zum gewünschten Ergebnis geführt hat :)
 
Back
Top