From: Dave Chinner <david@fromorbit.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>, xfs@oss.sgi.com
Subject: Re: xfs, aacraid 2.6.27 => 2.6.32 results in 6 times slowdown
Date: Tue, 8 Jun 2010 22:29:19 +1000 [thread overview]
Message-ID: <20100608122919.GC7869@dastard> (raw)
In-Reply-To: <4C0E13A7.20402@msgid.tls.msk.ru>
[ cc'd XFS list ]
On Tue, Jun 08, 2010 at 01:55:51PM +0400, Michael Tokarev wrote:
> Hello.
>
> I've got a.. difficult issue here, and am asking if anyone else
> has some expirence or information about it.
>
> Production environment (database). Machine with an Adaptec
> RAID SCSI controller, 6 drives in raid10 array, XFS filesystem
> and Oracle database on top of it (with - hopefully - proper
> sunit/swidth).
>
> Upgrading kernel from 2.6.27 to 2.6.32, and users starts screaming
> about very bad performance. Iostat reports increased I/O latencies,
> I/O time increases from ~5ms to ~30ms. Switching back to 2.6.27,
> and everything is back to normal (or, rather, usual).
>
> I tried testing I/O with a sample program which performs direct random
> I/O on a given device, and all speeds are actually better in .32
> compared with .27, except of random concurrent r+w test, where .27
> gives a bit more chances to reads than .32. Looking at the synthetic
> tests I'd expect .32 to be faster, but apparently it is not.
>
> This is only one machine here which is still running 2.6.27, all the
> rest are upgraded to 2.6.32, and I see good performance of .32 there.
> But this is also the only machine with hardware raid controller, which
> is onboard and hence not easy to get rid of, so I'm sorta forced to
> use it (I prefer software raid solution because of numerous reasons).
>
> One possible cause of this that comes to mind is block device write
> barriers. But I can't find when they're actually implemented.
>
> The most problematic issue here is that this is only one machine that
> behaves like this, and it is a production server, so I've very little
> chances to experiment with it.
>
> So before the next try, I'd love to have some suggestions about what
> to look for. In particular, I think it's worth the effort to look
> at write barriers, but again, I don't know how to check if they're
> actually being used.
>
> Anyone have suggestions for me to collect and to look at?
http://xfs.org/index.php/XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_write_cache.3F
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-06-08 12:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-08 9:55 xfs, aacraid 2.6.27 => 2.6.32 results in 6 times slowdown Michael Tokarev
2010-06-08 12:29 ` Dave Chinner [this message]
2010-06-08 20:34 ` xfs, 2.6.27=>.32 sync write 10 times slowdown [was: xfs, aacraid 2.6.27 => 2.6.32 results in 6 times slowdown] Michael Tokarev
2010-06-08 23:18 ` Dave Chinner
2010-06-09 6:43 ` Michael Tokarev
2010-06-09 7:47 ` Dave Chinner
2010-06-09 19:11 ` Michael Tokarev
2010-06-10 0:47 ` Dave Chinner
2010-06-10 5:59 ` Michael Tokarev
2010-06-10 14:58 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100608122919.GC7869@dastard \
--to=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjt@tls.msk.ru \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox