Skip to content

Ratlosigkeit ...

Mir gehen so langsam die Ideen aus.

Unser root-Server zeigt mittlerweile ein Mal am Tag Ausfallerscheinungen, Rekord war ein load average von 174 und ich habe gesehen, dass unglaublich viele Postfix- und auch reichlich viele Apache2-Prozesse liefen. Darüber kam der Server ins swappen und war kaum noch ansprechbar. Die Resultate sehe ich, aber ich finde die Ursache nicht.

Natürlich haben wir die Logs von Mailserver und Webserver analysiert und nach den "üblichen" Verdächtigen gesucht, wir sind aber leider nicht fündig geworden.

Ernst gemeinte Vorschläge und Hilfen sind herzlich Willkommen.

Trackbacks

Dirks Logbuch am : Kein Hardwarefehler ...

Vorschau anzeigen
So, unser Hoster hat einen acht-Stündigen Hardwaretest auf die Maschine losgelassen. Leider ohne Erfolg. Allerdings hat nach dem Hochfahren das Software-RAID1 sich noch synchronisiert. Vielleicht haben sie ja prophylaktisch die Platten getauscht. Drück

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Richard am :

*Warum soll es dir da besser gehen als uns? Wir jagen nun schon seit einiger Zeit dem "Phantom"-Phaenomen hinterher... Bis jetzt ohne wirklichen Erfolg!

Jimbo am :

*Evtl defekte Festplatte? Könntest du mal nen FSCHK machen

visus am :

*Waere auch meine erste Idee gewesen. Ich hatte das mal bei einer ESX Virtual Machine... Einige Prozesse sind bei Schreibvorgaengen haengen geblieben und die Programme haben angefangen Prozesse zu forken (vor allem apache-prefork stand sehr oft im ps-Output).

Die zweite Idee: RAM kaputt? Der Kernel kommt relativ gut mit defektem RAM klar und ignoriert die defekten Teile (manchmal aber nur bei der Nutzung und nicht in den Stats). Das koennte den Kernel swappen lassen. Probiert mal memtest.

Dirk Deimeke am :

*Das werde ich einmal beim Support anfragen. Einen memtest kann ich nicht Remote machen. Danke!

Dirk Deimeke am :

*Den habe ich schon gemacht und danach durfte ich dne Server neu aufsetzen. Nach dem Neuformatieren der Platten habe ich einen weiteren fsck gemacht, der allerdings keinerlei Probleme zeigte.

Ute am :

*Puh, ihr Armen, das tut mir leid, als hätte es nicht gereicht, dass die Kiste euch schon ein Wochenende gekostet hat... Leider fällt mir außer Daumen drücken, dass ihr bald die Ursache findet nichts ein.

Alphager am :

*Check mal die Temperaturen; ich hatte einen ähnlichen Fall, bei dem die CPU-Kühlung ausgefallen war -> CPU-Drosselung ohne Ende.

el*Loco am :

*Ich tippe auf die Festplatte(n), das würde die hohe Load auf Grund vieler auf I/O wartender Prozesse erklären - zeigt das Ding per SMART denn etwaige Fehler an?

Dirk Deimeke am :

*Auf dem Server ist kein Smart. Die grosse Frage ist, was von dem, was wir beobachten die Ursache und was die Wirkung ist.

Die IOwaits können auch durchaus vom Swappen kommen.

el*Loco am :

*Ach ja, kannst du evtl. mal ein dmesg und komisches aus /var/log/(messages|kern.log|daemon) o.ä. posten? Tauchen die Fehler immer zur gleichen Zeit auf? Laufen da komische Cronjobs?

Da ihr in den apache logs nichts gefunden habt, ist wahrscheinlich ein Amok-laufender Crawler auszuschliessen - Yahoo hat da in der letzten Zeit immer mal wieder Probleme.

Dirk Deimeke am :

*In den Log-Dateien ist gar nichts zu finden, als ob ein Schalter zum Zeitpunkt der übergrossen Load umgelegt wurde.

Cronjobs schliesse ich aus, da die Zeiten nicht mit unseren Cronjobs übereinstimmen.

Dirk Deimeke am :

*Ich kann mir auch folgendes Verhalten vorstellen, habe aber noch keine Beweise dafür gefunden:

Wir haben ja einige Stellen, an denen externe Dienste zur Hilfe genommen werden, um Spam zu prüfen. Blacklist für NIXspam bei Manitu, Akismet für Blogkommentare.

Wenn jetzt eine Spamwelle rollt, könnte es hypothetisch sein, dass einzelne Threads sehr lange auf Antworten der entfernten Systeme warten.

Sie warten und verbrauchen Speicher. Die Nächste Mail die kommt (Kommentare im Blog schliesse ich aus, da ich gar nichts im Log finde), bekommt einen neuen Thread. Irgendwann ist das RAM aufgebraucht und die Maschine geht ins Swapping.

Die Frage ist, wie ich einen Hebel bekomme, um das zu bestätigen.

onli am :

*Nun, wir könnten alle diese externen Dienste soweit möglich mal schließen oder alle loggen bzw. die vorhandenen Spamlogs prüfen.

Dirk Deimeke am :

*Das ist alles schon passiert. Es gibt nur leider überhaupt keinen Hinweis. Weder zu viele Mailverbindungen noch zu viele Connects auf den Webserver. Daraus resultierend gibt es natürlich auch kaum Zugriffe auf die Kommentarfelder ...

onli am :

*Nachtrag: Vielleicht ist es völlig unbedeutend, vielleicht hat es hiermit was zu tun. Als ich eben meinen Beitrag speichern wollte, scheiterte die Trackbackgenerierung, am Punkt "Sende pingback an URI https://sourceforge.net/blog/xmlrpc.php...", der zweiten URL.

Ein gescheiterter Pingback ist natürlich an sich bedeutungslos, aber normalerweise sollte Serendipity dann einfach weitergehen anstatt die Generierung ganz abzubrechen, was auf einen "kritischen" Fehler hindeutet.

Da das auch was mit externen Diensten zu tun hat, wollte ich es erwähnt haben.
Gruß

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen