[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Server performance on Windows and migration

From: Andy Levy <andy.levy_at_gmail.com>
Date: Wed, 4 Feb 2009 12:42:25 -0500

On Wed, Feb 4, 2009 at 06:33, Justin Case
<send_lotsa_spam_here_at_yahoo.com> wrote:
> Hi all,
> Lately our subversion server version 1.4.5 (on Windows 2003 server, NTFS) became very slow. Nothing new happened on the machine, no new firewalls, no setting changes. The repository is about 25G big with about 30k files, using FSFS. We have like maximum 2-3 users simultaneously but not doing much work, they use Tortoise latest versions (1.5.x) plus one Hudson client (the continuous integration tool, no idea what its client is based on).

How many revisions do you have?

> Problem is, svnserver,exe pegs at 100% CPU for too long. A checkout yesterday of a project (size 2G, the kits shouldn't probably be saved in...) from the above repository took like 12 hours. I have absolutely NO IDEA what is happening.

It could have been the client slowing down as well as the server.

> I couldn't find many performance tuning tips for Windows so I made sure we have disabled last file access for NTFS, disabled indexing, removed dead transactions - but nothing improved significantly in the performance.
> Should I expect anything performance-wise from an upgrade to 1.5.5? Would sharding do me good, and if yes is there a way to convert the existing repository to a sharded one?

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.

There is a Python script, fsfs-reshard.py[1], 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[2]).

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.

1: http://svn.collab.net/viewvc/svn/trunk/tools/server-side/
2: http://subversion.tigris.org/svn_1.5_releasenotes.html#repos-upgrades


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-04 18:44:31 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.