RE: [PHP-DEV] FastCGI limit memory
| From: | Andi Gutmans | Date: | Tue, 06 Feb 2007 05:06:59 +0000 |
| Subject: | RE: [PHP-DEV] FastCGI limit memory | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-27846@lists.php.net to get a copy of this message | ||
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:pierre.php@gmail.com]
> 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 <r@roze.lv> 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
>