On Fri, 2002-03-08 at 18:57, Ben Collins wrote:
> I've tracked down the overusage of locks to the stabilize_node()
> function in dag.c. This is the call where we traverse the commited tree
> and mark everthing immutable.
>
> During this portion of my import, some 200,000 locks and 885 lock
> objects are used up, before being released. I'm trying to find out of
> there is a way we can explicitly release locks as we go (using
> db->lock_vec or something).
Well, hmmmm.
200,000 locks?
For a given transaction (and all it's child tranasctions, whose locks do
*not* go away until the parent is committed/aborted, not when *the
child* is committed/aborted), you shouldn't be getting that many locks.
B-tree requires one lock per tree level to access something (this is of
course, for read-only/write-only, read-write takes two locks).
Hash requires one lock to access something.
So hash might reduce it by a factor of five maximum, based on your
earlier db stats that showed the tree level at 5.
This is best case. It's somewhere between "not at all, and a factor of
5". But we still shouldn't have that many locks.
Hmmmm.
First, i would actually switch the DB type to hash (which supports the
duplicate key stuff we use, before someone asks).
If this reduces the number of locks by more than a factor of 5, it's
gotta be a BDB bug.
Given that i can't see where these locks are being created and staying
alive unless we are creating child transactions, it could quite
possibily be a BDB bug.
If it is, switching to hash should show it.
I'm really at a loss otherwise.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 9 06:41:40 2002