php-fastcgi and memory leaks

Phillip B Oldham phill at
Tue Mar 25 14:48:13 MSK 2008

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 
> 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 
> 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 at>
> To: <nginx at>
> 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 at <mailto:phill at>



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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phill.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <>

More information about the nginx mailing list