Sporadischer 500 - premature end of script bei fcgid/Apache2

Leicht off-topic, aber trotzdem:
Paeddl said:
...obwohl mod_php für mich eigentlich nicht in Frage kommt, weil dort meines Wissens auch der Speicherverbrauch im Laufe der Zeit zunimmt oder ist das mittlerweile korrigiert worden?
Click to expand...

Soweit ich da informiert bin ist es so, dass ein Apache Prozess nie wieder Speicher freigibt bis er neu gestartet wird. Das heißt: Wenn Du PHP Skripte hast, die 200MB Ram verbrauchen, ist der Apache Prozess nachdem das Skript durchgelaufen ist auch 200MB groß. Den Speicher belegt er auch, wenn er in den folgenden Requests nur benötigt wird um 1kb Gif Bilder auszuliefern.
Dafür gibt es dann aber auch in der Apache Config des mpm_prefork_module den Paramneter "MaxRequestsPerChild". Der Wert gibt an nach wievielen Requests der jeweilige Prozess neu gestartet wird.
Wir haben den Wert derzeit auf 2000 stehen und auch bei mehreren Monaten Laufzeit und recht ordentlicher Nutzung gibt es keine Probleme mit dem allokierten Speicher.
Ein grundsätzliches Leak hat mod_php daher meines Wissens nach nicht, man muss halt wissen, was man beachten muss.

Grüße,
Christopher
 
Moin,

nun geht es weiter. Habe seit kurzem 3 Produktivmaschinen mit neuem Softwaresetup laufen und sammle fleissig Daten. Eine 4. kommt noch hinzu. Ich brauche die Logdateien für mindestens 1 Woche, nur dann kann ich zwischen Debian 4, Debian 5 und CentOS vergleichen.

Ich bin schon dabei, die "alten" Logdateien aufzubereiten, dabei haben sich einige interessante Erkenntnisse ergeben.
 
Nun habe ich 3 Monate Erfahrungen mit dem neuen Setup. Kurzum: Die 500er werden wohl durch den APC verursacht.

Anfangs gab es auch unter CentOS immer noch durch PHP verursachte 500er, über die ich mich per E-Mail informieren lassen habe.

Dann habe ich APC ausgemacht und vorbei war der Spuk.

Anbei ein paar Log-Auszüge aus einem Debian Lenny System für diejenigen, die selbst recherchieren wollen. Die Log-Pfade müssen natürlich angepasst werden, ggf. auch der Loglevel vom Apachen:

Code: 
zless {/var/www/*/log/*.log.2.gz,/var/log/apache2/*.log.2.gz} | grep "Premature"

[Tue Jan 18 16:38:59 2011] [error] [client nn.nnn.nnn.nnn] Premature end of script headers: index.php

Code: 
zless {/var/www/*/log/*.log.2.gz,/var/log/apache2/*.log.2.gz} | grep "communication error"

[Tue Jan 18 16:39:18 2011] [notice] mod_fcgid: process /var/www/host/htdocs/index.php(15274) exit(communication error), terminated by calling exit(), return code: 0

Code: 
zless {/var/www/*/log/*.log.2.gz,/var/log/apache2/*.log.2.gz} | grep "HTTP/1.1\" 500"

meinedomain.de:nn.nn.nn.nn - - [18/Jan/2011:16:39:15 +0100] "GET / HTTP/1.1" 500 44933 "-" "Mozilla/5.0 (compatible; MSIE 6.0b; Windows NT 5.0) Gecko/2009011913 Firefox/3.0.6 TweetmemeBot" 341 28960

Wenn es einmal zu solch einem FastCGI-"communication error" gekommen ist, sind auch andere vHosts davon betroffen gewesen. Ich denke mal, dass das mit dem Workerkonzept zusammenhängt (Apache Child/Thread-Konzept).

Eventuell lässt sich der Fehler beheben, wenn man die Grösse des APC-Caches anpasst. Ich habe ein wenig nachgelesen und herausgefunden, dass die Abstürze dadurch verursacht werden können, dass die Skripte mehr Speicher als der verfügbaren Cache brauchen.

Im Moment ist APC deaktivert, ich muss den mit neuer Grösse mal testweise reaktivieren und dann wieder beobachten.
 
You must log in or register to reply here.
Back
Top