Apache mod_fcgid/suexec und gelegentliche „Premature end of script headers“ Fehlermeldungen

[Fixed]

Ich habe vor kurzem unseren Webserver (Apache) auf mod_fcgid und suexec umgestellt um das ganze etwas sicherer zu gestalten. Die verschiedenen Benutzer und Webseiten auf unserem Server sind nun gegeneinander abgeschottet und alles sollte toller sein … so hoffte ich jedenfalls.

Scheint auch so zu sein. Die Webseiten mit PHP laden nicht langsamer als vorher (EAccelerator kann nicht mehr benutzt werden, da es nicht mit suexec funktioniert) und es laufen ganz viele php-cgi Prozesse mit den Rechten der entsprechenden Webbenutzern.

Ist aber nicht wirklich so. Unter Last stimmt da irgendwas nicht und der Server liefert ab und zu Server Error 500 („Premature end of script headers“) Fehlerseiten aus. Jetzt kann das natürlich daran liegen, dass hier alles auf einem Vserver liegt, aber /proc/user_beancounters deutet nicht darauf hin, dass irgendwelche Grenzwerte überschritten werden. Nur die Shared Memory Pages sind verdächtig hoch und nahe der Grenzwerte, normales RAM hat noch lange nicht die 2 GB Grenze erreicht.

Kennt sich irgendeiner meiner Leser damit aus? Was passiert mit PHP FastCGI unter Last? Brechen die Prozesse dann einfach so ab? Die php-cgi Prozesse für mein Blog sind nämlich witzigerweise alle kaum älter als 30 Minuten und das obwohl sie 2500 Anfragen bearbeiten sollen bevor sie neu gestartet werden und so beliebt ist mein Blog nun auch wieder nicht. Gibt es sonst noch einen Grund? In den Logs kann ich keinen weiteren Grund finden. Gibt es vielleicht einen Debugmode oder so etwas ähnliches wie strace dafür?

Meldet euch ;-)

Update:
Es muss tatsächlich etwas mit dem Starten bzw. Beenden der php-cgi Prozesse zu tun haben. Im Apache Error Log stehen die gleichen Zeiten bei den „Premature …“-Fehlern, die im suexec.log angeben wann ein php-cgi Prozess gestartet wurde. Für meinen Geschmack passiert das viel zu oft, obwohl PHP_FCGI_MAX_REQUESTS auf 2500 steht.

Noch ein Update vom Update: In dem Modus weckt Apache seine „Kinder“ per http-Anfrage an sich selbst auf der IP 127.0.0.1 … und das ziemlich oft. Vielleicht sind die 2500 Request deshalb so schnell aufgebraucht.

Update:
Ok, anscheinend ist es ein Problem mit dem shared Memory. Im error_log findet sich ab und zu

PHP Warning: [eAccelerator] Can not create shared memory area in Unknown on line 0
PHP Fatal error: Unable to start eAccelerator module in Unknown on line 0

So … das erklärt die Abstürze der Prozesse, wirft allerdings eine neue Frage auf. Warum zum Teufel läuft eAccelerator noch? Erstaunlicherweise scheint das Ding wirklich Bytecode in /tmp/eaccelerator abzulegen, obwohl ich überall gelesen habe, dass eAccelerator nicht mit suexec funktionieren soll. Ach ja, und warum funktioniert es eigentlich? Ich habe keine eaccelerator lib und es ist auch in keiner Konfigurationsdatei vermerkt. Wo kommt das Ding her? … da kommt wohl noch ein Update später ;-)

Letztes Update:
Scheinbar geht eAccelerator auch mit suexec und FastCGI zusammen (eine ini-Datei dafür lag in /etc/php5/apache2/conf.d). Das Problem waren dann tatsächlich die zur Verfügung stehenden Shared Memory Pages auf dem Vserver. Habe eAccelerator angewiesen weniger davon zu benutzen und die Dateien auf der Platte zu cachen. Ob das jetzt dann überhaupt noch viel bringt ist fraglich, aber es funktioniert ohne „Premature …“ – Fehler und das reicht mir erstmal.

Danke für die vielen Hinweise. Gebt zu, ihr wusstet, dass ich es eventuell selbst rausbekommen würde ;-)