Speichernutzung des Apache

[hmundt]

Hallo,

ich setze xampp1.4.4 auf Winodws 2000 ein. Auf dem System läuft eine php-Anwendung. Ich habe festgestellt, dass der Speicherverbrauch des Apache kontinuierlich ansteigt, und der einmal allozierte Speicher auch vom Apache nicht mehr freigegeben wird (selbst nachts, wenn keine User zugreifen).
Das geht so lange, bis folgende Meldung im error-Log auftaucht:
FATAL: emalloc(): Unable to allocate xxxxx bytes
oder auch
FATAL: erealloc(): Unable to allocate xxxxx bytes

Dann stirbt der Apache-Kindprozess und es wird ein neuer gestartet. Auszug aus dem Logfile:
[Mon Jul 12 18:22:34 2004] [notice] Parent: child process exited with status 1 -- Restarting.
[Mon Jul 12 18:22:44 2004] [notice] Parent: Created child process 1220
[Mon Jul 12 18:22:45 2004] [notice] Disabled use of AcceptEx() WinSock2 API
[Mon Jul 12 18:22:48 2004] [notice] Child 1220: Child process is running
[Mon Jul 12 18:22:48 2004] [notice] Child 1220: Acquired the start mutex.
[Mon Jul 12 18:22:48 2004] [notice] Child 1220: Starting 250 worker threads.
[Mon Jul 12 18:22:48 2004] [notice] Child 1220: Listening on port 443.

Dann geht das ganze Spiel wieder von vorne los.
Frage: Ist das normal?
Wenn nein, was kann ich tun um das zu debuggen?? Ich habe nirgendwo was dazu gefunden, auch nicht in den Apache- oder php-Mailinglisten.

Weiterhin habe ich das Problem, dass auf einem Server sich das so darstellt, dass nach der "emalloc-"Fehlermeldung zwar auch die o.g. Einträge im errorlog stehen, d.h. es sieht so aus, als ob der Apache den Kindprozess neu starte, aber der Server NIMMT KEINE REQUEST MEHR AN, bis man den Apache-Service von Hand neu startet.
Kann mir hier bitte jemand weiterhelfen? Kennt jemand vielleicht einen Workaround, wenn nicht die Lösung?

[Rolidor]

Hallo.
Kann es sein, dass dein Skript buffering benutzt, dann liegt es möglicherweise an PHP. Siehe http://bugs.php.net/bug.php?id=28260

Gruß
Rolo

[hmundt]

Hallo Rolo,

vielen Dank für den Tip. Allerdings trifft es nicht ganz. Explizites Buffering setze ich nirgendwo ein. Allerdings sehr wohl Sessions, wie in dem von Dir genannten Beiterag.
Auf einem Server setze ich den gzip-ob_handler ein, was glaube ich automatisch zu einem Buffering führt. Das Verhalten habe ich aber auch, wenn ich es ausschalte.
Es ist auch m.E. nicht wie in dem von Dir genannten Artikel das Memory Limit je Skript, was mir Probleme bereitet. Vielmehr "frisst" der Apache den gesamten zur Verfügung stehenden Speicher. Wahrscheinlich muss Winodws dann irgendwann das Swapfile vergrößern, das dauert und dann kommt der Fehler (oder so).
Noch irgendeine Idee?

Gruß Horst

[Rolidor]

Morsche.
Dann wäre es erst mal abzuklären, ob das Verhalten auch ohne PHP auftritt. Bei mir lag es jedenfalls bisher fast immer an PHP, wenn ich den Server mangels Speicher abgeschossen habe. Ich mache bei Sessions regen Gebrauch von Sessionvariablen. Was beim Testen auf dem lokalen Rechner völlig wasserdicht erschien, hat sich bei ausgiebiger Nutzung über mehrere Verbindungen später als Fiasko entpuppt. Daher bin ich inzwischen dazu übergegangen, Ressourcen sofort wieder frei zu geben, wenn sie nicht mehr gebraucht werden - auch wenn das lt. PHP-Doku angeblich durch die Beendigung des Skripts implizit geschieht. Das hat bei mir schon manches Problem beseitigt.

Gruß
Rolo

[hmundt]

Hallo Rolo,

ich hab schon schwer den Verdacht, dass es an php liegt. Hab jetzt nicht die Zeit für riesige Testreihen gehabt, aber bei statischen Dokumenten scheint sich der Apache nach einiger Zeit bei konstantem Speicherverbrauch einzupendeln.

