> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: 14 May 2002 18:31
> striker@apache.org and cmpilato@collab.net write:
>
> > > > Is the pool code simply not re-using allocations?
> > >
> > > The latter is indeed the case. The production pools code does very
> > > little to reuse mem. It is a space-time tradeoff.
>
> Well, this clearly explains why we're unable to do an ra_local
> checkout of /trunk, or even a single 'svnadmin dump' of a full
> revision. Both of those tasks are being *very* anal about clearing
> and re-using pools; there's no reason they should run out of memory.
I find this a bit odd. Why wouldn't it work over ra_local? And what
kind of results do you get when you use the debug version of pools?
> We absolutely need to fix the pool code and make it aggressive about
> re-using memory. SVN can't function otherwise.
>
> If the httpd project requires time optimization over space, that's
> fine; just have httpd avoid calls to apr_pool_clear()! Wouldn't that
> be enough?
No. The problem is in how memory is reused currently. The pool
maintains an active block. If the next allocation doesn't fit in the
remaining part of that active block, the block is marked as full.
Then the pool gets a new active block. Memory waste can grow
dramatically if you are unlucky enough to do your allocations in
a certain order. I believe Greg Stein and I worked out that you can
get up to 400% of what you would expect in usage.
Also, consecutive blocks aren't joined together to form a bigger
block. In other words, you might have one big chunk of mem that could
satisfy your allocation, but the allocator won't see it and gets new
(unfragmented) mem.
For these issues patches were posted quite some time back. Time to
get them out from under the dust and test them.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 14 18:51:53 2002