Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48094 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93752 invoked from network); 26 Apr 2010 15:45:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Apr 2010 15:45:43 -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:43830] helo=daylessday.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 67/57-58325-525B5DB4 for ; Mon, 26 Apr 2010 11:45:42 -0400 Received: from [192.168.3.218] (unknown [212.42.62.198]) by daylessday.org (Postfix) with ESMTPSA id A56BCBFA08B for ; Mon, 26 Apr 2010 19:45:38 +0400 (MSD) Message-ID: <4BD5B521.6070404@daylessday.org> Date: Mon, 26 Apr 2010 19:45:37 +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: <4BD54437.2020304@daylessday.org> <4BD54D42.5070400@daylessday.org> <4BD564A9.2060000@daylessday.org> <4BD57525.50803@daylessday.org> <36701B7BE4054FB3A72CFFB6B8A81DF5@KD5> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] One suggestion to PHP-FPM From: tony@daylessday.org (Antony Dovgal) On 26.04.2010 19:20, looyao teng wrote: > 2. The PHP's management of memory can't give the occupied memory > back to the system by itself. This is simply not true. It does cache some blocks, but usually the memory is simply free()d. > 3.Though the idea is good,it cannot acquiret the actual state of > the memory usage of the process for PHP. Meanwhile,the other > methods are not good enough in a way,such as cannot run on > multi-platform.So we hope to try to monitor and manage the heap > memory.After all,the used memory of PHP itself is relatively > stationary.And the memory_limit is ought to limit the heap memory. > So, when it go beyond the limit,kill the process in order to release > the memory. What do you mean by "the idea"? Your initial idea? "Other methods"? Multi-platform? Yes, surely mallinfo() is not multiplatform. But it shows the real memory usage, not Zend MM stats. So what's your point? > 4. I'm agree that it's not necessary to realize this feature in > SAPI, but it may be not easy to realize in other pleaces, because > it must check after current task execute, and SAPI is not all like > FPM that is independent process existing. Erm.. Come again? > 6. I do not install memtrack, according to the README, I think it's > not my really want , the focus of my requirement is not to log or > throw exception, because I know my problem is what, I need to solve > it, and the solution is to exit. I repeat: you can add another limit to memtrack and another action. And this time it might be exit(), not warning. But after looking at your patch, I believe that this problem is NULL since the very beginning. You're checking Zend MM stats and that number is always 0 after request shutdown and before request startup, no matter what. 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. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP