Server hängt sich ständig auf
- Thread starter amaier161
- Start date
AFAIK, trifft die Konstanz an PHP-Prozessen und RAM-Bedarf nur zu, wenn diese ausreichen. IMHO konfiguriert man ja für das Modul ein Minimum an Prozessen, dass ständig zur Verfügung steht. Bei Bedarf erweitert das fastCGI-Modul dies jedoch dynamisch. Was aber kein Problem darstellt.
Soweit ich jedoch beobachten konnte, kassiert man die unbeliebten sporadischen 500er Errors sobald man in Sachen CPU vor allem aber beim RAM an die äußeren Grenzen kommt. Auf den ersten Blick sieht es so aus, als ob der Server geschmeidig läuft - weil die vorgenannten 500er Errors halt sehr "zufällig" auftreten. Ein Blick in die Logs offenbart dann eine ganz andere Situation.
Der Idealfall ist, dass man so viele Prozesse hat dass sie die CPU voll auslasten können, aber der RAM nicht übermäßig voll ist. Eine dynamische Anpassung macht dann keinen Sinn mehr, wenn der Server mit der Last nicht zurechtkommt, dann schafft er das auch bei mehr oder weniger Prozessen nicht. Diese Konfiguration ist mit FastCGI im Allgemeinen erreichbar. Ich muss allerdings sagen dass ich das Apache-Modul nicht persönlich kenne, nur litespeed und lighttpd.
Last edited by a moderator:
lighty hat eine eigene fastCGI-Implementierung von Haus aus von daher - wie Du schon angemerkt hast - nicht vergleichbar.
Das Problem ist IMHO, dass diverse How-Tos mit sehr unterschiedlichen Empfehlungen existieren, die dann in den meisten Fällen auch scheinbar sehr gut funktionieren. Aber zuweilen werden jene berüchtigten 500er Error produziert, die schwer nachvollziehbar sind.
Konfigurationen, die dazu tendieren ist z.B. so eine: http://www.howtoforge.com/how-to-set-up-apache2-with-mod_fcgid-and-php5-on-debian-lenny (nach meiner persönlichen Erfahrung) oder auch hier werden Probleme bei der Konfiguration aufgezeigt: http://wohnzimmerhostblogger.de/arc...att-auf-1-lieber-gar-nicht-setzen-sollte.html
Das ganze scheint sich noch zu verschärfen, wenn man nicht das Debian fcgid-Modul nimmt, sondern direkt auf das fastcgi-Modul zurückgreift - siehe auch hier: http://2bits.com/articles/apache-fcgid-acceptable-performance-and-better-resource-utilization.html
Mein Fazit: Bei PHP über FastCGI sollte man das Lastverhalten seines Servers und seiner Scripte gut kennen und in der Lage sein, diese korrekt zu beobachten. Tut man das nicht und übernimmt "blind" Beispielkonfigurationen, kommt es u.U. schnell zu schwer nachvollziehbaren Fehlern. Nach meiner Beobachtung ist es erstmal am besten, gar keine FCGI-Optionen speziell zu setzen (bis auf die zwingend notwendigen Pfade etc.) und erstmal die Defaults zu testen - oftmals funktionieren die bereits sehr gut.
Das Problem ist IMHO, dass diverse How-Tos mit sehr unterschiedlichen Empfehlungen existieren, die dann in den meisten Fällen auch scheinbar sehr gut funktionieren. Aber zuweilen werden jene berüchtigten 500er Error produziert, die schwer nachvollziehbar sind.
Konfigurationen, die dazu tendieren ist z.B. so eine: http://www.howtoforge.com/how-to-set-up-apache2-with-mod_fcgid-and-php5-on-debian-lenny (nach meiner persönlichen Erfahrung) oder auch hier werden Probleme bei der Konfiguration aufgezeigt: http://wohnzimmerhostblogger.de/arc...att-auf-1-lieber-gar-nicht-setzen-sollte.html
Das ganze scheint sich noch zu verschärfen, wenn man nicht das Debian fcgid-Modul nimmt, sondern direkt auf das fastcgi-Modul zurückgreift - siehe auch hier: http://2bits.com/articles/apache-fcgid-acceptable-performance-and-better-resource-utilization.html
Mein Fazit: Bei PHP über FastCGI sollte man das Lastverhalten seines Servers und seiner Scripte gut kennen und in der Lage sein, diese korrekt zu beobachten. Tut man das nicht und übernimmt "blind" Beispielkonfigurationen, kommt es u.U. schnell zu schwer nachvollziehbaren Fehlern. Nach meiner Beobachtung ist es erstmal am besten, gar keine FCGI-Optionen speziell zu setzen (bis auf die zwingend notwendigen Pfade etc.) und erstmal die Defaults zu testen - oftmals funktionieren die bereits sehr gut.