Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48099 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64212 invoked from network); 26 Apr 2010 19:32:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Apr 2010 19:32:26 -0000 Authentication-Results: pb1.pair.com header.from=tony@daylessday.org; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tony@daylessday.org; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain daylessday.org designates 89.208.40.236 as permitted sender) X-PHP-List-Original-Sender: tony@daylessday.org X-Host-Fingerprint: 89.208.40.236 mail.daylessday.org Linux 2.6 Received: from [89.208.40.236] ([89.208.40.236:35754] helo=daylessday.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E4/84-42789-94AE5DB4 for ; Mon, 26 Apr 2010 15:32:26 -0400 Received: from [192.168.1.2] (ppp83-237-193-141.pppoe.mtu-net.ru [83.237.193.141]) by daylessday.org (Postfix) with ESMTPSA id B6665BFA08B for ; Mon, 26 Apr 2010 23:32:22 +0400 (MSD) Message-ID: <4BD5EA46.2080104@daylessday.org> Date: Mon, 26 Apr 2010 23:32:22 +0400 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-1.1.1 Thunderbird/3.0.4 MIME-Version: 1.0 To: internals@lists.php.net References: <4BD564A9.2060000@daylessday.org> <4BD57525.50803@daylessday.org> <36701B7BE4054FB3A72CFFB6B8A81DF5@KD5> <4BD5B521.6070404@daylessday.org> <4BD5DF5F.5050603@daylessday.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] One suggestion to PHP-FPM From: tony@daylessday.org (Antony Dovgal) 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