Das ging schief. Im Lauf der letzten Tage war der digitale heimwerker (und eine Handvoll anderer Blogs auf dem gleichen Server) unzuverlässig verfügbar. Hier ist die Spurensuche:
tl;dr
Die Garbage Collection im Objektcache des W3TotalCache-Plugin von WordPress hatte aus nicht erforschten Gründen versagt und so im großen Stil kleine Dateien angelegt. Dadurch wurde die Zuteilung an INodes in der VM überschritten und das Anlegen neuer Dateien (auch Sockets) führte zu Fehlermeldungen, die praktisch alles irgendwie betroffen haben.
Zur Reparatur wurde der Objektcache von Hand gelöscht.
Um zu vermeiden dass das Problem wieder auftritt wurde der Objektcache abgeschaltet. (Angesichts der laufenden Umzugsvorbereitungen ist das vorläufig angemessen.)
Als neulich die „digitale Alarmanlage“ des digitalen heimwerker losging und mich informierte dass die Webseite nicht erreichbar sei, war ich zunächst nicht beunruhigt: Der Hosting-Anbieter hatte Wartungsarbeiten angekündigt.
Als sich die Vorfälle häuften und auch andere Dienste (Email, SSH, DNS) immer öfter betroffen war, wurde ich irgendwann unruhig: Auch beim besten Hoster kann eine Wartung irgendwas zerlegen, aber nach ein paar Stunden, spätestens nach ein paar Tagen muss wieder Ruhe einkehren, auch bei einem eher billigen Hosting-Paket.
Ein wenig Überlegen… was gab es Neues in den letzten Tagen:
- Verschiedene Software-Updates, sowohl auf der Betriebssystem- als auch auf der Blog-Software-Ebene
- Unglaubliche Mengen Spam in asiatischen Schriftzeichen
- Systemwartung beim Hoster
- Experimente im Zusammenhang mit dem Umzug des Blogs auf ein neues Hosting-Paket.
Ziemlich viele sich bewegende Teile. Also… Ursachenforschung.
Zunächst stellt sich heraus, dass das System nicht vorhersehbar ausfällt. Mal geht’s, mal geht’s nicht. Sehr unbefriedigend.
Schlußfolgerung: Es ist wahrscheinlich ein Ressourcenengpass bei dem irgendetwas schon an der Grenze ist, aber dynamisch immer wieder freigegeben und wieder verbraucht wird.
Schneller Check mit top, free und df: Die „üblichen Verdächtigen“ (Hauptspeicher, CPU und Plattenplatz) waren es schon einmal nicht: CPU und Hauptspeicher waren unter 20%, Plattenplatz etwa bei 50%. Mir war zwar nicht klar, wo so viel Plattenplatz verbraucht werden sollte, aber was soll’s…
Die Fehlermeldungen der verschiedenen Progrämmchen (apache, mysql, sudo, du, …) haben immer etwas mit Ressourcenmangel zu tun, aber mal ist von „nicht genug Speicher“, mal von „kann nicht über Sockets kommunizieren“ und mal von „kann Datei nicht anlegen“ die Rede.
Schlußfolgerung: Es ist eine exotische Form von Ressourcenengpass, die in der Programmierung der verschiedenen Anwendungen nicht separat ausgewiesen wird.
Die Prozesstruktur (ps / pstree) legt nahe, dass der MTA sich an den Spam-Massen verschluckt haben könnte: Die Zahl der cleanup-Prozesse (aus dem postfix-Paket) und die Zahl der spamassassin-Prozesse war auffällig hoch. Vielleicht kommunizieren die über Sockets miteinander und verbrauchen zu viele Sockets?
Aber auch bei stillgelegtem Mailsystem legt sich das Problem nicht.
Irgendwann finde ich die rettende Frage bei ServerFault: „sudo: unable to create sockets: Cannot allocate memory“
Klar… das Hosting-Paket ist kein „vollwertiger“ virtueller Server sondern eine frühe Form eines Containers, d.h. gewisse Ressourcen werden über mehrere Kunden hinweg geteilt und dazu der Fairness halber rationiert („quota“ auf neudeutsch :-)). Also: Ein Blick in das virtuozzo Power Panel sollte mir sagen können, welche Ressourcen rationiert sind und wo ich damit stehe.
Tatsächlich: Die Zahl der INodes (spezielle Blöcke im Dateisystem, die für viele Linux-Dateisysteme den „Klebstoff“ zwischen dem Anwender-Konstrukt „Datei“ und dem hardwarenahen Konstrukt „Block“ darstellen) ist auf 3.000.000 begrenzt, und 3.000.001 sind verwendet.
Aber wer oder was verwendet so viele INodes? Zu viel Spam?
Wie man den Verbraucht von INodes im Dateisystem sauber zählen kann, habe ich nicht erforscht – verbrauchter Plattenplatz (wir erinnern uns… da war weiter oben eine kleinere Auffälligkeit) korreliert stark mit verwendeten INodes, das sollte eine gute Spur geben. Also:
du -hx –max-depth=1 /
… und immer den größten Verwender genauer untersuchen. Es stellt sich heraus, dass …/wp-content/cache/object/ unangemessen viel Plattenplatz verbraucht.
Das ist der Objektcache von W3TotalCache, einem Caching-Plugin für WordPress. Irgenwie scheint die Garbage Collection im Cache versagt zu haben.
Also: Mit dem Brecheisen von der Shell aus den Cache löschen (VORSICHT BEI COPY&PASTE: DIESES KOMMANDO LÖSCHT UNWIEDERBRINGLICH DATEN: „nice find VERZEICHNISNAME -mtime +0.5 -delete„). Das Löschen von ca. 2.700.000 Dateien dauert mehrere Stunden! – Zum Glück ist das System nach ca. einer halben Stunde wieder einsatzbereit weil wir weit genug von der Quota weg sind, und ich kann den Objektcache im WordPress-Dashboard abschalten.
