22 messages in ru.sysoev.nginxRe: php-fastcgi and memory leaks
FromSent OnAttachments
Phillip B OldhamMar 25, 2008 2:43 am 
Reinis RozitisMar 25, 2008 4:30 am 
Phillip B OldhamMar 25, 2008 4:47 am 
Yordan GeorgievMar 25, 2008 1:01 pm 
Phillip B OldhamMar 26, 2008 1:12 am 
ThomasMar 26, 2008 2:43 am 
Phillip B OldhamMar 26, 2008 3:00 am 
ThomasMar 26, 2008 3:08 am 
Corey DonohoeMar 26, 2008 7:18 am 
Yordan GeorgievMar 26, 2008 7:27 am 
Rob SchultzMar 26, 2008 12:14 pm 
Phillip B OldhamMar 28, 2008 2:36 am 
ThomasMar 29, 2008 1:41 pm 
Reinis RozitisMar 30, 2008 5:56 pm 
ThomasMar 31, 2008 4:41 am 
Phillip B OldhamMar 31, 2008 4:54 am 
Grzegorz NosekMar 31, 2008 5:06 am 
Phillip B OldhamMar 31, 2008 5:27 am 
Grzegorz NosekMar 31, 2008 5:40 am 
Phillip B OldhamMar 31, 2008 5:46 am 
Grzegorz NosekMar 31, 2008 6:33 am 
Phillip B OldhamMar 31, 2008 6:44 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: php-fastcgi and memory leaksActions...
From:Phillip B Oldham (phil@public.gmane.org)
Date:Mar 25, 2008 4:47:50 am
List:ru.sysoev.nginx

Thats interesting. A diff would be useful if you have one.

What's the best way to set these settings? At the moment I'm exporting them just before I use spawn-fcgi (from lighttpd), but even though I've set it to a low number (10) I don't think its being honoured. I'm running CentOS5, if that's any help.

If I can't find a suitable work-around for this I may have to switch to apache with php compiled in - something I don't really want to do as I'm finding working with nginx to be a great experience.

Reinis Rozitis wrote:

Thats a common issue (at least for me). Although php leaks itself with every version less there are still quite a bunch of extensions outside that dont handle the memory bits the right way.

As a workarround I use this patch http://devzone.zend.com/content/patch/pat38.txt

Its pretty old and made for php4 but with little tweaks you can apply also to php5 (I could make a diff and throw in here). The basic idea is you have an extra setting PHP_FCGI_MAX_RAM_MB - you can limit at what memory usage the php child should handle the last request and die (so the master process can spawn a new one - similar to PHP_FCGI_MAX_REQUESTS ).

This solution is better because you dont accidently kill a process which is in a middle of generating a response.

rr

----- Original Message ----- From: "Phillip B Oldham" <phill-ABPfyfql6ydQOjYTieCOMbyq0pUa53/3@public.gmane.org> To: <nginx-nofU2znGi42HXe+LvDL@public.gmane.org> Sent: Tuesday, March 25, 2008 11:44 AM Subject: php-fastcgi and memory leaks

Further to the email below, I'm still having problems with PHP5 fastcgi and nginx. I'm finding that php slowly takes up 100% of the available memory and starts to drop connections at around 70%. At the moment I've got monit restarting the fastcgi processes when the memory usage hits 70%, but this isn't optimal as the scripts I'm running shouldn't take anywhere near that on a virtual server with 300MB dedicated ram.

I'm wondering whether anyone else has come across the same problem running php5 fastcgi who has managed to find a fix or work-around?

--

*Phillip B Oldham* The Activity People phill-ABPfyfql6ydQOjYTieCOMbyq0pUa53/3@public.gmane.org
<mailto:phill-ABPfyfql6ydQOjYTieCOMbyq0pUa53/3@public.gmane.org>

------------------------------------------------------------------------

*Policies*

This e-mail and its attachments are intended for the above named recipient(s) only and may be confidential. If they have come to you in error, please reply to this e-mail and highlight the error. No action should be taken regarding content, nor must you copy or show them to anyone.

This e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium, and we have taken steps to ensure that this e-mail and attachments are free from any virus. We must advise that in keeping with good computing practice the recipient should ensure they are completely virus free, and that you understand and observe the lack of security when e-mailing us.

begin:vcard fn:Phillip Oldham n:Oldham;Phillip org:The Activity People;Systems Development email;internet:phill-ABPfyfql6ydQOjYTieCOMbyq0pUa53/3@public.gmane.org title:Chief Programmer tel;work:0870 162 4847 x-mozilla-html:TRUE url:http://theactivitypeople.co.uk/ version:2.1 end:vcard