Hallo liebes Team, Nachdem wir heut Probleme mit dem Datenbankzugriff von service01.lmx hatten, fiel mir auf das cache01 sehr langsam ist. http://collector7.gs.activate.de/cgp/host.php?h=cache01.lmx.xres.de Aus der Colletd-Statistik lässt sich ablesen, das Hauptspeicher und Swap überlaufen. Darum liest sich das kern.log wie eine spannender Sherlok Holmes Roman in dem der mysteriöse Out-Of-Memory (Serien-)Killer sein Unwesen auf den Systemen treibt. Ab und zu läuft ihm ein php-Prozess vor die Flinte. Gestern nacht hat er jedoch die Datenbank erwischt, welche zum Glück automatisch neugestartet wurde. Heute Nachmittag 16:20 - 17:00 hatte die Datenbank leider nicht dieses Glück, da ihr Elternprozess geschlachtet wurde. Zum Glück waren Marcel und ich zufällig auf dem System und haben dies mitbekommen. Der DB-Prozess wurde neu angekurbelt. Darum habe ich mich dazu entschieden morgen die MySQL-Prozesse (und deren Ressourcen) aller Cache01 in Nagios aufzunehmen. ;-) Cache01.lmx zeit dieses Verhalten seit Mittwoch morgen. Kann das mit den Änderungen am code korellieren ? Der Speicherabdruck hat sich verdoppelt, schiebt sich in den Swap. Die zusätzlichen Festplattenzugriffe reissen die Leistung des Systems im Ganzen herunter. Das System ist nun so eingestellt, so wenig wie irgend möglich in die Auslagerungspartition zu schreiben: sysctl vm.swappiness = 1 Der IO-Scheduler wurde ausgetauscht, dies führt zu deutlich besserem Antwortverhalten und Plattendurchsatz: echo deadline > /sys/block/sda/queue/scheduler Marcel hat den Loader neu gestartet, sodass der Server selbst so langsam wieder Fahrt aufnimmt. Schönen Feierabend wünscht Tobias -- Tobias Stein - Systemadministration - activate communication systems GmbH G.-Schumann-Str. 294 04159 Leipzig Tel.: +49 341 90 98 7 508 email: t.stein@activate.de Geschäftsführer: Markus Hartwig, Rainer Jansen Handelsregister: Amtsgericht Leipzig (HRB 21850)