Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48098
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.216 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=ISL2eXoWQoH6mwChwBp6HN62V9aJhVGpQiAZmrdeiqEzUz3uiMTdqUg0tFWL+ZqDhl
         ncWNeOUGiIrIkT1NxXW8DCsfunToC3M6L/7mENYtKD3uwnhosh4LDDDk5dHAW54IkFIo
         I2T38CfVaGLyh3cw/cBYBiP+9U/qEO4C5YHz0=
MIME-Version: 1.0
In-Reply-To: <4BD5DF5F.5050603@daylessday.org>
References: <j2g7b32197c1004060011n5b78f062kf05bde7d0b2b9993@mail.gmail.com>
	 <4BD564A9.2060000@daylessday.org>
	 <n2g3bea96c41004260308m13b1571fn321d86afdf520297@mail.gmail.com>
	 <4BD57525.50803@daylessday.org>
	 <t2j3bea96c41004260418p6eb184bco599bc352be517433@mail.gmail.com>
	 <36701B7BE4054FB3A72CFFB6B8A81DF5@KD5>
	 <n2g7b32197c1004260820zb1fa39bdvfb0bf8c13ff61f83@mail.gmail.com>
	 <4BD5B521.6070404@daylessday.org>
	 <t2ob54d0abe1004261125oa6009cc3v7214f126544bc30a@mail.gmail.com>
	 <4BD5DF5F.5050603@daylessday.org>
Date: Mon, 26 Apr 2010 21:12:53 +0200
Message-ID: <r2nb54d0abe1004261212p8e37b0bke591c3391438c6f8@mail.gmail.com>
To: Antony Dovgal <tony@daylessday.org>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6d9728a52cc970485289059
Subject: Re: [PHP-DEV] One suggestion to PHP-FPM
From: tyra3l@gmail.com (Ferenc Kovacs)

--0016e6d9728a52cc970485289059
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 26, 2010 at 8:45 PM, Antony Dovgal <tony@daylessday.org> wrote:

> On 26.04.2010 22:25, Ferenc Kovacs wrote:
> >
> >     If you have any problems with third-party libs leaking memory not
> >     accounted by Zend MM, you can always lower
> >     the max_requests parameter in your config file.
> >
> >     That's all. Problem solved.
> >
> >
> > Its not the best idea. If you feed imagick with random images, then your
> > memory leak will be pretty random.
>
> Random actions end up with random results.
> Thank you, captain!
>
>
You are so kind. I'm so proud of you!!
But sticking with a real world scenario:
you have to convert what they upload, and thats pretty random.


> > If you set the max_requests low, then you will see fewer memory limit
> > exhausted, but the overall overhead will be much bigger, because you
> > will respawn a decent amount of worker unnecessary
>
> Respawn overhead is almost zero if you compare it to the overall cost of
> executing, say, 1000 of scripts.
>
>
if you have to set the max_request to for example 10, because of the aborted
scripts, then it is not zero

> > if you set it high,
> > the overhead will be lower, but you will see much more aborted scripts.
>
> Aborted scripts?
> Since when do they abort when some third-party lib leaks some memory?
>
>
When the leaked memory causes a memory limit was exhausted fatal error?


> > With the ability, to respawn processes based on the memory allocation,
> > you could serve the maximal amount of request, without unnecessary
> > respawn or aborted scripts.
>
> My point was and is that with Zend MM enabled, it takes care of any leaks
> that might
> happen in PHP and they won't accumulate, as each time a request starts, we
> start with
> clean Zend MM pool.
>

Yeah, but if you followed the thread, you can see that the external libs are
the problem.


> In order to prevent leaks happening in third party libraries (which Zend MM
> is unable
> to control) to blow up your PHP processes, you need to use the non-portable
> solution I
> implemented in memtrack, not the one proposed in the original patch.
>

http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/getrusage.c?rev=1.18;content-type=text%2Fx-cvsweb-markup


> And even that is not required as you can always adjust max_requests and
> live happily ever after.
>
>
Yeah, sure. :)

Tyrael

--0016e6d9728a52cc970485289059--