Frequent repository slow downs

[Bob Wilken <dr...@hotmail.com>]

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

Re: Frequent repository slow downs

[kf...@collab.net]

"Bob Wilken" <dr...@hotmail.com> writes:
> 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.

Sorry, what do you mean by "The probability of hosing another project
during a recovery of one is quite high so I need to run recover on
all" ?  Why does running recovery on one project hose a separate
repository?  What symptoms are you seeing?

Or by "hosing", do you just mean that access is down because Apache is
down?

> 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?

svn.collab.net is running RedHat Linux, I believe.

We've just started having similar problems, actually, but were busy
with meta-work last week and haven't had a chance to look into it yet.
We suspect something is wonky about SVN's usage of Berkeley DB.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org