Folks,
I wanted to send a follow up message to my original email on using
Solaris 9 with Solaris and the drastic performance penalty I was seeing
on the Solaris/SPARC platform.
The performance problem only occurred when using the client. After
performing many tests, including turning logging on, mounting with
noatime, and others we were unable to get our subversion client running
at an acceptable level to use it in a production environment without
causing a lot of wait time for our developers. We consistently saw an
76-85% decrease in performance when running the client on Solaris vs.
Windows or Linux boxes.
The performance hit we were experiencing was due to the UFS file system
requiring synchronous disk access each time a file is created, as was
pointed out in an email by Greg Hudson last week.
This was proven out further by turning on delayed I/O using the fastfs
tool. When we do this, times on the client go back down to the times
we see on other operating systems.
While I know that using fastfs in a "production" environment is looked
down upon because you can't count on the disk being synchronized in the
event of a power failure, I was wondering if anyone on the list actually
uses this delayed I/O feature of the operating system for things like
users home directories that are backed up nightly.
As Linux file systems default to nosynch and I've never had a problem
with boxes losing data in power failures here at home, I don't see a big
problem with this as long as the box isn't running an oracle production
database or something like that. Given the fact that the computer room
at work has interruptible power and backup generators anyway, I see even
less of a problem.
Also, I wanted to make clear that the server hums along nicely. There
is no performance impact running SVN under Apache on Solaris 9. The
big hit comes from the client creating the work area meta data during
the checkout operation.
Thanks to everyone on the list who responded as I was researching this
problem. Your input was very valuable in pointing me in the right
direction.
-- Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 14:05:26 2004