> From: "Kirby C. Bohling" <kbohling@birddog.com>
> Date: Mon, 04 Feb 2002 16:24:14 -0600
>...
> Well, from what I can tell, the pool that is a directory baton is being
> over used. I am pretty sure it represents 60-80% of the memory. I know
> I saw the directory baton pool up over 40MB, but I believe that was
> early in the check out process.
Ouch.
When you say "check out process", you're referring to one of the directory
batons' pools that are creating during "svn checkout ..." ? (as opposed to
"svn update" or something)
>...
> It shows all the pools and the sizes. I used tags and file_line from
> the pools to determine exactly which pools and where they were created
> that the amount of memory is being allocated in. I know that a ton of
> memory is consumed creating the entries file over and over again in the
> same directory.
Thus, your patch for using a subpool in svn_wc__entry_modify(). Gotcha. But
in an earlier mail, you said it was only a few megabytes of the 180 meg that
you observed.
As I mentioned in private email, entries.c is due for a big cleaning. We can
do the subpool thing at that point, but it's kind of small fish right now.
> I haven't looked at the rest of it. The stuff for
> files gets pretty large also. The number of allocations over 2K is
> small. It would be easy to add statistics for that too.
I'd be curious what the largest, single allocation is.
>...
> ever. It seems you nickel and dime them to death, and keep a lot of
> memory around a ton longer then needed.
This is key. I had assumed that there were a few, incorrect uses of a few
pools. Instead, it sounds like there is a pretty systemic problem.
>...
> know about. I know that Mozilla has a tool named "SpaceTracer" I
> believe that tracks memory footprint and lifetime from logs to help you
> find objects that are living too long. I spent a ton of time with
> OpenStep chasing stuff like this down in a former life, it is a lot more
> fun when it isn't your job :-)
:-)
> If you want pathes and/or reports on this stuff let me know, I will send
> it. Some of it requires patching to apr, and some of it is written in
> such a way that you have to have SVN_POOL_DEBUG on, but it is all
> fixable to be relatively sane.
Sander is going to be most interested in this, as he has already said :-)
> Some scripting/gdb/libiberty, and I can
> probably nail down where every last allocation comes from on a
> particuarly pool if that is useful.
What will be most useful is the scripting that you use for this. If we just
get the results, then we'll fix that one spot. But if we have the tools,
then we can do even more :-)
[ "give a man a fish, and he won't go hungry for a day. teach him to fish
and he won't be hungry for the rest of his life." (well, until the lake
is fished out, at least) ]
> I don't know that the apr people
> will like the apr changes or accept them, which makes a lot of the stuff
> less useful. It's why I haven't submitted it to the list yet, I thought
> I might find a way around the changes to apr. It helps a lot in finding
> the pools.
As Sander said, we have about a half-dozen committers to APR here. That has
its downsides every now and then (when changes come to both sides at the
same time), but on balance, it is a tremendous win.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006