Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: error (athena.apache.org: local policy)
Date: Mon, 8 Dec 2014 20:38:24 +0100
From: Stefan Sperling <stsp@elego.de>
To: Philip Martin <philip.martin@wandisco.com>
Cc: Stefan Fuhrmann <stefan.fuhrmann@wandisco.com>,
        Subversion Development <dev@subversion.apache.org>
Subject: Re: On pool / memory usage debugging
Message-ID: <20141208193824.GC25318@ted.stsp.name>
Mail-Followup-To: Philip Martin <philip.martin@wandisco.com>,
	Stefan Fuhrmann <stefan.fuhrmann@wandisco.com>,
	Subversion Development <dev@subversion.apache.org>
References: 
 <CA+t0gk0r_f-HLO8w0LsshDVS2GYLgM8sK7EFxguzxUCyqDkYGQ@mail.gmail.com>
 <87lhmine3m.fsf@ntlworld.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87lhmine3m.fsf@ntlworld.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

On Mon, Dec 08, 2014 at 07:19:57PM +0000, Philip Martin wrote:
> I have been looking at the proposed 1.8/1.7 backport for issue 4531.
> The problem is easy to reproduce with pool debugging enabled and the
> patch does reduce memory use, but with a normal build I don't see the
> excessive memory in the first place.

That's surprising.

> Was this issue raised in response to a problem observed in a normal
> build?  Can the problem be reproduced in a normal build?  Perhaps the
> large tree produced by the script in the issue is not large enough to
> cause the problem in a normal build?

It was found and reproduced first with a set of CollabNet SVN 1.8 binaries,
both stand-alone and Edge ones, where it was crashing the server which
evidently maxed out memory as displayed by top(1) on Linux.
The original repository was much larger than the sample created by the
gentree script, though, in the order of 40GB in total size. I'm not sure
which repository format exactly.

As mentioned in the issue I can reproduce the problem with a trunk build.
The copy doesn't abort but uses roughly 2GB of memory before it completes.