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

Frequent repository slow downs

From: Bob Wilken <drcodeman_at_hotmail.com>
Date: 2003-08-02 18:30:10 CEST

I've read about the issue #739 wedged state problem, and when the repository
becomes unresponsive I have shutdown apache and run svnadmin recover which
gives me a bit better response but it doesn't last long (30 minutes or so).
My best recovery strategy generally seems to come from dump/load into a new
repository but that may be just my perception as it always feels more
responsive after the reload.

I'm running a dev 0.25.0 build with Redhat Linux 8 and wonder if it's
something I have misconfigured or if I would be more stable on another OS
platform.

I migrated my code from another source repository and have 7000+ revisions
in SVN but that's comparable to Subversion's revisions. I ran strace on the
apache threads and noticed continuous timeouts, but I don't really know if
that is normal or not.

It likely wouldn't bother me so much -- except I now have 50+ repositories
hosted off a single apache instance taking the approach of a repository per
project. The probability of hosing another project during a recovery of one
is quite high so I need to run recover on all... really not a pretty
picture.

What OS is Subversion itself running off? Any tips on how it is configured
or how frequently you run recover with so many uncontrolled clients
accessing - how do you prevent them from locking up your database?

Thanks for any tips,
Bill

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Aug 2 18:30:53 2003

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