On Fri, Aug 17, 2001 at 05:07:54AM -0500, kfogel@collab.net wrote:
>...
> The showstopper appears to be caused by unfreed Berkeley DB resources.
> We had some scripts do massive numbers of multi-file commits against a
> repository, and eventually it starts failing, with (among other
> things) DB_INCOMPLETE errors, in both ra_local and ra_dav case. See
> http://www.sleepycat.com/docs/api_c/db_close.html for more on that.
The point here is that we were running serial tests against the repository.
There should have been only one accessor at a time. Yet the db->close docs
describe DB_INCOMPLETE as occurring when another writer is working during
the close operation. That would seem to indicate some transaction is still
open. It is possible that we were closing an operation (i.e. we didn't hook
it to a pool).
So... I think the plan here is to try and find what is being left open and
why. It is also possible that we are connecting before the previous commit
has cleaned up (i.e. the previous connection is still open).
> There are some other problems as well. Some of the http PUT requests
> are failing;
We're seeing a 500 error here. There is some kind of problem with sending a
delta.
> there are some working copy locking issues cropping up;
When we ran a huge series of commits, we would start to see some dirs were
reported as locked.
>...
> copy bugginess, but repository maintenance issues are another story.
> We need to get that stuff fixed before self-hosting.
The maintenance that Karl is referring to here is w.r.t the log files. The
database grows pretty large due to the log files. There is some stuff in the
DB docs about how to archive the db, and more specifically: how to detect
which log files are no longer in use (and can be rm'd). We need to get some
basic maintenance instructions/procedures figured out and in place.
That is about it. Three main problems so far: locked WC, bad PUTs, and
repository issues. I'm going to be looking into the PUT and repository
problem over the weekend.
We also found the commit-email script was a bit slow -- it added about 3.5
seconds to each commit. Mike Pilato has checked in some changes just now to
improve the speed. A few seconds is no big deal, but we may as well speed it
up. Another possibility is to fork the commit-email and run it in the
background, letting the final commit request complete quickly (since we
generate it based on a specific revision, this is easy and robust (unlike
the race conditions we see in CVS re: generating the commit email)).
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:36:36 2006