15. August 2010

PHP_FCGI_CHILDREN – spar dir den Ram!

15. August 2010 - Geschrieben von Martin - 3 Kommentare

Mein kleiner Debian Test Server hat die letzten Tage unwahrscheinlich viel Ram gezogen. Von 265MB welche verbaut sind, nutzte er bereits nach einem Neustart ganze 75% – das kann es ja nicht sein, schließlich laufen dort lediglich ein Lighttpd, MySQL, Exim4, Courier und SSH, also nichts weltbewegendes. Zu diesem Zeitpunkt griff ich auch nur mit 2 Rechnern auf meine PHP Anwendungen zu.

Also begann ich die vielen php5-cgi Prozesse genauer unter die Lupe zu nehmen, da diese am meisten Ram brauchten. Nach einigem unnützen hin und herstellen in der PHP.ini wagte ich mich noch an die FastCGI Konfiguration von Lighttpd, dort habe ich nur so zum Test die PHP_FCGI_CHILDREN heraus geschmissen und siehe da, der Server benötigt nach einem Neustart des Webservers Lighttpd nur noch gute 30 bis 50% Ram, wenn das mal kein befriedigendes Ergebnis ist.

Des weiteren habe ich nun anstatt 12 php5-fcgi Prozessen nur noch 4 Stück. Offenbar beendet PHP oder FastCGI die Geforkten Tasks nicht mehr richtig …

Laut PHP Bugtracker existiert dieser Bug schon seit gut 3,5 Jahren: http://bugs.php.net/40286

3 Antworten zu “PHP_FCGI_CHILDREN – spar dir den Ram!”

  1. sebi sagt:

    Wiedermal muss ich dich berichtigen.
    Das „Problem“ am klassischen CGI („Common Gateway Interface“, Kommunikation zw. Webserver(-Backend) und der Anwendung (in dem Fall PHP)) ist der große Aufwand beim Starten („spawn“), das beinhaltet zB den Aufbau der Umgebung für die Anwendung (nicht das PHP-Programm, sondern PHP selbst) etc.
    FastCGI verwendet die Prozesse wieder, was enorm viel Zeit spart, wenn diese aber gar nicht nötig sind, ist der RAM natürlich voll. In Perl kann man einfach eine Endlosschleife starten, die das Programm bei Requests durchlaufen lässt. PHP (mit cgi/fcgi-Support, siehe „$ php -v“ bzw. „$ php-cgi -v“) erledigt das intern.

    SimpleCGI ist eine weitere, aber einfachere Alternative, mit dem gleichen Ziel.

    In Version 1.5 werden mod_fastcgi, mod_cgi, mod_scgi ersetzt durch mod_proxy_core, als universale Schnittstelle. Lighty rocks!

    LIghty lässt sich sehr gut und einfach anpassen, für alle möglichen Anwendungen. Wenn du willst, kann ich da mal einen Artikel schreiben.

  2. Martin sagt:

    Wenn du Lust hättest gerne, kannst mich ja mal in Jabber Anschreiben.

    Das die FastCGI Tasks bestehen bleiben ist klar, das hat auch einwandfrei funktioniert, nur die geforkten wurden offenbar benutzt und als sie keine Verwendung mehr fanden schlummerten sie vor sich hin. Bei der nächsten Request Welle wurden diese dann nicht mehr vom System verwendet und wieder neue gestartet. Irgendwann hatte ich dann so viele „Tote“ Tasks, das das System keinen Ram mehr zum forken hatte und Bääm hat sich die ganze Kiste aufgehängt.

    Die Zahl der Maximal Forkbaren Tasks herunterzuschrauben hat hier auch nichts gebracht, das System hat sich dennoch irgendwann aufgehängt.

    Genau so wenig hat idle Timeout geholfen, die Tasks wurden offenbar vom System als beendet angesehen, aber in Wirklichkeit liefen sie noch.

    Komisch :-/

  3. jimmy sagt:

    cool

Schreibe einen Kommentar