linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Marcus Sorensen <shadowsor@gmail.com>
Cc: Wes <wt75@gazeta.pl>, linux-raid <linux-raid@vger.kernel.org>
Subject: Re: raid10 centos5 vs. centos6 300% worse random write performance
Date: Sun, 28 Jul 2013 00:46:28 -0500	[thread overview]
Message-ID: <51F4B034.3040801@hardwarefreak.com> (raw)
In-Reply-To: <CALFpzo71sjK6Cd=jZ_iQG8rRk5TatGsJ5FznD75ayTm1A5kH-g@mail.gmail.com>

On 7/27/2013 4:01 PM, Marcus Sorensen wrote:
> Seekmark is very simple. It opens a block device with O_RDWR and
> O_SYNC, divides the disk into block_size chunks, spawns a bunch of
> threads, and each one chooses a random block, seeks there, writes,
> then chooses another, seeks there, writes, etc.  There shouldn't be
> any write barrier issue, since there's no filesystem involved. You can
> also point it at a file on a filesystem and it will do the same with
> that file, the O_SYNC *should* flush on every write.
> 
> There could be IO scheduler differences between the kernels.

~$ cat /sys/block/sda/queue/scheduler
[CFQ] noop deadline

Wes, yours will show CFQ probably as the default on RHEL/CentOS.  You'll
want deadline for best seek and all around performance.  So:

~$ echo deadline > /sys/block/sda/queue/scheduler

Add that to an init script or cron entry so it sets on every boot.

Also, make sure NCQ is working on each drive.  If it is, try disabling
it.  Look in dmesg for 4 lines like this with (depth 31/32), or at least
not zero for the first number.  Post the output for us to see.

ataX.00: xxxxxxxxx sectors, multi 16: LBA48 NCQ (depth 31/32)


>>> Does seekmark use barriers

Barriers are not an issue with this test.

WARNING: never disable filesystem write barriers unless you have a
verified to be working battery/flash backed write cache hardware RAID
controller.  If you disable barriers with individual drives on SATA
controllers and the kernel crashes or you lose power, it can corrupt the
filesystem, sometimes beyond recovery.

-- 
Stan


  reply	other threads:[~2013-07-28  5:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 10:11 raid10 centos5 vs. centos6 300% worse random write performance Wes
2013-07-25 11:44 ` Mikael Abrahamsson
2013-07-25 12:23   ` Wes
2013-07-25 18:49   ` Wes
2013-07-27 20:22   ` Wes
2013-07-27 21:01     ` Marcus Sorensen
2013-07-28  5:46       ` Stan Hoeppner [this message]
2013-08-12  8:43         ` Wes
2013-08-12 19:25           ` Stan Hoeppner

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=51F4B034.3040801@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=shadowsor@gmail.com \
    --cc=wt75@gazeta.pl \
    /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;
as well as URLs for NNTP newsgroup(s).