One suggestion to PHP-FPM

2010/4/15 Jérôme Loyet jerome@loyet.net

2010/4/15 滕路遥 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 the
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 ?

Obviously you didn't read the original mail, and the links inside:
http://groups.google.com/group/highload-php-en/browse_thread/thread/1882a3b2257dcc5c/ea73892cea011541?lnk=gst&q=gaochunhui#ea73892cea011541

The problem here is that PHP wouldn't free any allocated memory untill
the process exits, so there's the risk of memory exhaustion if too
many PHP processes were running, even though each process wouldn't
exceed PHP's memory_limit.

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.

Tyrael

thanks,
looyao

2010/4/14 Rasmus Lerdorf rasmus@lerdorf.com

The patch seems good (I didn't test it yet) but I'm curious about the
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 it
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 get
picked up.

-Rasmus

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érôme Loyet jerome@loyet.net

2010/4/15 滕路遥 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 the
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

The patch seems good (I didn't test it yet) but I'm curious about the
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 it
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 get
picked up.

-Rasmus

Le 26 avril 2010 04:02, looyao teng tly.phpfans@gmail.com a écrit :

in linux, read the /proc/self(pid)/status,  and the VmRSS(real memory usage)
or VmSize(virtual memory usage)  is the the memory usage of  the current
process.

in fact I was looking of a cleaner way to do it.

2010/4/24 Jérôme Loyet jerome@loyet.net

2010/4/14 Rasmus Lerdorf rasmus@lerdorf.com

The patch seems good (I didn't test it yet) but I'm curious about the
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 it
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 get
picked up.

does someone know a way to get the memory usage of the current process ?
getrusage is not accurate in linux.

Thx
++ jerome

Adding this to FPM won't help anyway - FPM doesn't use threads.

You meant won't hurt?

No, I mean implementing it in PECL/memtrack would be better since this way
you add it to all non-threaded SAPIs.
While adding it to FPM means that other non-threaded SAPIs will have to do
it in an other way.

Yeah, this could be implemented there, but it seems that its not actively
developed, last release 0.1 beta more than a year ago.
But as you say, it would be a huge benefit, to add this feature for all
non-threaded SAPI.

Tyrael

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