I have written a little script that loops over all the revisions in a
repository, calling `svnlook REPOS_PATH rev REVISION info` for each
iteration.
I have a copy of the Subversion repos up to revision 2096.
If I run my little script on my Linux laptop, it takes a while, but
eventually completes without error. I run db4_stat, and I see this:
25176 Last allocated locker ID.
9 Number of lock modes.
2000 Maximum number of locks possible.
2000 Maximum number of lockers possible.
2000 Maximum number of objects possible.
2326583 Current locks.
2326600 Maximum number of locks so far.
0 Current number of lockers.
7 Maximum number lockers so far.
0 Current number lock objects.
133 Maximum number of lock objects so far.
3010435 Number of lock requests.
3010435 Number of lock releases.
0 Number of lock requests that would have waited.
0 Number of lock conflicts.
0 Number of deadlocks.
0 Number of transaction timeouts.
0 Number of lock timeouts.
696KB Lock region size (712704 bytes).
0 The number of region locks granted after waiting.
3206726 The number of region locks granted without waiting.
If I run my little script on our FreeBSD test machine, it friggin'
flies for a while, then svnlook coredumps. Why does it coredump?
Well, I get a Berkeley memory error, but using db4_stat makes me think
that I've run out of locks:
2406 Last allocated locker ID.
9 Number of lock modes.
2000 Maximum number of locks possible.
2000 Maximum number of lockers possible.
2000 Maximum number of objects possible.
1 Current locks.
3 Maximum number of locks so far.
1999 Current number of lockers.
2000 Maximum number lockers so far.
0 Current number lock objects.
2 Maximum number of lock objects so far.
4802 Number of lock requests.
4802 Number of lock releases.
0 Number of lock requests that would have waited.
0 Number of lock conflicts.
0 Number of deadlocks.
0 Number of transaction timeouts.
0 Number of lock timeouts.
696KB Lock region size (712704 bytes).
0 The number of region locks granted after waiting.
12836 The number of region locks granted without waiting.
Incidentally, svnlook is always crashing on revision 399 of the repos,
so just for kicks I ran it by hand on revision 399, and it worked
without a problem (I wanted to make sure svnlook wasn't just
core-dumping on that revision).
Anybody have any recommendations on how to proceed in light of this
setback?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 7 19:03:09 2002