Svn update slow for a small repository

["Cabanero, Christian" <ca...@amazon.com>]

Hello,

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

The server is a Linux RHEL 3 box that currently is running nothing but subversion server 1.3.0.  However, I'm running it using the "svnserve -d" mode and it's being accessed via svn:// protocol only.  No one on the team is using http:// or direct file access.  The repository is pretty small.  The db directory is only 70 MB, and most of that is likely large binary png files that we were using for mock-ups.

Right now everyone on the team (6 people) is using subversion version 1.3.0, using both svn command line and also the subclipse plug-in which in-turn is using the JavaSVN library.  Both the command line and plug-in is intermittently slow, sometimes very slow.

I also have a FishEYE server that is scanning the repository periodically however even when I have that turned off it is still slow, although turning it off appears to help a little bit.

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'm not sure what else to do in terms of troubleshooting this.  Is the problem related to the fact that I'm running svnserve -d manually?  

Thanks for any help,

Christian Cabanero



Christian Cabanero
Senior Technical Program Manager
Amazon.com
cabanero@amazon.com
http://www.amazon.com

Re: Svn update slow for a small repository

[Ryan Schmidt <su...@ryandesign.com>]

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'd also be interested to know more about this. We also experience  
occasional iowait slowness sometimes up to a few minutes when  
updating or committing a working copy. Our repository is served from  
a Gentoo Linux machine through Apache 2.0.54. I thought the iowait  
was due to the working copies, which in our scenario are also being  
stored on the Linux server and accessed from desktop workstations  
over Samba. But perhaps it's due to the server-side repository  
operations?

The time needed will be proportional not to the size of the working  
copy but to the number of directories, if I understand correctly.  
Perhaps that applies in your case? I think it applies in ours... I  
have a working copy which (without the .svn directories) is 71MB  
large and contains (without the .svn directories) 1250 directories.

I would think allocating more memory to disk cache, or getting a  
faster RAID, would help. We have a RAID, but apparently it's not good  
enough. Or something.



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