Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Feb 2005 14:44:24 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Nick Pavlica <linicks@gmail.com>
Cc:        Mike Tancsa <mike@sentex.net>
Subject:   Re: FreeBSD 5.3 I/O Performance / Linux 2.6.10 | Continued Discussion
Message-ID:  <Pine.NEB.3.96L.1050203144140.3610E-100000@fledge.watson.org>
In-Reply-To: <dc9ba0440502011550715bb0ec@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Feb 2005, Nick Pavlica wrote:

>   I was wondering if any progress has been made in determining the cause
> of the poor disk I/O performance illustrated by the testing in this
> thread?  Now that 5.3 is labeled as the production stable version, and
> 4.x is labeled as legacy, improving the performance of the 5.4+
> distributions is clearly important.  I know that everyone is working
> hard to do this, and wanted to help by testing(retest, etc)  the disk
> I/O performance on 5.4 devel/final and post the results as soon as
> possible.  I would also like others to join me in this testing effort so
> that we have as much feedback as possible.  My hope is that we will
> start bridging the large disk I/O performance gap demonstrated in the
> 4.11 & 5.3 testing. 

Per my out of band e-mail a bit earlier, I was wondering if I could get
you to produce a concise write-up of the various benchmarks you're
running, and the specific configurations and results so far.  I'd like to
reproduce the scenario in a test cluster, but want to make sure I'm
looking at the same issue syou're looking at :-).

> - When would be best time to start this testing?  - What is the
> preferred method for keeping in sync with the current devel branch?  I'm
> assuming cvs-up is the best method. 

I've found the best way to track branches is to mirror the CVS repository
using cvsup and no tag, then to locally check out specific work trees.
This allows you to easily slide files across revisions, helping to track
down specific changes that may have been the source of regression or
improvement.  It also makes it easier to answer the question "What are you
running" :-).

Regarding when to start running -- now is as good a time as any.  The VFS
SMP work seems to have settled some, so it's now a variable that can be
frobbed fairly safely as part of testing.

Robert N M Watson



> 
> Thanks!
> --Nick Pavlica
> 
>   
> 
> 
> 
> 
> On Fri, 28 Jan 2005 09:52:38 +0000 (GMT), Robert Watson
> <rwatson@freebsd.org> wrote:
> > 
> > On Thu, 27 Jan 2005, Mike Tancsa wrote:
> > 
> > > >I/O (reads, writes at fairly large multiples of the sector size -- 512k is
> > > >a good number) and small I/O size (512 bytes is good).  This will help
> > > >identify the source along two dimmensions: are we looking at a basic
> > > >storage I/O problem that's present even without the file system, or can we
> > > >conclude that some of the additional extra cost is in the file system code
> > > >or the hand off to it.  Also, with the large and small I/O size, we can
> > > >perhaps draw some conclusions about to what extent the source is a
> > > >per-transaction overhead.
> > >
> > > Apart from postmark and iozone (directly to disk and over nfs), are
> > > there any particular tests you would like to see done ?
> > 
> > Just to get started, using dd to read and write at various block sizes is
> > probably a decent start.  Take a few samples, make sure there's a decent
> > sample size, etc, and don't count the first couple of runs.
> > 
> > Robert N M Watson
> > 
> > _______________________________________________
> > freebsd-questions@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
> >
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050203144140.3610E-100000>