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! > 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 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? > 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. 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. And even that is not required as you can always adjust max_requests and live happily ever after. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
