Return-Path: Delivered-To: apmail-modperl-archive@apache.org Received: (qmail 74635 invoked by uid 500); 16 Apr 2001 10:33:18 -0000 Mailing-List: contact modperl-help@apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list modperl@apache.org Received: (qmail 74095 invoked from network); 16 Apr 2001 10:33:15 -0000 To: Michael Bacarella Cc: "[Aquitaine]" , mod-perl Subject: Re: Apache growing. References: <005a01c0c601$cfe3e5a0$bd66c5cb@private> <20010415205924.A14898@sync.nyct.net> From: Dave Hodgkinson Date: 16 Apr 2001 11:25:47 +0100 In-Reply-To: <20010415205924.A14898@sync.nyct.net> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Michael Bacarella writes: > (I'm not sure this is even a code problem. Maybe perl is just bad at keeping > a single consistent working set and the copy-on write from the parent Apache > kicks in and keeps increasing unique per process memory consumption). There's lots of good stuff in the mod_perl guide on tracking down leaks. Both perl and mod_perl have both been extensively tested . It's worthwhile to have done this at least once so you know how to do it when you really need to do it. In addition, profiling your code is a Good Thing to do :-) -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy ----------------------------------------