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, [ ... ]
next prev parent 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