Re: One suggestion to PHP-FPM

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