From: Mark Kampe <mark.kampe@inktank.com>
To: Mike Dawson <mdawson@gammacode.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: Guidelines for Calculating IOPS?
Date: Fri, 19 Oct 2012 10:45:04 -0700 [thread overview]
Message-ID: <508191A0.1040509@inktank.com> (raw)
In-Reply-To: <50816812.2040008@gammacode.com>
Replication should have no effect on read throughput/IOPS.
The client does a single write to the primary, and the
primary then handles re-replication to the secondary
copies. As such the client does not pay (in terms of
CPU or NIC bandwidth) for the replication. Per-client
throughput limitations should be largely independent of
the replication.
However, the replication does generate additional network
and I/O activity between the OSDs. This means that the
available aggregate throughput (of the entire cluster)
is effectively cut in half when you move from one-copy to two.
I am confused by your math:
You say 385MB/s and 5250 IOPS (x8k)
5250 IOPS * 8192 = 43MB/s
Do you mean that some of your clients are generating
a lot of small block writes (at up to 5250 IPS) and
that others of your clients are doing larger writes
(with an aggregate throughput of 385MB/s)?
For RADOS throughput:
385MB/s is a fairly small number
5250 buffered sequential IOPS is a very small number
5250 random IOPS is not a particularly large
number, but will require several servers
My guess is that the IOPS may drive the number of
servers, and the drives per server will be the
capacity divided by the number of required servers.
So how many IOPS can you get per server?
You are using RBD, and depending on the particulars
of your stack, there may be a great deal of buffering
and caching on the client side that can make the
RADOS traffic much more efficient than the tributary
client requests. Thus, I would suggest that you
probably want to actually benchmark the application
in question to measure the client-experienced throughput.
On 10/19/12 07:47, Mike Dawson wrote:
> All,
>
> I am investigating the use of Ceph for a video surveillance project with
> the following minimum block storage requirements:
>
> 385 Mbps of constant write bandwidth
> 100TB storage requirement
> 5250 IOPS (size of ~8 KB)
>
> I believe 2 replicas would be acceptable. We intend to use large
> capacity (2 or 3TB) SATA 7200rpm 3.5" drives, if the IOPS work out
> properly.
>
> Is there a method / formula to estimate IOPS for RDB? Specifically I
> would like to understand:
>
> - How does replica count affect read/write IOPS?
>
> - I'm trying to understand best practice for when to optimize server
> count, drives per server, and drive capacity as it relates to IOPS. Is
> there a point of diminishing I/O performance using server chassis with
> lots of drive slots, like the 36-drive Supermicro SC847a?
next prev parent reply other threads:[~2012-10-19 17:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 14:47 Guidelines for Calculating IOPS? Mike Dawson
2012-10-19 17:45 ` Mark Kampe [this message]
2012-10-19 17:56 ` Wido den Hollander
2012-10-19 19:07 ` Mike Dawson
2012-10-19 20:46 ` Gregory Farnum
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=508191A0.1040509@inktank.com \
--to=mark.kampe@inktank.com \
--cc=ceph-devel@vger.kernel.org \
--cc=mdawson@gammacode.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.