[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3 performance issue with a Berkeley db application


On Tue, 2003-02-04 at 12:41, Matthias Andree wrote:

> > ext3 is making it write much _more_ data.  Due to the 5-second commit,
> > the application's redirtying and an ext3 gremlin.

> So this means we write more data because ext3 commits quicker than the
> other file systems I tested and has less chance to kill old write
> requests that are overwritten because they were already flushed to disk?
> Then we really won't have much choice except quenching our overwrites as
> far as reasonable and try to improve locality of our operations.

Or using data=writeback, or specifying a longer commit interval.

> The part that still interests me is: What I still don't understand is
> that ext3 on SCSI schedules some writes in 5 s intervals with 4 idle
> seconds at most times; then some bursts of 10,000 or 30,000 blocks
> occasionally and writes a consistent 1,000 to 2,500 blocks/s on fsync --
> IDE in contrast has a constant write rate of 700 blocks/s without these
> 4 seconds at 0 blocks. Why is my SCSI layer faster than Greg's although
> my drive is slower?

How are you measuring the IO rates?  The normal "vmstat" IO accounting
only accounts for the submission of IO requests, not their completion. 
The IDE and SCSI subsystems can have very different queue depths, so for
SCSI you may well see a huge number of IOs submitted to the queue all at
once, whereas on IDE the queue will fill up after fewer commands and the
calling process will stall.  

That would mean you'd see all the blocks accounted at once on SCSI, but
you'd see a continual dribble of new blocks accounted for under IDE. 
The disk would still be kept busy under both.

> Please look at http://mandree.home.pages.de/bogofilter/vmstat-1.png -- I
> hope this is clearer and tells more than a thousand words.
> So again: is it worth trying with a vanilla, Marcelo, ... kernel? Is
> there anything I can tune, elvtune, mount options, ext3fs options that
> might differ between this file systems so I can eliminate perturbations?

It's not a filesystem thing but a block-device-layer thing, and elvtune
can only mask it to a limited extent (because the SCSI layer will take
requests off the queue as they come in, so changing the block device
queue depth doesn't control all the variables in the SCSI case.)

"iostat -x" should show you the outstanding IO queue sizes if you have
got CONFIG_BLK_STATS enabled, and that will give you a better idea of
what's going on.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]