Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27845
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.233 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=obgSIOeGKIi5B5RLMF7mzvtCYAKtZc8U/96ktoWhPqOdivODpW1fZZgwD2EBKFMm7yrKvYVm5UyMNFE3uYMXyGaZgN6qVCqO/Tqvd34A/B5UWwiF8An6A2psM68I+Nd+iQapEJ44wzF8KvxF3+Ff3oUs8s5i6E1Ff/Q+iWkApTc=
Message-ID: <fe05d1540702051653w3d74f3ddodbb1fc439603261f@mail.gmail.com>
Date: Tue, 6 Feb 2007 01:53:33 +0100
To: "Reinis Rozitis" <r@roze.lv>
Cc: internals@lists.php.net
In-Reply-To: <015701c74973$32b61950$698df657@wired>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <006d01c74961$ae34f4f0$698df657@wired>
	 <fe05d1540702051237t35c5147av94a78e684a6cac61@mail.gmail.com>
	 <010c01c7496b$33d9d270$698df657@wired>
	 <fe05d1540702051340g54d7f4cfo9627f70e48f3ff4f@mail.gmail.com>
	 <015701c74973$32b61950$698df657@wired>
Subject: Re: [PHP-DEV] FastCGI limit memory
From: pierre.php@gmail.com (Pierre)

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