Hmm, sounds like lock management problems. Multiple users acquiring locks
and causing deadlock? (the hangs anyway. The recursion problems may also
be related)
This is not an easy problem to clean out as it depends on interaction with
other software pieces (Bdb) that also use locks. I think that Bdb has a
deadlock detect arrangement to sense a problem and abort one of the
deadlockees before a commit. Is this being used?
There isn't any way to use lots of simulated users pounding on the database
to test for nonexistence of this problem. It needs to be done analytically.
There are higher-order tools (e.g., Spin) which can be used to model the
transactions and analyze whether problems exist. This is a lot of work
though.
FWIW
BobG
Brandon Ehle wrote on Wed, 15 Jan 2003 09:19:04 -0800
solo turn wrote
>>
>>
>>what would be a good strategy to reach scalablility/stability? could
>>it be a testcase with thousands of entries and moving/copying around
>>in it? could it be encouraging somebody "large" to move to svn?
>>
>>
>At this point we have a bunch of global hangs that can happen at any
>time and almost never happen in the same place twice, and a few
>operations that run your system out of resources.
>
>The latter would be easy to develop tests for, but we'd need to set up a
>specific machine that auto-runs these large tests daily and uploads the
>reports to svn-breakage as most of the developers won't have the
>necessary resources on their machines to run these tests.
>
>The former is much more difficult, until someone tracks down and
>identify the problem, we won't be able to build a reliable test case,
>and I've found that sometimes when I think the hangs have gone away,
>they'll show up a couple days later when doing another large repository
>operation.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 15 17:59:26 2003