Hallo, Seit dem ich das mldonkey web-interface GMUI auf dem dem apache betreibe kann ich ihn mehr oder weniger reproduzierbar Amok laufen lassen. Gmui ist ein php script welches mysql verwende, um meherere Benutzer mit verschiedenen Rechten auf den mldonkey loslassen zu koennen. Nach bestimmten Aktionen, z.B umbenenen von downloads oder downloaden von Dateien aus dem "incoming" kann es hier passieren, dass das Script beim beim Laden einer neuen Seite im Browser haengen bleibt. Dabei faengt das apache-child an den ganzen RAM aufzuessen bis nichts mehr geht und der Kernel sich nach 1,2 Stunden herablaesst den betreffenden httpd2-prefork zu killen: Feb 5 02:16:10 h52614 kernel: Out of Memory: Killed process 13576 (httpd2-prefork). Feb 5 02:16:10 h52614 kernel: httpd2-prefork: page allocation failure. order:0, mode:0xd2 Feb 5 02:16:10 h52614 kernel: Call Trace: [...] Ersmal zum Verstaendnis: Muesste Apache ein (eventuell) kaputtes php script verkraften koennen oder ist es normal das er so immer weiter RAM verbraet? (das script liegt uebrigens in einem userdir) Dummerweise habe ich nicht viel Ahnung von php: Wie kann ich denn feststellen wo genau im Script er stecken bleibt? Was koennte ich machen um das herauszifinden, wenn es das das naechste mal passiert? Hier noch ne Zeile aus den apache logs: 212.xxx.xxx.xxx - west [05/Feb/2005:01:03:09 +0100] "GET /%7Edonkey/GMUI/index.php?CORE_OP=umanage HTTP/1.1" 200 3137 "h ttp://inline.xyz.net/%7Edonkey/GMUI/index.php?CORE_OP=vd" "Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)" Der apache war ab dieser Zeit etwa nicht mehr erreichbar Das interessannte ist hier, das diese Zeile zeitlich total verspaetet in die logs geschrieben wurde - davor gibt es einige Zeilen von 2:16 - 2:20 Uhr (als der server so langsam wieder erwachte). Also vermute ich dass dies das letzte ist was uns der gekillte httpd2-prefork mitteilen wollte. Wird jemand schlau draus? ach ja, SuSE 9.1, apache-2.0.49-27.18.3, php4-4.3.4-43.22 cu, Ruediger
Hallo Rüdiger, hallo Leute, Am Montag, 7. Februar 2005 04:49 schrieb Ruediger Meier:
Seit dem ich das mldonkey web-interface GMUI auf dem dem apache betreibe kann ich ihn mehr oder weniger reproduzierbar Amok laufen lassen. [...] kann es hier passieren, dass das Script beim beim Laden einer neuen Seite im Browser haengen bleibt. Dabei faengt das apache-child an den ganzen RAM aufzuessen bis nichts mehr geht und der Kernel sich nach 1,2 Stunden herablaesst den betreffenden httpd2-prefork zu killen:
Wie sehen Deine PHP-Einstellungen bezüglich memory_limit, max_input_time und max_execution_time aus? (/etc/php.ini oder <?php phpinfo() ?> ) [...]
Ersmal zum Verstaendnis: Muesste Apache ein (eventuell) kaputtes php script verkraften koennen oder ist es normal das er so immer weiter RAM verbraet? (das script liegt uebrigens in einem userdir)
Normal ist es definitiv nicht.
Dummerweise habe ich nicht viel Ahnung von php: Wie kann ich denn feststellen wo genau im Script er stecken bleibt?
Füge genügend error_log()-Aufrufe (mit Angabe der Position o. ä.) ins Script ein ;-) Genaue Syntax siehe PHP-Doku. Außerdem solltest Du log_errors in der /etc/php.ini aktivieren (anschließend Apache neu starten!)
Was koennte ich machen um das herauszifinden, wenn es das das naechste mal passiert?
Guck ins Apache-ErrorLog statt ins Access-Log ;-) Gruß Christian Boltz -- Bei Windows hat man Mailreader, der alles kann. Bei Linux hat man ein MUA, das eigentlich gar nichts kann, aber das verdammt gut. [Bernd Brodesser in suse-linux]
On Monday 07 February 2005 21:07, Christian Boltz wrote:
Wie sehen Deine PHP-Einstellungen bezüglich memory_limit, max_input_time und max_execution_time aus? (/etc/php.ini oder <?php phpinfo() ?> )
max_execution_time = 30 max_input_time = 60 memory_limit = 8M
Ersmal zum Verstaendnis: Muesste Apache ein (eventuell) kaputtes php script verkraften koennen oder ist es normal das er so immer weiter RAM verbraet? (das script liegt uebrigens in einem userdir) Normal ist es definitiv nicht.
Koennte es theoretsich auch mit dem P4 optimierten Kernel zusammen haengen? Oder kann man die httpd2-prefork Prozesse nicht insgesamt irgendwie beschraenken? Wenn wegen des Apachen anfaengen wird zu swappen, koennte der auch gleich gekillt/restarted werden, da der Server bei mir primaer anderes zu erledigen hat - obwohl es ja nicht schoen ist.
Dummerweise habe ich nicht viel Ahnung von php: Wie kann ich denn feststellen wo genau im Script er stecken bleibt?
Füge genügend error_log()-Aufrufe (mit Angabe der Position o. ä.) ins Script ein ;-) Genaue Syntax siehe PHP-Doku.
hm ;) eigentlich wollte ich ja nur das script benutzen, ohne es zu verstehen. Ich werde mich mal beim Author melden, voerst habe ich einiges heraus genommen was meiner Meinung nach den Crash verursacht hat.
Außerdem solltest Du log_errors in der /etc/php.ini aktivieren (anschließend Apache neu starten!)
Was koennte ich machen um das herauszifinden, wenn es das das naechste mal passiert?
Guck ins Apache-ErrorLog statt ins Access-Log ;-)
Im error log steht nichts auffaelliges. cu Ruediger
Hallo Rüdiger, hallo Leute, Am Mittwoch, 9. Februar 2005 04:33 schrieb Ruediger Meier:
On Monday 07 February 2005 21:07, Christian Boltz wrote:
Wie sehen Deine PHP-Einstellungen bezüglich memory_limit, max_input_time und max_execution_time aus? (/etc/php.ini oder <?php phpinfo() ?> )
max_execution_time = 30 max_input_time = 60 memory_limit = 8M
Also die (eigentlich?) harmlosen Default-Einstellungen.
Ersmal zum Verstaendnis: Muesste Apache ein (eventuell) kaputtes php script verkraften koennen oder ist es normal das er so immer weiter RAM verbraet? (das script liegt uebrigens in einem userdir)
Normal ist es definitiv nicht.
Koennte es theoretsich auch mit dem P4 optimierten Kernel zusammen haengen?
Nichts ist unmöglich, aber das wäre nicht meine erste Baustelle ;-)
Oder kann man die httpd2-prefork Prozesse nicht insgesamt irgendwie beschraenken? Wenn wegen des Apachen anfaengen wird zu swappen, koennte der auch gleich gekillt/restarted werden, da der Server bei mir primaer anderes zu erledigen hat - obwohl es ja nicht schoen ist.
man ulimit ;-) Apache selbst AFAIK hat auch ein paar Einstellungen zur Speichernutzung usw. - aber falls Du wirklich auf einen Bug gestoßen sein solltest, ist ulimit die deutlich robustere Lösung.
Dummerweise habe ich nicht viel Ahnung von php: Wie kann ich denn feststellen wo genau im Script er stecken bleibt?
Füge genügend error_log()-Aufrufe (mit Angabe der Position o. ä.) ins Script ein ;-) Genaue Syntax siehe PHP-Doku.
hm ;) eigentlich wollte ich ja nur das script benutzen, ohne es zu verstehen.
*g* error_log()-Aufrufe sind wirklich nicht schwer zu programmieren.
Ich werde mich mal beim Author melden, voerst habe ich einiges heraus genommen was meiner Meinung nach den Crash verursacht hat.
Dann bin ich mal gespannt, ob es hilft ;-) Gruß Christian Boltz -- Wenn Du Dich weiter doof stellst, dann: Warning: loading builtin philipp-cool-down.dll. Couldn't be loaded! Expect trouble!!! [Philipp Zacharias in suse-linux]
participants (2)
-
Christian Boltz
-
Ruediger Meier