On 26.04.2010 23:12, Ferenc Kovacs wrote: > 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.
Yes. And there is no way to fix it. But that doesn't mean there MUST be any leaks at all. Btw, there are also other image libraries in this world. Not to mention that you can still use Imagemagick, but move the conversion from web to some CLI script. >> 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 We're talking about real life scenario here, please stick to it. >> > 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? It doesn't - Zend MM nothing nothing about third party libs. >> 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. RIGHT! That's exactly what I'm talking about! And the initial patch uses Zend MM to check the leaks, which is wrong. >> 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 Yes? Did you notice the word 'memory' is not even present on that page? -- 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
