Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47953
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.219 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=xiaYaONB8sQY9xSKUvMtNu7fboSz3S9ho3sQcxv7R0b+j9JQhgwKMuVQlSHjT8cXCw
         a0DZLYuETv4cCs/81ksbnDtxKKkEB1K94eLVf/SQsBmWOOJsMC+e1eoetgzRdWTVlAtN
         g+BHt/b70Tv3TejujjIWBEb4aPHodxajEd3x4=
MIME-Version: 1.0
In-Reply-To: <g2obd9320b31004150028gb77611a9qed357e180a3b60c@mail.gmail.com>
References: <j2g7b32197c1004060011n5b78f062kf05bde7d0b2b9993@mail.gmail.com>
	 <p2z3bea96c41004140029pe2e65660rb15c56e1040ca6f6@mail.gmail.com>
	 <j2n3bea96c41004140201ia1cffc4fr1c191a343af73931@mail.gmail.com>
	 <4BC58D10.4050609@lerdorf.com>
	 <y2x7b32197c1004141858sa672049dxda3e8f1404e97b04@mail.gmail.com>
	 <y2m3bea96c41004142303x190f5b45hc15952527b13a446@mail.gmail.com>
	 <o2rb54d0abe1004150009p3c1142ben2b415e1e429179bc@mail.gmail.com>
	 <g2obd9320b31004150028gb77611a9qed357e180a3b60c@mail.gmail.com>
Date: Thu, 15 Apr 2010 09:45:39 +0200
Message-ID: <w2ub54d0abe1004150045z66fac5cdrc638733a26627fd6@mail.gmail.com>
To: Michael Shadle <mike503@gmail.com>
Cc: php-dev <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=000325557e1e53844f048441aedd
Subject: Re: [PHP-DEV] One suggestion to PHP-FPM
From: tyra3l@gmail.com (Ferenc Kovacs)

--000325557e1e53844f048441aedd
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 15, 2010 at 9:28 AM, Michael Shadle <mike503@gmail.com> wrote:

> On Thu, Apr 15, 2010 at 12:09 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
> > My suggestion is more about releasing the allocated memory as soon as
> > possible. That is, this option is similar to "max_requests".
> > PHP-FPM would kill the PHP process if the requests a process handled
> > exceed max_requests, and similarly, PHP-FPM should kill the PHP
> > process whose memory usage exceeds "exit_on_memory_exceeds".
> >
> > So one of your lib (for example imagick) leaks memory, on the long run,
> it
> > will exhaust the memory limit, and will kill a totaly request.
> > You can set that how many request should be served with one worker, but
> you
> > can't soft limit it's memory consumption.
> > This is what the patch does:
> > if you set the hard limit: (memory_limit) you can guarante that no
> process
> > will use more memory, because if it tries, it will fail.
> > and you can set soft limit, if that reached, the process will die and
> > respawn after finishing the current request.
>
> Sounds like you more or less want a "request_terminate_timeout" type
> of functionality but based on memory. Since set_time_limit() and other
> things in PHP don't seem to force kill the process. So PHP-FPM
> forcefully terminates the process based on the actual wall clock
> seconds.
>
> Unfortunately I don't know how PHP-FPM handles it's worker pool, but as far
as with goes with apache php_prefork and fastcgi you can limit how many
request should one worker process, but it will be a good option to limit the
process lifetime based on the memory consumption.

> I'm thinking you're hoping for the same thing to be possible but for
> memory limits per-process? I would say that could be cool, either per
> pool or per child somehow.

Yeah.

> No clue if it is possible, but that would
> be a great way to limit the usage *forcefully* - helpful on lower
> resource machines (like a vps...)
>
Its possible, the patch adds this functionality to the php-fpm.
but I started thinking about, that the possibility to terminate (I mean
really terminate, not just abort the execution of the current request) the
worker would be a good feature in the php language itself.

Tyrael

--000325557e1e53844f048441aedd--