All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Nelson <mark.nelson@inktank.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: Sylvain Munaut <s.munaut@whatever-company.com>,
	"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: poor write performance
Date: Mon, 22 Apr 2013 06:39:02 -0500	[thread overview]
Message-ID: <51752156.9050004@inktank.com> (raw)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B4F3636DC@BITCOM1.int.sbss.com.au>

On 04/22/2013 06:34 AM, James Harper wrote:
>> Hi,
>>
>>> Correct, but that's the theoretical maximum I was referring to. If I calculate
>> that I should be able to get 50MB/second then 30MB/second is acceptable
>> but 500KB/second is not :)
>>
>> I have written a small benchmark for RBD :
>>
>> https://gist.github.com/smunaut/5433222
>>
>> It uses the librbd API directly without kernel client and queue
>> requests long in advance and this should give an "upper" bound to what
>> you can get at best.
>> It reads and writes the whole image, so I usually just create a 1 or 2
>> G image for testing.
>>
>> Using two OSDs on two distinct recent 7200rpm drives (with journal on
>> the same disk as data), I get :
>>
>> Read: 89.52 Mb/s (2147483648 bytes in 22877 ms)
>> Write: 10.62 Mb/s (2147483648 bytes in 192874 ms)
>>
>
> I like your benchmark tool!
>
> How many replicas? With two OSD's with xfs on ~3yo 1TB disks with two replicas I get:
>
> # ./a.out admin xen test
> Read: 111.99 Mb/s (1073741824 bytes in 9144 ms)
> Write: 29.68 Mb/s (1073741824 bytes in 34507 ms)
>
> Which means I forgot to drop caches on the OSD's so I'm seeing the limit on my public network (single gigabit interface). After dropping caches I consistently get:
>
> # ./a.out admin xen test
> Read: 39.98 Mb/s (1073741824 bytes in 25614 ms)
> Write: 23.11 Mb/s (1073741824 bytes in 44316 ms)
>
> Journal is on the same disk. Network is... confusing :) but is basically public on a single gigabit and cluster on a bonded pair of gigabit links. The whole network thing is shared with my existing drbd cluster so performance may vary over time.
>
> My read speed is consistently around 40MB/second, and my write speed is consistently around 22MB/second. I had expected better of read...

You may want to try increasing your read_ahead_kb on the OSD data disks 
and see if that helps read speeds.

>
> While running, iostat on each osd reports a read rate of around 20MB/second (1/2 total on each) during read test and a rate of 40-60MB/second (~2x total on each) during write test, which is pretty much exactly right.
>
> iperf on the cluster network (pair of gigabits bonded) gives me about 1.97Gbits/second. iperf between osd and client is around 0.94Gbits/second.
>
> changing the scheduler on the harddisk doesn't seem to make any difference, even when I set it to cfq which normally really sucks.
>
> What ceph version are you using and what filesystem?
>
> Thanks
>
> James
>


  reply	other threads:[~2013-04-22 11:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-18 11:46 poor write performance James Harper
2013-04-18 12:15 ` Wolfgang Hennerbichler
2013-04-18 23:11   ` James Harper
2013-04-20 10:52     ` Harald Rößler
2013-04-20 11:12       ` James Harper
2013-04-20 21:04         ` Jeff Mitchell
2013-04-18 13:43 ` Mark Nelson
2013-04-18 16:46   ` Andrey Korolyov
2013-04-18 17:01     ` Mark Nelson
2013-04-18 23:23   ` James Harper
2013-04-19  7:21     ` James Harper
2013-04-19  7:30       ` James Harper
2013-04-19 11:09         ` James Harper
2013-04-19 14:50           ` Mark Nelson
2013-04-20  0:33             ` James Harper
2013-04-20  1:30               ` James Harper
2013-04-21 13:52                 ` Mark Nelson
2013-04-22  5:32                   ` James Harper
2013-04-22 11:34                     ` Mark Nelson
2013-04-22 11:40                       ` James Harper
2013-04-21 17:56               ` Sylvain Munaut
2013-04-21 23:04                 ` James Harper
2013-04-22  8:34                   ` Sylvain Munaut
2013-04-22 11:34                     ` James Harper
2013-04-22 11:39                       ` Mark Nelson [this message]
2013-04-22 11:48                         ` James Harper
2013-04-22 12:01                           ` Mark Nelson
2013-04-22 13:47                             ` Mark Nelson
2013-04-22 15:20                         ` Sage Weil
2013-04-22 15:35                           ` Sylvain Munaut

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=51752156.9050004@inktank.com \
    --to=mark.nelson@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=james.harper@bendigoit.com.au \
    --cc=s.munaut@whatever-company.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.