Die Idee mit dem expliziten Freigeben der Ressourcen hatte ich auch schon. Bei den Datenbankabfragen mache ich das auch schon größtenteils. Werd ich dann wohl für die Variablen auch noch einbauen müssen. Tut's dabei ein unset() ? Free() gibts ja bei PHP nicht...

Kennst Du vielleicht Tools, die den Speicherverbrauch unter PHP analysieren? Ich hab den Profiler vom Zend Studio, aber misst nur die Zeit und gibt zum Speicherverbrauch überhaupt keine Info.

Gruß Horst

[Rolidor]

Hallo.
Ich mache mir inzwischen keinen Kopf mehr um das Speichermanagement. Das hängt offensichtlich viel zu sehr von der Konfiguration/Version des Servers, PHP und dem Betriebssystem ab. Ein Skript, das unter zwei, drei Installationen problemlos läuft kann unter einer weiteren einfach deshalb versagen, weil es nicht schnell genug an Speicher kommt und es auf einen timeout läuft. Auf die Einstellungen, die dieses Problem beheben könnten habe ich bei einem Provider normalerweise keinen Einfluss.
Daher sehe ich einfach zu, nicht mehr benötigte Speicherinhalte sofort wieder los zu werden. Mysql_free_result() und unset() funktionieren leider aber nicht immer in dem Sinn, das der allozierte Speicher sofort wieder zur Verfügung steht. Habe gute Erfahrung damit gemacht, Arrays als leer (=array()) und anderen Variablen und Objekten leere Strings zuzuweisen (='').
Ein Tool für die Analyse des Speicherbedarfs von PHP kenne ich nicht. Gab hier allerdings schon öfter mal einen Thread, dass der Apache unter Win2k alle Ressourcen frisst.

Gruß
Rolo

[borschtel1]

Ahh, das ist der erste Thread, den ich genau zu diesem Fehler finde.

Ich habe nämlich genau das gleiche Problem mit meiner Installation.

Ich denke der Fehler liegt an irgendeiner Fehlkonfiguration. Das mit der Freigabe des Speichers kann ich mir nicht wirklich vorstellen.

Wenn jemand eine Lösung zu diesem Problem findet, dann bitte poste es hier.

Danke
ThorstenT

[hmundt]

Wir können ja unsere Einstellungen mal vergleichen.
Welche Apache-Module und php-Extensions setzt Du denn ein?

[borschtel1]

Ja gute Idee. Hier sind meine Einstellungen.

Apache Module:

mod_access
mod_actions
mod_alias
mod_asis
mod_auth
mod_autoindex
mod_cgi
mod_dir
mod_env
mod_include
mod_log_config
mod_mime
mod_rewrite
mod_setenvif
mod_deflate
php4_module


PHP Extensions:

php_curl
php_gd2
php_ming
php_mssql
php_openssl
php_pdf
php_sqlite
php_xslt
php_zip


Gruß
ThorstenT

PS: Habe jetzt noch einen anderen Tipp gefunden und mal ausprobiert. Wenn es was bringt, dann gebe ich Bescheid.

It works better if I set the Apache MaxRequestsPerChild to about 10000
instead of 0. It seems to be some kind of apache or php memory leak problem
and now does apache automatically respawns the child process after some
time.

"Stefan Edstrom" <baldrick@vcdhelp.com> wrote in message
news:arrb6o$8ns$1@hudsucker.umdac.umu.se...
> I'm running Apache 1.3.26, PHP 4.4.0-dev(as a sapi module) and
> MySQL3.23.51 on a dual processor(AMD MP 1800) Windows 2000 server with 1
> GB RAM. PHP causes this fatal error every 5-15 minute:
>
> FATAL: erealloc(): Unable to allocate 1441792 bytes
>
> and it causes Apache to respawn and kills all current connections(the
> apache child process dies and restarts). I have tried with older PHP
> versions(4.2.3,4.2.4-dev,4.3RC1) and with no extra modules but with same
> result. I use the php.ini-recommended with no changes.Win2k have about 400
> MB free memory when it happens so it can't be a memory problem or?Any
ideas?
> /Baldrick at www.vcdhelp.com
>
>

http://216.239.59.104/search?q=cache:Rg ... n&ie=UTF-8

[borschtel1]

So, die MaxRequestsPerChild haben keine Veränderung gebracht.

Ich habe aber folgendes rausgefunden.
Mit dem Beispielscript von http://nl.php.net/manual/en/control-str ... eclare.php kann man den Fehler reproduzieren.

Vielleicht kann damit ja jemand etwas anfangen.

