Guten Abend! Da bin ich wieder und das fast so schnell, dass ich schon auf der nächsten Seite bin. Heute habe ich den doch recht kalten Sonntag genutzt um Wäsche zu waschen, lecker zu schmankeln und meinen Server ein bisschen aufzupeppeln. Dabei lag das Hauptaugenmerk auf einem Fehler, den ich schon seit Anbeginn mit Nginx als Webserver hatte. Wobei das Problem eigentlich gar nicht bei Nginx selbst liegt, sondern vielmehr beim FCGI-Spawner … lasst mich kurz erläutern!

Nginx spawnt selbst keine PHP-Sessions, daher ist er Standalone lediglich in der Lage HTML-Code, also statische Dingenshausen auszugeben. Möchte man nun PHP verwenden, und wenn man ein Mann von Welt ist möchte man das, so ist es nötig ein entsprechendes Tool dahinter zu stellen, an dem Nginx lauschen kann. Unter Debian ist es recht einfach, denn man installiert einfach nur Nginx und spawn-fcgi, konfiguriert den Shit und schon läuft alles sauber. In meinem Falle aber lief es auf Anhieb nicht so sauber wie erwartet, denn manchmal waren die Ladezeiten recht negativ und (manche werden ihn gesehen haben) es kam oft zu einem “502 Gateway Timeout”.

Dies passierte immer dann, wenn der FCGI-Prozess aus unerfindlichen Gründen die Biege machte. Behoben hatte ich den Fehler eine Zeit lang recht … naja … sagen wir “alternativ”. Einfach den entsprechenden Befehl jede Minute per Cronjob ausführen lassen. Wenn der Prozess läuft, kann an den gleichen Port keiner mehr gebunden werden und wenn er nicht läuft (502) wird er einfach durch den Cronjob gestartet. Ist aber nicht die sauberste Möglichkeit, was ich besonders dann merkte, wenn ich in WordPress something hochladen wollte. Der Fehler ist jetzt behoben – auf Kosten meiner Freizeit. Aber hab ich doch gerne gemacht. Danke hier auch nochmal an den netten Blogger, der den Lösungsansatz geliefert hat.

Den genauen Grund kenne ich nach wie vor nicht, aber die Lösung.
Und zwar spawne ich meinen Prozess mit dem Befehl:

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f “/usr/bin/php5-cgi -c /lol/fail/php.ini” -P /var/run/fastcgi-php.pid

Wird der Befehl gestartet, so erscheint ein Prozess, der den PHPshit regelt. Soweit so gut. Nun stürzt dieser ständig ab – wie schon gesagt.
Deshalb ändere ich diese Zeile des Scripts oder auch den Befehl folgendermaßen ab:

/usr/bin/spawn-fcgi -F 1 -C 1 -a 127.0.0.1 -p 9000 -u www-data -g www-data -f “/usr/bin/php5-cgi -c /lol/fail/php.ini” -P /var/run/fastcgi-php.pid

Kurz zur Erklärung: -F und die darauf folgende Zahl bestimmt die Anzahl der Forks, -C und die folgende Zahl die Anzahl der Child-Prozesse pro Fork. Wer rechnen (oder top/htop nutzen) kann kommt zu der Erkenntnis, dass nun zwei Prozesse laufen. Die Zahlen kann man variieren, je nach Auslastung und Kapazitäten in Bezug auf Arbeitsspeicher. Anfangs hatte ich zwei Forks mit je zwei Childs – was aber sich dann aber auch gutim RAM-Verbrauch zeigte. Die Seite läuft auch mit den 1en gut, warum also mehr verbrauchen als man muss. :) Das kann natürlich jeder selbst entscheiden.

Diese Konfiguration läuft bei mir sehr stabil und der Cronjob ist nicht mehr nötig um die Seite dauerhaft verfügbar zu halten. Ich werde das dennoch in den nächsten Tagen beobachten und hier updaten, sofern etwas nicht hinhauen sollte. Der RAM-Verbrauch bei der “unsauberen” Konfiguration lag bei 590 Megabyte. Aktuell ist er bei 600 MB, wobei ich sagen muss, dass nicht nur der Webserver auf dem VPS läuft.

Wer vielleicht die genaue Ursache kennt, kann ja hier mal kommentieren.
Der “andere” Blogger meinte:

Nach langer Recherche im Internet stieß ich aber auf einem Beitrag, wo behauptet wurde, dass es gar kein Absturz, sondern geplantes Beenden des PHP-Prozesses zur Vermeidung eines (zu großem) Memory-Leak sei.

Und die im debianforum hatten (ausnahmsweise) auch mal keine Ahnung. :D

Und um nochmal an den ersten Teil zu erinnern – mit dieser Konfiguration ist die Seite merklich schneller geworden, so finde ich. Möglicherweise ist das aber auch nur Einbildung oder pure Dummheit. Letzteres schließe ich nicht aus. Gute Nacht!