[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

concurrency and slowdowns

From: Dan Kearns <Dan.Kearns_at_Siebel.com>
Date: 2004-06-11 19:41:33 CEST


Is there any progress on fixing concurrency related problems? Any time there are more than 3-5 simultaneous updates and/or commits, my repository slows down to the point of unusability. It doesn't actually wedge, however to make it usable again requires killing all the clients (and therefore running recover).

Just for data points, the repos is ~15k files and somewhat deep (maybe 35 levels of directories at the deepest).

I notice that bdb reports many deadlocks (maybe a few hundred against 15-20M successful locks), which usually indicates a design problem. Just scanning the "trails" code gave me the distinct impression that wrapping detected deadlocks in a tight loop of retries is probably making things worse.

Hopefully someone will tell me this is under control and I just need to be patient and wait for v.next? (I hope, I hope, I hope…)

Are there any workarounds which don't involve serializing repository access? I'm sort of wondering if it wouldn't help to insert a line in the svn piece of the deadlock detector to treat every other deadlock as a fatal error… just to give whomever it is fighting with a little headstart.

…or maybe I'm totally off base with my wild guessing as to what's wrong?

Received on Fri Jun 11 19:41:33 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.