From: Michael Tokarev <mjt@tls.msk.ru>
To: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: xfs, aacraid 2.6.27 => 2.6.32 results in 6 times slowdown
Date: Tue, 08 Jun 2010 13:55:51 +0400 [thread overview]
Message-ID: <4C0E13A7.20402@msgid.tls.msk.ru> (raw)
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?
Thank you!
/mjt
next reply other threads:[~2010-06-08 9:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-08 9:55 Michael Tokarev [this message]
2010-06-08 12:29 ` xfs, aacraid 2.6.27 => 2.6.32 results in 6 times slowdown Dave Chinner
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=4C0E13A7.20402@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=linux-kernel@vger.kernel.org \
/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