Das Problem liegt an der Funktion "register_tick_function()".
Nur leider benutze ich in meinen Skripten nirgends diese Funktion. Es muss also noch weitere Ursachen geben.

Gruß
ThorstenT

PS: Desweiteren habe ich gelesen, dass bei der Benutzung von PHP als CGI dieses Problem nicht mehr auftauchen soll. Habe es aber noch nicht getestet.

[nemesis]

Wenn man die MaxRequestsPerChild auf einen niedrigen Wert setzt, sollten die Probleme eigentlich nicht auftreten. Da Apache seine "Kinder" nach eben der festgelegten Anzahl von Anfragen beendet, und nen neuen dafür erstellt, der keine altlasten von mod_php mitschleppt.
Php 4.x wurde nicht für einen Multithreaded Apache 2 Server entwickelt.
Daher funktioniert die CGI Version oftmals besser als mod_php
Php 5.0.0 muss halt eben leider erstmal zeigen, wie stabil es ist

[hmundt]

Hallo zusammen,

sorry, ar ein paar Tage unterwegs, konnte deswegen nicht posten.

@ThorstenT:
Den "MaxRequestsPerChild"-Workaround habe ich auch schon probiert. Problem dabei ist, dass wenn der Apache einen neuen Kind-Prozess startet, der Anwender ca. 10-15 Sekunden warten muss, bis sein request beantwortet ist. Technisch funktioniert das, aber meistens schlägt vorher der psyschologische timeout zu. Wenn man das alle 10000 Requests oder so macht, mag das noch gehen, bei mir tritt aber das alloc-Problem manchmal schon nach 1000 requests oder so auf.

Ich setze übrigens folgende Module ein:
LoadModule access_module modules/mod_access.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule asis_module modules/mod_asis.so
LoadModule dir_module modules/mod_dir.so
LoadModule env_module modules/mod_env.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule php4_module "/xampp/apache/bin/php4apache2.dll"
LoadModule ssl_module modules/mod_ssl.so

und folgende php Extensions:
extension=php_dbx.dll
extension=php_domxml.dll
extension=php_mssql.dll
extension=php_xslt.dll

Die Schnittmenge mit Deinen php extensions besteht also aus mssql und xslt. Ich hatte zuerst xslt im Verdacht, weil das sehr speicherintensiv werden kann, aber das ist es nicht. Ich kann das Verhalten reproduzieren, wenn ich es nicht einsetze. Mssql brauche ich so der so.
Da das ganze auch unter Apache 1.3 absolut stabil funktionierte, vermute ich, dass es entweder am Apache selbst oder aber am php-Modul liegt :-(


@nemesis: Die Idee mit dem CGI hatte ich auch schon, mir fehlte aber die Zeit, es auszuprobieren.
Hast Du Erfahrung damit? Gibt es evtl. irgendwelche Seiteneffekte, also dass dann zwar der Fehler nicht mehr auftritt, aber dafür was anderes nicht mehr funktioniert?
Wie ist die Performance der CGI-Version im Vergleich zum Apache-Modul?

Gruß Horst

[nemesis]

Die Performance ist prinzipbedingt langsamer als das Apache-Modul.
Aber solange du es nicht auf einem Produktivsystem mit schlechtem Rechner im I-net betreiben willst mit vielen Anfragen, tuts cgi auch. War schließlich früher das einzigste was es gab...
Und 10-15sec sind doch etwas zu übertrieben.... kann es sein dass dein Win swapt, oder was anderes Prozessorleistung zieht?

[hmundt]

Die 10 bis 15 Sek. treten nicht bei jedem Request auf, sondern wenn ich die maxRequetsPerChild-Directive z.B. auf 1000 setze und dann beim 1000. Request der Apache seinen Kindprozess beendet und neu startet. Das dauert anscheinend so lange.
Danach werden alle Requetst wieder mit normaler Performance benatwortet. Bis zum 2000., der dann wieder lange dauert usw.
Swappen sollte das System eigentlich nicht. Der Apache-Prozess greift sich zwar schon bis zu 300 MB, aber bei 1 GB RAM dürfte das nicht allzuviel ausmachen (sonst läuft auf der Maschine nichts, und das ganze Windows-Server-Geraffel ist abgeschaltet).

[nemesis]

Windows swapt leider auch wenn genügend RAM vorhanden ist. Habe es bei mir deshalb deaktiviert. Auf wieviele Childs haste den Apache denn eingestellt? Wenns nur einer ist, isses klar
Ansonsten übernimmt ja einer der anderen Childs den Request.