Re: Svn update slow for a small repository

I finally decided to spent sometime looking into the code for this slowdown. Turns out that this is already a known issue (look at the topic on "Subversion _really_slow) . Subversion depends on APR to get random number. In the default build, APR uses /dev/random to get its number. Sometime the system would stall waiting on /dev/random.

I decided I don't need this high degree of randomness, so I configure mine with a --without-devrandom switch. With this, the problem goes away.

kv chin <a.sparrow@yahoo.com> wrote:
On Mar 14, 2006, at 23:18, Cabanero, Christian wrote:

> We're trying to use subversion 1.3.0 for a pretty small repository
> and are having intermittent performance problems with it.

> The slowness is most often observed when performing updates and
> diffs using both the command line and subclipse.
>
> What I've seen is that when the slowness does occur the Linux box
> doesn't have a lot of CPU utilization, in fact it's often near zero
> but I do see a lot of iowait, sometimes as much as 98%.

I have the exact same problem too. I used svnserve -d -r ... to
serve my repository. The repository is not huge, it is about 50MB.
75% of the time when I browse the repository through svn protocol,
the performance is pretty good. But other times, it could take
between 1 to 5 minutes for it to respond. I used FSFS for the
repository. I also noticed the exact same thing that the server
is
 not doing anything at all (CPU utilization is close to 0) during
the slowdown.
The hosted project has many directories, but each directory only
has at most 30 files.

Any help would be greatly appreciated.

Kart

---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.

                
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
Received on Fri Apr 14 08:21:29 2006