You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ron Bieber <ro...@bieberlabs.com> on 2004/03/30 12:04:18 UTC
Re: Drastic performance difference with subversion client on
Solaris 9
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Drastic performance difference with subversion client on Solaris 9
Posted by es...@logic.net.
On Tue, Mar 30, 2004 at 06:04:18AM -0600, Ron Bieber wrote:
> 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.
I'd like to add that you may want to add "logging" to the mount options
on any filesystems you've done this to. While it can't completely save
your hide in the event of failure, you'll at least (hopefully) minimize
the damage by only hosing up a journal (and thus losing some data), rather
than getting back a damaged or unrepairable filesystem (thus losing ALL
data ;-).
--
Edward S. Marshall <es...@logic.net>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Drastic performance difference with subversion client on
Solaris 9
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-03-30 at 07:04, Ron Bieber wrote:
> 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.
The situation is somewhat more complicated than you give it credit for
in your first sentence.
The Linux ext2 filesystem behaves as you say, with completely asynch
writes and no particular attention to ensuring failure atomicity of any
kind. But it does have a pretty sophisticated fsck designed to get a
filesystem back into working order in the face of failures. (It can't
protect against certain kinds of problems, like data blocks containing
data from the wrong files, but at least it won't throw up its hands in
disgust and tell you to newfs.)
Modern Linux filesystems (reiser, xfs, ext3) have asynchronous file
creation but use techniques (careful ordering or journals) to make sure
that the on-disk filesystem is consistent at all times. As a result,
they tend to be a little slower than ext2, but most safer. Most people
who use Linux these days use one of these filesystems.
Solaris with asynch writes has neither the advantage of a sophisticated
fsck (as far as I know) nor the advantage of ordered writes or
journaling. Although you stand a pretty good chance of being okay in
the face of an unclean shutdown, it's not very safe at all.
So, feel free to rely on backups and uninterruptable power; those are
fine things. But I don't think you can rely on the experience of Linux
users.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Drastic performance difference with subversion client on Solaris 9
Posted by es...@logic.net.
On Tue, Mar 30, 2004 at 06:04:18AM -0600, Ron Bieber wrote:
> 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.
I'd like to add that you may want to add "logging" to the mount options
on any filesystems you've done this to. While it can't completely save
your hide in the event of failure, you'll at least (hopefully) minimize
the damage by only hosing up a journal (and thus losing some data), rather
than getting back a damaged or unrepairable filesystem (thus losing ALL
data ;-).
--
Edward S. Marshall <es...@logic.net>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Drastic performance difference with subversion client on
Solaris 9
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-03-30 at 07:04, Ron Bieber wrote:
> 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.
The situation is somewhat more complicated than you give it credit for
in your first sentence.
The Linux ext2 filesystem behaves as you say, with completely asynch
writes and no particular attention to ensuring failure atomicity of any
kind. But it does have a pretty sophisticated fsck designed to get a
filesystem back into working order in the face of failures. (It can't
protect against certain kinds of problems, like data blocks containing
data from the wrong files, but at least it won't throw up its hands in
disgust and tell you to newfs.)
Modern Linux filesystems (reiser, xfs, ext3) have asynchronous file
creation but use techniques (careful ordering or journals) to make sure
that the on-disk filesystem is consistent at all times. As a result,
they tend to be a little slower than ext2, but most safer. Most people
who use Linux these days use one of these filesystems.
Solaris with asynch writes has neither the advantage of a sophisticated
fsck (as far as I know) nor the advantage of ordered writes or
journaling. Although you stand a pretty good chance of being okay in
the face of an unclean shutdown, it's not very safe at all.
So, feel free to rely on backups and uninterruptable power; those are
fine things. But I don't think you can rely on the experience of Linux
users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org