Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48097 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48448 invoked from network); 26 Apr 2010 18:45:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Apr 2010 18:45:57 -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:44900] helo=daylessday.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/F0-42789-26FD5DB4 for ; Mon, 26 Apr 2010 14:45:55 -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 D402EBFA08B; Mon, 26 Apr 2010 22:45:51 +0400 (MSD) Message-ID: <4BD5DF5F.5050603@daylessday.org> Date: Mon, 26 Apr 2010 22:45:51 +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: Ferenc Kovacs CC: PHP Internals References: <4BD54D42.5070400@daylessday.org> <4BD564A9.2060000@daylessday.org> <4BD57525.50803@daylessday.org> <36701B7BE4054FB3A72CFFB6B8A81DF5@KD5> <4BD5B521.6070404@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 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