As some people know, we recently switched from using cvs to svn and
feedback has begun to come in from the field. The biggest feedback I
have gotten is client performance on large repositories. Doing a
update on a large tree is very slow and when the working directory is on
NFS, it is unbelievably slow (a 5 minute CVS operation, 15 minutes under
SVN local, 3 and a half hours SVN on NFS)
My theory was that we were accessing the various files in the .svn
directory more often then should otherwise be needed and possibly by
changing the format of the .svn directory (the commonly accessed files
would be merged into a single file?) we could reduce the file system "burn".
The test machine is Solaris 2.8 running a static svn client built from
trunk (13219). Why a static client? It takes 1500 system calls to start
up a standard shared library client verses only about 220 for a static
client. I wanted to eliminate these system calls from the test as
unrelated noise. The "subject" of the test was a directory that
contained 3 files. I had already checked the files out so all I was
doing was calling "svn up scripts" which was not actually doing anything.
The raw system call results is:
http://www.stormbirds.org/~joshs/svn/svn-out.htm
<http://www.stormbirds.org/%7Ejoshs/svn/svn-out.htm>. I also put a
sorted copy up: http://www.stormbirds.org/~joshs/svn/svn-sorted.htm
<http://www.stormbirds.org/%7Ejoshs/svn/svn-sorted.htm> .
The key things to notice are the calls to open() where it is changing
files and rename(). It looks like it rewrites the entries file 3
times for each directory plus the dir-wcprops once.
Translated to a real world example, my build environment has 1272
directories. This means that to do a "svn up" at the top requires my
client to write 3816 unchanged copies of entries and then call rename
3816 times to replace the previous version. Of course, it is also
rewrites dir-wcprops 1272 times with no changes. Ie, we have more then
5000 file-creations and 5000 file-renames having no effect
Also, since this is changing the inode numbers (creating new files/etc),
this is totally eliminating any ability for the OS to cache the inode data
thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 1 23:00:41 2005