You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2001/08/22 00:54:37 UTC
first 700 commits, with instrumentation
This is an instrumentation Greg and I had been talking about, and that
Albert Chin had suggested here earlier too. Rather than fling this
massive (~4.5M) file around in email, kindly point your browser to
http://svn.collab.net/mass-commit-instrumented.txt
if you want to see the results. There's a summary at the top of the
page:
----------------------------------------------------------------------
This is the output the first 700 commits from mass-commit, with the
new intrumentation in svn_fs_close_fs() turned on. Some interesting
results:
1. We don't appear to have any leftover locks or txns, which is
good. Those numbers are always 0 by the time svn_fs_close_fs()
is called, as they should be, and all the other numbers look
about right too.
Fine. However,
2. It *does* look like svn_fs_close_fs() is getting called more
than once during the commit process. Not talking about the
temporary fs's used by svn_ra_local__split_URL(), I mean fs's
are apparently being closed at various intervals file sending.
That's downright weird. I wonder if we have an overeager pool-freeing
policy going on here?
----------------------------------------------------------------------
Note that, despite point (1), we're still getting the DB "cannot
allocate memory" errors we'd been seeing before, and the "commit
failed: while calling close_edit()" + "unexpected end of svndiff
input" errors too.
There are also some "working copy locked" errors, but I'm pretty sure
those don't matter (i.e., they're a bug, but not one causing the
repository problems).
Thoughts? (Albert?)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org