Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of sussman@gmail.com designates
 74.125.44.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=Md6ro41tBgP+o/UfENQ/wYUu9LoEvo7sywEe1794cRDu82d/nLonD0FPMKdkoXmQes
         x4PhfcKD/a74tCQC2dqxhOv4ceWARtUAb/aM+sWmcknGWQVKdYHLiKtSSU9PIwMuFAmG
         rlyhp72KYDMbUcA0KecbfhUjvJLbEIF+t/2E4=
Message-ID: <53c059c90810011147p337b617fx2252e230ac6f2f42@mail.gmail.com>
Date: Wed, 1 Oct 2008 13:47:16 -0500
From: "Ben Collins-Sussman" <sussman@red-bean.com>
Sender: sussman@gmail.com
To: "Mark Phippard" <markphip@gmail.com>
Subject: Re: apr pools & memory leaks
Cc: "Subversion Developers" <dev@subversion.tigris.org>, dev@apr.apache.org
In-Reply-To: <ff892c5d0810011131x210402cdq5d2b2aefc04b87ca@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <53c059c90810011111v37c36635y7279870f9bc852a0@mail.gmail.com>
	 <ff892c5d0810011131x210402cdq5d2b2aefc04b87ca@mail.gmail.com>

On Wed, Oct 1, 2008 at 1:31 PM, Mark Phippard <markphip@gmail.com> wrote:
> On Wed, Oct 1, 2008 at 2:11 PM, Ben Collins-Sussman
> <sussman@red-bean.com> wrote:
>> I have interesting memory leak data to share with these two lists
>> (crossposting to both svn and apr dev lists).
>>
>> Ever since we launched svn-on-bigtable over at Google (about 2 years
>> ago), we've been struggling with mysterious memory leaks in apache --
>> very similar to what users are complaining about in Subversion issue
>> 3084.
>>
>> After lots of analysis, here's what we've figured out so far.
>
> It is good to see some analysis on this issue.  Here is link BTW:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3084
>
> A couple questions:
>
> 1) This seems to happen only with Apache 2.2 and not 2.0.  Is there
> any explanation for that supported by your analysis?

As far as I know, this is an APR issue, not an Apache issue... and I
don't think the pool code has changed for at least 6 or 7 years...?


>
> 2) It seems like many of the people, at least on Windows, can
> reproduce this problem quickly.  Could this just be due to running
> requests which create/destroy a lot of memory?

Definitely.  A single checkout causes zillions of subpools to be
repeatedly created and destroyed.   Just look at all the looping
constructs in libsvn_fs!

If you run apache in prefork mode, you won't see this problem -- no
apache process lasts very long.

If you run apache in threaded (mpm) mode, the apache process runs
forever, and the leak becomes obvious.

>
> 3) Any reason more Windows users would see this than Linux?  Maybe
> more Windows SVN users use Apache 2.2 than on Linux?

As Erik said, on Windows only the threaded mode is available, thus
explaining why they're seeing this problem more than anyone else.