Don't the FastCGI processes inherit memory limits from their parent? (assuming you're not running standalone FastCGI which almost noone does).
Andi > -----Original Message----- > From: Pierre [mailto:[EMAIL PROTECTED] > Sent: Monday, February 05, 2007 4:54 PM > To: Reinis Rozitis > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] FastCGI limit memory > > On 2/5/07, Reinis Rozitis <[EMAIL PROTECTED]> wrote: > > > I'm not sure that you are looking at the right place to solve the > > > problem. If the leaks are in phpinfo (or in memory allocated by > > > php), then maybe (really not sure). > > > > > > But if the leaks are in IM as their extension does not use php > > > memory manage, it is not something fixable by php or > anything else but IM. > > > > Pierre you are getting me totally wrong. > > I dont really care for this particular ImageMagick(Wand) or even > > phpinfo leak at all :) > > Yes, that I got that, I only liked to say that this patch > will not help that much, only to be sure about what is your goal. > > > What I am talking about is a feature which similar as > 'memory_limit' > > (inside one script runtime) limits maximum memory usage for a long > > running php child (if spawned with the -b option (external > FASTCGI Server mode)). > > At the moment the only option to avoid memory leaks is to set > > PHP_FCGI_MAX_REQUESTS after which the child dies and a new > is spawned. > > Still the memory usage can grow (as example in this case) way too > > quick to actually hit the request limit, which may bring > the system in OOM state. > > > > The patch was provided for 4.x branch > > http://www.zend.com/zend/week/pat/pat48.txt > > So I wanted to get some feebacks (without filling the > feature request > > at bugs.php.net which I apologise for) if its something > worth to implement. > > Probably to hear something from Dmitry. > > The best place to have a definitive opinion would be to > report a bug, put a link to the patch and assign it to > Dmitry. Having a bug report will also help to do not get this > patch lost somewhere in the www. > > Please note that 4.4 is frozen, there is no chance to get > such patches in it, but maybe in 5.2.2. > > > > Keep an eye on the current 2.1.0 development, it will be > really fast > > > :) > > > > Is the source allready available for testing? > > Those 3 remaining tasks in roadmap didnt look problematic at this > > state (though I suppose there are more issues).. > > All sources are in CVS (see the Downloads page), I'm just > beginning the 2.1.0 changes in CVS (2.0.34-final is due for > Wednesday) :). > > --Pierre > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
