Linux RAID subsystem development
 help / color / mirror / Atom feed
From: pg@lxra2.for.sabi.co.UK (Peter Grandi)
To: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: RAID5 Performance
Date: Thu, 28 Jul 2016 14:28:23 +0100	[thread overview]
Message-ID: <22426.2167.369879.756599@tree.ty.sabi.co.uk> (raw)
In-Reply-To: <22425.63565.439521.592849@tree.ty.sabi.co.uk>

[ ... ]
> That largely explains why in the tests I have mentioned small
> sync write IOPS for many "consumerish" flash SSDs top at around
> 100, instead of the usual > 10,000 for small non-sync writes.
[ ... ]

To summarize the preceding long discussion:

* The stats reported show a low level of IOPS being carried out.

* The critical part of the workload seems to be synchronous
  small writes.

* Probably then the primary issue is the use of flash SSDs that
  have a limited number of IOPS for small synchronous writes.

* A secondary issue is that RAID5 results in RMW for small
  writes.

There are two possible options:

* Replace the flash SSDs with those that are known to deliver
  high (at least > 10,000 single threaded) small synchronous
  write IOPS.

* Relax the requirement for synchronous writes on *both* the
  primary and secondary DRBD servers, if feeling lucky.

The third option, which is to change the workload so that it
does not emit small synchronous writes to the storage layer,
seems not practical in the context.

Ideally the system would also be switched from RAID5 to RAID10
to avoid the large penalty on small writes at the RAID level
too.

That may be considered expensive, but as I wrote:

> [ ... ] it requires a storage layer that has to cover all
> possible IO workloads optimally, [ ... ]

  reply	other threads:[~2016-07-28 13:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27  2:24 RAID5 Performance Adam Goryachev
2016-07-27  3:15 ` Brad Campbell
2016-07-27  5:36 ` Doug Dumitru
2016-07-27 23:26   ` Adam Goryachev
     [not found]   ` <7af0cc98-e395-9446-05eb-a6c0ca20f187@websitemanagers.com.au>
2016-07-28  0:11     ` Doug Dumitru
2016-07-28 13:08       ` Anthony Youngman
2016-07-28 14:10       ` Adam Goryachev
2016-07-28 17:45         ` Peter Grandi
2016-07-27 14:26 ` Peter Grandi
2016-07-27 17:38   ` Doug Dumitru
2016-07-28 12:19     ` Peter Grandi
2016-07-28 13:28       ` Peter Grandi [this message]
2016-07-28 13:57         ` Adam Goryachev
2016-07-28 17:20           ` Peter Grandi
2016-07-28 18:45             ` Doug Dumitru
2016-08-02  7:09             ` Adam Goryachev
2016-08-03 21:23               ` Peter Grandi
2016-07-28 13:50       ` Adam Goryachev

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=22426.2167.369879.756599@tree.ty.sabi.co.uk \
    --to=pg@lxra2.for.sabi.co.uk \
    --cc=linux-raid@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