From: Stefan Priebe <s.priebe@profihost.ag>
To: Gregory Farnum <greg@inktank.com>
Cc: Dan Mick <dan.mick@inktank.com>, ceph-devel@vger.kernel.org
Subject: Re: production ready?
Date: Tue, 30 Oct 2012 21:32:01 +0100 [thread overview]
Message-ID: <50903941.90805@profihost.ag> (raw)
In-Reply-To: <CAPYLRzh3AV41CnY5VMPAtuggZxr6NidDrYF0ODYL6H64vEBVeQ@mail.gmail.com>
Am 30.10.2012 14:45, schrieb Gregory Farnum:
>> But there's still the problem of slow random write IOP/s. At least i haven't
>> seen any good benchmarks.
>
> It's not magic — I haven't done extensive testing but I believe people
> see aggregate IOPs of about what you can calculate:
> (number of storage disks * IOPS per disks) / (replication level)
> The journaling bumps that up a little bit for bursts, of course;
> similarly if you're doing it on a brand new RBD image it can be a bit
> slower since you need to create all the objects as well as write data
> to them. You need to architect your storage system to match your
> requirements. If you want to run write-heavy databases on RBD, there
> are people doing that. They're using SSDs and are very pleased with
> its performance. *shrug*
My last test was with 0.49 so i can't talk about 0.52 but as far as i
know nothing has changed in this case.
I had 6 Dedicated servers running each with 4x Intel 520series SSDs
running 4 OSDs (one OSD per disk). I had the journal running in tmpfs
1GB size to be sure it isn't the bottleneck. Replication was set to 2.
Each SSD is capable of doing 30.000 IOP/s random 4k.
But with RBD i wasn't able to get more than 20.000 IOP/s but overall i had:
6 ded. servers * 4 SSDS => 24 OSDs/SSDs * 30.000 IOP/s / Replication 2
=> 360.000 iop/s theoretical overall performance
But i didn't get more than 20.000 while using 3.6Ghz Xeon CPUs and Dual
10GBE.
Greets,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-10-30 20:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-26 21:52 production ready? Gandalf Corvotempesta
2012-10-29 20:21 ` Dan Mick
2012-10-30 11:35 ` Gandalf Corvotempesta
2012-10-30 13:15 ` Gregory Farnum
2012-10-30 13:36 ` Gandalf Corvotempesta
2012-10-30 13:38 ` Stefan Priebe - Profihost AG
2012-10-30 13:45 ` Gregory Farnum
2012-10-30 20:32 ` Stefan Priebe [this message]
2012-10-30 13:40 ` Gregory Farnum
2012-10-30 13:57 ` Gandalf Corvotempesta
2012-10-30 14:17 ` 袁冬
2012-10-30 14:31 ` Gandalf Corvotempesta
2012-10-30 14:38 ` 袁冬
2012-10-30 14:59 ` Gandalf Corvotempesta
2012-10-30 21:06 ` Dan Mick
2012-10-30 21:17 ` Gandalf Corvotempesta
2012-10-30 21:21 ` Sage Weil
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=50903941.90805@profihost.ag \
--to=s.priebe@profihost.ag \
--cc=ceph-devel@vger.kernel.org \
--cc=dan.mick@inktank.com \
--cc=greg@inktank.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox