[Vienna-pm] mod_perl + speicherproblem

[max demmelbauer]

so.. ich hab jetzt ein wenig mehr rausgefunden:

* die 120 MB kommen zustande weil am apache 3 virtualhosts definiert  
sind, jeweils mit
	
	PerlOptions +Parent

	d.h. es passt eh, weil 3 x 40MB is eben 120.. eh klar, aber hab  
einfach nicht dran gedacht...

* ich logge jetzt alle 5 sekunden den output von ps -aux, und bin zu  
dem ergebnis gekommen, dass, wenn der server crached, alle apache  
instanzen endlos speicher produzieren. d.h. es ist nicht nur ein  
bestimmer call, sondern ab einem gestimmten zeitpunkt verfaengt sich  
jeder perl prozess irgendwo. vielleicht ist es der mysql-driver..  
keine ahnung. (irgendwie koennte es auch noch JSON::XS sein.. hab ich  
irgendwie so im gefuehl)

* weiters hat das "MaxRequestsPerChild  100" schon sehr viel gebracht.  
war kein absturz seit der umstellung.

* zum setup, es ist eh schon so, dass wir einen perlbal vorgeschalten  
haben, und der apache wirklich nur die dynamischen requestes  
durchgereicht bekommt.

vielen dank mal fuer eure hilfe, hoffenlich find ich bald  
(wahrscheinlich mal per zufall) das eigentliche problem.

lg. max.



On 22.05.2008, at 18:45, Marinos Yannikos wrote:

> max demmelbauer schrieb:
>> ./webtek console (was einfach nur den ganzen applikation-code  
>> laedt, und
>> eine command-zeile bereitstellt) bei mir lokal auf einem IC2D 20MB,  
>> und
>> auf der athlon64 debiankiste 40MB.
>
> 32bit vs. 64bit Perl wohl (8 byte pointer, alignment, ...), obwohl
> Faktor 2 da eher der worst case sein sollte.
>
>> ich versteh einfach nicht:
>>
>>    - erstens: wieso schon mal der unterschied von 20MB zwischen den
>> systemen
>>    - zweitens: wieso braucht der apache prozess nochmal 80MB mehr  
>> fuer
>> denselben code?
>>    - der unterschied zw test/live betrieb im speicher ist auch schon
>> direkt nach dem starten (also unabhaengig von den requests)
>
> Dürfte dann wohl auch auf 32/64 bit zurückzuführen sein, evtl. auch
> andere Perl-Version?
>
>>    - mir ist es auch egal, der prozess kann soviel brauchen wie er
>> will! aber wenn der server immer wieder crached ist es halt sch**e..
>> grrr...
>
> Wir haben schon lange ein Setup wie in
> http://perl.apache.org/docs/1.0/guide/strategy.html#One_Plain_Apache_and_One_mod_perl_enabled_Apache_Servers
> beschrieben, damit können wir die mod_perl Apaches auf 10-15  
> limitieren
> und trotzdem einige 100 Requests parallel abarbeiten (auf statische
> Daten z.B.).
>
> Ansonsten kannst du wohl auch mal FastCGI anschauen, das trennt die
> fetten Perl-Prozesse sauberer vom Apache als mod_perl. Ich warte
> einstweilen auf ein Perl mit Speichermanagement, das die letzten 30
> Jahre Forschung in dem Gebiet nicht verschlafen hat. ;-)
> (zur Not auch eine Version mit drangepfrimmeltem
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/)
>
>> aber irgendwo ist ganz sicher ein fehler bei uns im code, und der  
>> bringt
>> mich an den rand des nervenzusammenbruchs, wenn ich am wo-ende 5x den
>> server restarten muss ;)
>
> Du kannst ja mal die Apache-PIDs mitloggen
> (http://httpd.apache.org/docs/1.3/mod/mod_log_config.html - %P) und  
> dann
> im access.log nachschauen, welche Requests einen bestimmten Prozess so
> aufgeblasen haben. Vielleicht findest du ja ein schönes memory leak  
> (ist
> bei mod_perl sehr einfach zu erzeugen, nachdem die globalen  
> Variablen ja
> bleiben).
>
>> eine vermutung ist auch ein `cmd` aufruf im applikationscode (darf/ 
>> soll
>> ich sowas im mod_perl env aufrufen?)
>
> http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl
> Gilt natürlich auch für backticks...
>
> MfG,
> -mjy
> -- 
> Dipl.-Ing. Marinos Yannikos, CEO
> Preisvergleich Internet Services AG
> Obere Donaustrasse 63, A-1020 Wien
> Tel./Fax: (+431) 5811609-52/-55
> Handelsgericht Wien - FN 197241K - Firmensitz Wien
> _______________________________________________
> Vienna-pm mailing list
> Vienna-pm at pm.org
> http://mail.pm.org/mailman/listinfo/vienna-pm