Guten Morgen zusammen!

Ich habe vor einigen Tagen für ein Community-Projekt drei Server (2x Web, 1x DB) in Betrieb genommen. Auf den beiden Webservern läuft Apache 1.3 (Debian-Package) mit PHP 4.1, es handelt sich um Athlon XP 2400+ - Maschinen mit 2 GB RAM mit Debian Sarge. Der Datenbankserver ist ein Athlon 64 X2 4200+ ebenfalls mit 2GB RAM, Debian Sarge AMD64 und MySQL 5.0 (tar-Distribution von mysql).

Da ja hinreichend bekannt ist, daß MySQL auf AMD64-Maschinen insbesondere unter Sarge Schwierigkeiten mit der verwendeten glibc hat, habe ich die libc6-2.3.6-7 von Debian installiert.

Jetzt tritt aber ein sehr eigenartiger Effekt auf. Von Zeit zu Zeit (ca. alle 10 bis 30 Minuten) hängt Aapche für einige Sekunden (ca. 15 bis 30 Sekunden), nichts tut sich, und danach geht es mit voller Geschwindigkeit weiter. D.h. wenn man eine Seite aufruft, passiert erst mal gar nichts ("warten auf servername..." im Browser) und dann nach ner kurzen Zeit kommt die Seite mit voller Geschwindigkeit. Eigenartig an dieser Situation ist, daß die Webserver vorher mit nicht allzu großer Last (höchstens 2.0) laufen, auch der Datenbankserver hat eine Last, die zwischen 0.2 und 0.8 pendelt. Wenn nun solch ein Stall auftritt, verschwinden die Apache-Prozesse bis auf zwei, die ganz oben stehen, aus der Prozessliste, die Last fällt immer weiter ab (teilweise bis auf 0.2), dann tauchen urplötzlich wieder jede Menge Apache-Prozesse auf, die Last schießt bis auf 7.0 und die Seiten werden geladen (und zwar mit voller Geschwindigkeit). Das ganze scheint unabhängig von der Auslastung des mysql-Servers zu sein, dennoch tritt dieses Problem zeitgleich auf beiden Webservern auf, bevorzugt, wenn auf die Seite von vielen Clients zugegriffen wird. An sonsten läuft das ganze ziemlich zügig, auch unter hoher Last.

Und noch etwas ist mir aufgefallen... zeitweise (aber eher selten) kommt es vor, daß die Datenbank offenbar nicht mehr reagiert. Dann stellt sich die Last auf dem Datenbankserver bei 0.99 ein und die Webserver timen bei einer Anfrage aus (keine Fehlermeldungen!). Ein Neustart des Datenbankservers (per mysql restart) behebt das Problem sofort, auch ein Abschießen der mysqld-Prozesse ist, wie bei der alten glibc, nicht erforderlich, /etc/init.d/mysql kann die selbst beenden.

So, jetzt hoff ich, irgendjemand hat eine Idee, woran das liegen könnte. Falls ihr irgendwelche Konfigurationsdateien braucht, einfach fragen... mysql ist übrigens über die my-huge.cnf konfiguriert, lediglich max-connections wurde auf 1000 gesetzt.

Gruß,

Henning

Hm, also das Error-Log sagt gar nichts, da scheint alles in Ordnung zu sein.. aber wenn das Problem das nächste mal auftritt werd ich da noch mal reinschauen, ebenso in die Process List.

Bei der Process List ist mir jetzt aber etwas aufgefallen. Gestern abend hatten wir ca. 400 Leute gleichzeitig auf der Seite, bis auf die Hänger lief eigentlich alles recht zügig, die Last des DB-Servers pendelte zwischen 0.4 und 0.8. Heute sind jedoch nur etwa 200 User online, und die Datenbanklast pendelt zwischen 1.0 und 2.5, obwohl nichts an der Konfiguration etc. verändert wurde. Die ProcessList zeigt außerdem einen haufen gelockter Prozesse, die sich alle auf die User-Tabelle beziehen. Wie gesagt, es wurde nichts geändert und das Problem trat gestern abend nicht auf...

OK, ich kann mal allgemein Entwarnung geben. Das Problem (mit dem plötzlich langsamer gewordenen mysql) ist inzwischen gelöst, zwei Ursachen:

1. Table Locks auf stark genutzten Tabellen (Lösung: Tabelle konvertiert nach innoDB)

2. Table Scans bei bestimmten Abfragen: Ich habe ein symmetrisches Buddylisten-System, das bisher von der Datenbank zusammengeführt und sortiert wurde. Da aber eine a INNER JOIN b ON (a.a = const AND a.b = b.a) OR (a.b = const AND a.a = b.a) - Abfrage nicht wirklich mit Keys zu optimieren ist, hat mysql hier sehr ineffiziente Table-Scans durchgeführt. Das hab ich geändert, die Buddyliste wird zwei mal asymmetrisch eingelesen und erst im PHP-Skript zusammengeführt und sortiert.

Ich hatte wohl nicht bedacht, daß die Buddylisten über nacht stark angewachsen sind (aufgrund von Datenkonvertierungen)

Und siehe da, nach Behebung der beiden Schwierigkeiten läuft die Datenbank auch bei 300 Usern wieder mit einer Last von 0.2

Auch das Hänger-Problem ist seither nicht mehr aufgetreten.

Dennoch danke für den Versuch, mir zu helfen!