Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47948
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.221.173 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=GHkseR9QrFnYqLDgBjfkTsfaNF2oS7BNqR48S+reOfFN3acPJLwPKRaonr7Mc4fCov
         JimtASgZQU7pktaXQ9gHMvsI6PBCm6yakeF21OnmX6NWrmm2/6RD1WLPejRr2Yw4Vd5t
         2KvqxWcRF8J79vtX62e6q6pJQ1i8RgIEDe//Y=
MIME-Version: 1.0
In-Reply-To: <y2m3bea96c41004142303x190f5b45hc15952527b13a446@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>
Date: Thu, 15 Apr 2010 15:15:14 +0800
Message-ID: <j2l7b32197c1004150015ra89cc72fk86fb8b1f79d192fd@mail.gmail.com>
To: =?ISO-8859-1?B?Suly9G1lIExveWV0?= <jerome@loyet.net>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=001636137aa292c201048441419d
Subject: Re: [PHP-DEV] One suggestion to PHP-FPM
From: tly.phpfans@gmail.com (looyao teng)

--001636137aa292c201048441419d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

When allocate memory from PHP memory heap, PHP runtime check the
memory_limit which
in  php.ini, but this can only give a error message and  not to continue to
excute php code, it can't
control the PHP-FPM child process, my idea is that when the  memory out of
limit we set,
kill this child process, we know, though PHP runtime can free its heap
memory, but  it can't give
it back to the system, so we can kill this child process and ensure the
system have enough free
memory. We do check the memory limit is to control the process.

2010/4/15 J=C3=A9r=C3=B4me Loyet <jerome@loyet.net>

> 2010/4/15 =E6=BB=95=E8=B7=AF=E9=81=A5 <tly.phpfans@gmail.com>:
> > We check error log after our server crashed, and we found that php heap
> > memory is out of limit,
> > so I think imagick use emalloc to allocate php heap memory, to check th=
e
> > zend_memory_usage is
> > not a method for imagick, other circumstances which occupy huge memory
> can
> > use this method to
> > ensure the system have enough free memory.
>
> OK,
>
> one thing I didn't understand is "why should you want check de zend
> memory usage when there is a memory_limit parameter in PHP.ini " ?
> does'nt it do the same at PHP layer when allocating ?
>
> >
> > thanks,
> >     looyao
> >
> > 2010/4/14 Rasmus Lerdorf <rasmus@lerdorf.com>
> >>
> >> On 04/14/2010 02:01 AM, J=C3=A9r=C3=B4me Loyet wrote:
> >> > The patch seems good (I didn't test it yet) but I'm curious about th=
e
> >> > way you check the memory real size:
> >> >
> >> > +                             if(zend_memory_usage(1 TSRMLS_CC) >
> >> > fpm_global_config.term_on_memory_limit){
> >> >
> >> > I don't know much about the zend_memory_usage() function. But does i=
t
> >> > return the real memory size of the process ?
> >>
> >> Right, that will only give you the memory allocated by the memory
> >> manager, obviously.  But, pecl/imagick does seem to use emalloc to
> >> allocate the imagick objects.  However, if the underlying magickwand
> >> library mallocs a bunch of temporary space on its own, this will not g=
et
> >> picked up.
> >>
> >> -Rasmus
> >
> >
>

--001636137aa292c201048441419d--