On Mon, Dec 8, 2014 at 7:46 PM, Stefan Sperling <stsp_at_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.
Received on 2014-12-08 20:32:09 CET