subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: On pool / memory usage debugging
Date Mon, 08 Dec 2014 19:30:31 GMT
On Mon, Dec 8, 2014 at 7:46 PM, Stefan Sperling <stsp@elego.de> wrote:

> On Mon, Dec 08, 2014 at 06:42:38PM +0100, Stefan Fuhrmann wrote:
> > IOW, pool debugging is nice for tracing allocations but if you
> > want to measure memory consumption on the OS side, turn
> > pool debugging off.
>
> All measurements I mentioned in the issue were done with pool debugging
> disabled. Measuring memory usage of the issue #4531 copy operation with
> pool debugging enabled was impossible because the copy operation never
> completed in a reasonable amount of time due to pool-debugging-induced
> logging overhead hogging the CPU.
>

Hm. 381 MB are massive, then. Maybe I can find reproduce it
and help tracking it down with a modified APR.


> > Finally, to minimize cache usage, make sure to disable fulltext
> > caching as well (enabled by default in 1.9) and set the cache
> > size to *1*, not 0. The latter would fall back to 1.6-style caches,
>
> Which option are you referring? The SVNInMemoryCacheSize option?
> The doc for that option says "0 deactivates the cache". Is this an error?
>
>   /* per server */
>   AP_INIT_TAKE1("SVNInMemoryCacheSize", SVNInMemoryCacheSize_cmd, NULL,
>                 RSRC_CONF,
>                 "specifies the maximum size in kB per process of
> Subversion's "
>                 "in-memory object cache (default value is 16384; 0
> deactivates "
>                 "the cache)."),
>

It's technically correct, because the "static" per-process cache does
get disabled and all that's left is memory dynamically allocated for
an open connection (svn_fs_t, actually).

But the doc string is misleading. I would suggest to change it to
"0 switches to dynamically sized caches".

-- Stefan^2.

Mime
View raw message