> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
> Sent: maandag 5 mei 2014 10:26
> To: Stefan Fuhrmann
> Cc: Subversion Development; Stefan Fuhrman
> Subject: Re: svn commit: r1590405 - in /subversion/trunk: build.conf
> subversion/include/private/svn_subr_private.h
> subversion/libsvn_repos/log.c subversion/libsvn_subr/bit_array.c
>
> On 5 May 2014 03:13, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> wrote:
> >
> >
> >
> > On Tue, Apr 29, 2014 at 4:29 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> >>
> >> On 29 April 2014 17:54, Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com>
> >> wrote:
> >> > On Mon, Apr 28, 2014 at 8:11 AM, Ivan Zhakov <ivan_at_visualsvn.com>
> wrote:
> >> >>
> >> >> eOn 27 April 2014 19:27, <stefan2_at_apache.org> wrote:
> >> >> > Author: stefan2
> >> >> > Date: Sun Apr 27 15:27:46 2014
> >> >> > New Revision: 1590405
> >> >> >
> >> >> > URL: http://svn.apache.org/r1590405
> >> >> > Log:
> >> >> > More 'svn log -g' memory usage reduction. We use a hash to keep
> >> >> > track
> >> >> > of all revisions reported so far, i.e. easily a million.
> >> >> >
> >
> > > * Some system provided APR (1.5+ in particular) uses mmap
> >
> >> > to allocate memory. I.e. for every block, e.g. 8k, there is a
> >> > separate mmap call. The Linux default is 65530 (sic!) mmap
> >> > regions per process. Slowly allocating pools can trigger OOM
> >> > errors after only 512MB actual memory usage (sum across
> >> > all threads). I already prepared a patch for that.
> >> >
> >> Ouch, I didn't know that. I was thinking that MMAP APR pool allocator
> >> is experimental and is not enabled by default.
> >
> >
> > It is not enabled by default, I guess but the
> > package responsible decided to enable it anyway.
> >
> Thanks for information.
In that case I think we should try to fix APR to remove this limitation, instead of rewriting our own code to cope with this.
When it uses mmap as allocator it should request bigger chunks from the OS.
I don't think mmap() will be faster than the default allocator for such small chunks... I would expect quite the opposite, unless code is using big chunks.
Bert
Received on 2014-05-05 11:51:00 CEST