Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21772 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75426 invoked by uid 1010); 2 Feb 2006 20:43:48 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 75411 invoked from network); 2 Feb 2006 20:43:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2006 20:43:48 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:59209] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id ED/08-20872-30F62E34 for ; Thu, 02 Feb 2006 15:43:47 -0500 Received: from [192.168.150.3] ([203.98.22.198]) (authenticated bits=0) by colo.lerdorf.com (8.13.5/8.13.5/Debian-3) with ESMTP id k12KheNn017975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Feb 2006 12:43:42 -0800 Message-ID: <43E26EFD.9050901@lerdorf.com> Date: Fri, 03 Feb 2006 09:43:41 +1300 User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Brian Moon CC: Ilia Alshanetsky , php internals References: <43E25FEC.3020808@dealnews.com> <43E26C45.9020503@prohost.org> <43E26CF8.5090105@dealnews.com> In-Reply-To: <43E26CF8.5090105@dealnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1270/Thu Feb 2 04:47:37 2006 on colo X-Virus-Status: Clean Subject: Re: [PHP-DEV] PHP, Apache 2, memory and APC From: rasmus@lerdorf.com (Rasmus Lerdorf) Brian Moon wrote: > Ilia Alshanetsky wrote: >> Rather then terminating Apache request yourself, you can use universal >> Apache configuration directives that allow you to restrict memory >> utilization of an Apache process. > > Hmmm, the ones I looked at seemed to prohibit a process from growing > above a certain size. Can you point me to them? I don't want to > prohibit a process from using what it needs (to a point). I need simply > need a child to terminate after it has gone above a certain threshold. > > We found that the norm for our applications was 10-15MB. Usage above > that was the exception. Some applications (especially when they were > generating cache that had gone stale) would need more for a brief > period. I don't want to stop that. I still think your best bet is to simply allow for the top watermark for each of your processes and configure your machines with enough ram to handle perhaps a smaller number of processes. Or fix your code to use less if that high watermark is too high. Killing processes seems like a very crude fix here. -Rasmus