You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gino Filicetti <gi...@filicetti.net> on 2008/02/07 04:19:05 UTC
Slow SVN Updates (though they shouldn't be).
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Verdana">Hey guys, I was wondering if anyone could explain
some annoying behaviour we've always seen whilst doing root level SVN
updates in our (rather large) working copy.<br>
<br>
Problem.... <br>
<br>
Run svn update on the root of our working copy, and the system will
download the newly updated files from the server and then it will sit
there and churn through at almost 100% cpu and with the hard drive
reading and writing like mad. Sometimes it will do this for longer than
it took to download the new files and eventually will return with the
"At Revision xxxx" message and all activity ceases.<br>
<br>
What exactly is it doing? Is it touching EVERY file in .svn in all
subdirectories? I'm curious if there's anything we can do to improve
performance or if we're stuck (and no, shrinking the size of our
working copy is not an option).<br>
<br>
System Info....<br>
<br>
Windows XP<br>
SVN: v1.4.5<br>
Problem is the same whether using TortoiseSVN or using svn in cygwin.<br>
<br>
Working copy info.... <br>
<br>
It's pretty big, using find and wc, I've calculated it out:<br>
<br>
-- number of files<br>
<br>
gfilicet@clc-gfilcet7-xp /cygdrive/c/chordiant/fnd62-rad7/workspace<br>
$ find . -type f -print | wc -l<br>
<br>
72216<br>
<br>
<br>
-- number of directories<br>
<br>
gfilicet@clc-gfilcet7-xp /cygdrive/c/chordiant/fnd62-rad7/workspace<br>
$ find . -type d -print | wc -l<br>
<br>
37773<br>
<br>
I realize this is also counting all the files and subdirectories in
.svn, so these numbers should be halved (roughly).<br>
<br>
Any help is appreciated. It would be great if there were something we
could do about this.<br>
<br>
Thanks,<br>
<br>
Gino<br>
<br>
<br>
</font>
</body>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Slow SVN Updates (though they shouldn't be).
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 6, 2008, at 22:19, Gino Filicetti wrote:
> Hey guys, I was wondering if anyone could explain some annoying
> behaviour we've always seen whilst doing root level SVN updates in
> our (rather large) working copy.
>
> Problem....
>
> Run svn update on the root of our working copy, and the system will
> download the newly updated files from the server and then it will
> sit there and churn through at almost 100% cpu and with the hard
> drive reading and writing like mad. Sometimes it will do this for
> longer than it took to download the new files and eventually will
> return with the "At Revision xxxx" message and all activity ceases.
I would say that's not entirely uncommon. Though the 100% CPU
surprises me a little. I think it should be waiting on the disk here,
not the CPU.
> What exactly is it doing? Is it touching EVERY file in .svn in all
> subdirectories? I'm curious if there's anything we can do to
> improve performance or if we're stuck (and no, shrinking the size
> of our working copy is not an option).
It's not touching every file, but it is doing clean-up in the working
copy. And it needs to do something in each .svn directory.
> System Info....
>
> Windows XP
> SVN: v1.4.5
> Problem is the same whether using TortoiseSVN or using svn in cygwin.
>
> Working copy info....
>
> It's pretty big, using find and wc, I've calculated it out:
>
> -- number of files
>
> gfilicet@clc-gfilcet7-xp /cygdrive/c/chordiant/fnd62-rad7/workspace
> $ find . -type f -print | wc -l
>
> 72216
>
>
> -- number of directories
>
> gfilicet@clc-gfilcet7-xp /cygdrive/c/chordiant/fnd62-rad7/workspace
> $ find . -type d -print | wc -l
>
> 37773
>
> I realize this is also counting all the files and subdirectories
> in .svn, so these numbers should be halved (roughly).
>
> Any help is appreciated. It would be great if there were something
> we could do about this.
The time it takes is probably proportional to the number of
directories in the working copy, and 37773 is a largish number of
directories, so it will take some time. To make it faster, increase
the performance of your disk, like by getting a disk that spins at a
faster rate, or by setting up a larger disk cache is possible, or by
putting the working copy on a RAM disk or something.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Slow SVN Updates (though they shouldn't be).
Posted by Talden <ta...@gmail.com>.
> It's pretty big, using find and wc, I've calculated it out:
>
> -- number of files
> ...
> 72216
>
> -- number of directories
> ...
> 37773
>
> I realize this is also counting all the files and subdirectories in .svn,
> so these numbers should be halved (roughly).
Actually since each 'real' folder may have all of this structure:
.svn/
prop-base/
props/
text-base
tmp/
prop-base/
props/
text-base/
And each .svn folder has two files, text-base has 1 file for every
file in the parent and prop-base will have a props file for each file
with properties....
realFolder ~= 37773 / 9 ~= 4200
realFiles ~= (72216 - (4200 * 2)) / 2 ~= 32000
I assume the traversal of the working copy during an update needs to
visit at least one file in every .svn folder (4200+ files) in 4200
different .svn folders, each with different parent folders... it is
all of this seeking that likely takes the time as much as the minimal
revision checking and tweaking.
There is a general acceptance that a more efficient and more capable
working copy format is needed - this is a massive task in design let
alone implementation and I don't even know if a serious degree of
effort has been applied to the problem given the huge push for the
upcoming 1.5 features...
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org