[Top] [All Lists]

Re: observed significant performance improvement using "delaylog" in a r

To: Peter Niemayer <niemayer@xxxxxx>
Subject: Re: observed significant performance improvement using "delaylog" in a real-world application
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 11 Aug 2010 10:08:54 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <i3rt4t$46c$1@xxxxxxxxxxxxxxx>
References: <i3rt4t$46c$1@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Aug 10, 2010 at 06:01:33PM +0200, Peter Niemayer wrote:
> Hi all,
> we use XFS for a very I/O-intensive, in-house developed real-time
> database application, and whenever we see new or significantly
> changed file-systems becoming available, we run a benchmark using
> this application on a conserved, fixed real-world data set.
> I'm pleased to state that using the experimental "delaylog" mount
> option (in vanilla linux-2.6.35) we measured a 17% performance
> increase
> for our benchmark scenario. (Other mount-options in use both before
> and after the "delaylog" option: noatime,nodiratime,nobarrier)

That's great to hear. One thing that you might want to try to
further improve performance is the logbsize=262144 option as well.
That will help flush log IO faster by doing less IOs.

Also, if your workload is doing lots of fsync calls, then the
optimisations I posted a few days ago should also help improve
delaylog throughput.

> That's a lot given that XFS was the fastest performing file-system
> for this application already.
> It's also a promising result regarding stability, as several other
> tests (using e.g. reiser4 or ceph) in the past led to crashes in the
> same benchmark scenario.

That's definitely encouraging. ;)

> So thanks to all contributing developers for this significant optimization!

And thanks for the feedback.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>