Thank you all for your answers.
I have no idea what SMART mode is, but I realized that as long the repository is on a virtual machine in another department (over which I have little influence), we might have to live long with the penalty regardless of any upgrade efforts. And yes, it's on RAID which reportedly had issues last weeks. However RAID was fixed and SVN is still slow - after all it seems to wait for CPU not IO.
> From: Andy Levy
> How many revisions do you have?
> It could have been the client slowing down as well as the
I see only on the server the 100% peak (peak... actually a looong ridge).
> Depends upon how many revisions you have. NTFS gets bogged down when
> you have large numbers of files in a single directory. With FSFS, each
> revision is a separate file, and they're all in one directory. The
> sharding introduced with 1.5 is meant to alleviate that concern.
I had the impression that only Windows Explorer is showing them lots slower, and internally (FS-level) it wouldn't really matter. Am I wrong here?
> There is a Python script, fsfs-reshard.py, which will perform the
> sharding for you. You'll need to upgrade to 1.5.x first, including
> svnadmin upgrade and then optionally svn-populate-node-origins-index
> (see the release notes).
> At this point, you've already taken the repository offline and done a
> whole bunch of maintenance on it - IMHO, just get it all done in one
> shot and do a dump/load cycle and get it over with, instead of
> upgrading, doing the populate-nodes-origin step, then resharding.
> My installation is smaller than yours, but I've been told by at least
> one person that since the 1.5 upgrade it's seemed faster. I have no
> real metrics though, and I use Apache, not svnserve.
Ok, I think I'll do the upgrade anyway and if it brings something even better.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-09 16:22:11 CET