Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BAA4A6E75 for ; Tue, 24 May 2011 13:06:39 +0000 (UTC) Received: (qmail 18967 invoked by uid 500); 24 May 2011 13:06:38 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 18914 invoked by uid 500); 24 May 2011 13:06:38 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 18906 invoked by uid 99); 24 May 2011 13:06:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 May 2011 13:06:38 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates 72.32.122.20 as permitted sender) Received: from [72.32.122.20] (HELO chandler.sharp.fm) (72.32.122.20) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 May 2011 13:06:31 +0000 Received: from chandler.sharp.fm (localhost [127.0.0.1]) by chandler.sharp.fm (Postfix) with ESMTP id B8A1D5C801A for ; Tue, 24 May 2011 08:06:10 -0500 (CDT) Received: from [192.168.201.54] (unknown [212.58.232.179]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: minfrin@sharp.fm) by chandler.sharp.fm (Postfix) with ESMTP id 27D5F5C800E for ; Tue, 24 May 2011 08:06:10 -0500 (CDT) Message-Id: From: Graham Leggett To: dev@httpd.apache.org In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80226F44C6922@il-ex01.ad.checkpoint.com> Content-Type: multipart/alternative; boundary=Apple-Mail-890--629831280 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [PR #51256] Memory consumption by parent process at sort_hook function Date: Tue, 24 May 2011 15:06:06 +0200 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80226F44C6922@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.936) X-Virus-Scanned: ClamAV using ClamSMTP --Apple-Mail-890--629831280 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 24 May 2011, at 2:20 PM, Yehezkel Horowitz wrote: > I have noticed that sort_hook function (in apr_hooks.c) doesn't > destroy temporary pool. > > This leads to a memory consumption of ~500K (=68 hooks * 8K) per > PROCESS! > > Since the sorted hooks are memcpy'ed to another pool anyway, no one > needs this pool after the function return. > > So the resolution is very simple - destroy this pool after usage > (before returning the sorted hooks array). > > I have tested this solution in my environment, without any problems. > > What do you think about this? Definitely sounds sensible. Do you have a patch so we can take a look? Regards, Graham -- --Apple-Mail-890--629831280 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On 24 May 2011, at = 2:20 PM, Yehezkel Horowitz wrote:

I have noticed that sort_hook =
function (in apr_hooks.c) doesn't destroy temporary =
pool.
This leads to a memory =
consumption of ~500K (=3D68 hooks * 8K) per =
PROCESS!
Since the sorted hooks are =
memcpy'ed to another pool anyway, no one needs this pool after the =
function return.
So the resolution is very simple =
- destroy this pool after usage (before returning the sorted hooks =
array).
I have tested this solution in my =
environment, without any problems.
What do you think about =
this?

Definitely sounds sensible. Do you have a patch so we can take a = look?

Regards,
Graham
--

= --Apple-Mail-890--629831280--