All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
To: Greg Farnum <greg@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: how to debug slow rbd block device
Date: Wed, 23 May 2012 08:18:07 +0200	[thread overview]
Message-ID: <4FBC811F.5060004@profihost.ag> (raw)
In-Reply-To: <65E9589544C4489F93761035433ADC01@inktank.com>

Hi,

>> So try enabling RBD writeback caching — see http://marc.info
>> /?l=ceph-devel&m=133758599712768&w=2
>> will test tomorrow. Thanks.
Can we path this to the qemu-drive option?

Stefan


Am 22.05.2012 23:11, schrieb Greg Farnum:
> On Tuesday, May 22, 2012 at 2:00 PM, Stefan Priebe wrote:
>> Am 22.05.2012 22:49, schrieb Greg Farnum:
>>> Anyway, it looks like you're just paying a synchronous write penalty
>>  
>>  
>> What does that exactly mean? Shouldn't one threaded write to four  
>> 260MB/s devices gives at least 100Mb/s?
> 
> Well, with dd you've got a single thread issuing synchronous IO requests to the kernel. We could have it set up so that those synchronous requests get split up, but they aren't, and between the kernel and KVM it looks like when it needs to make a write out to disk it sends one request at a time to the Ceph backend. So you aren't writing to four 260MB/s devices; you are writing to one 260MB/s device without any pipelining — meaning you send off a 4MB write, then wait until it's done, then send off a second 4MB write, then wait until it's done, etc.
> Frankly I'm surprised you aren't getting a bit more throughput than you're seeing (I remember other people getting much more out of less beefy boxes), but it doesn't much matter because what you really want to do is enable the client-side writeback cache in RBD, which will dispatch multiple requests at once and not force writes to be committed before reporting back to the kernel. Then you should indeed be writing to four 260MB/s devices at once. :)
> 
>>  
>>> since with 1 write at a time you're getting 30-40MB/s out of rados bench, but with 16 you're getting>100MB/s.
>>> (If you bump up past 16 or increase the size of each with -b you may  
>>  
>> find yourself getting even more.)
>> yep noticed that.
>>  
>>> So try enabling RBD writeback caching — see http://marc.info/?l=ceph-devel&m=133758599712768&w=2
>> will test tomorrow. Thanks.
>>  
>> 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

  reply	other threads:[~2012-05-23  6:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-22 12:45 how to debug slow rbd block device Stefan Priebe - Profihost AG
2012-05-22 14:52 ` Andrey Korolyov
2012-05-22 19:27   ` Stefan Priebe
2012-05-22 19:35 ` Greg Farnum
2012-05-22 19:40   ` Stefan Priebe
2012-05-22 19:52     ` Greg Farnum
2012-05-22 20:13       ` Stefan Priebe
2012-05-22 20:30       ` Stefan Priebe
2012-05-22 20:48         ` Mark Nelson
2012-05-22 20:54           ` Stefan Priebe
2012-05-22 20:49         ` Greg Farnum
2012-05-22 21:00           ` Stefan Priebe
2012-05-22 21:11             ` Greg Farnum
2012-05-23  6:18               ` Stefan Priebe - Profihost AG [this message]
2012-05-23  6:30                 ` Josh Durgin
2012-05-23  7:01                   ` Stefan Priebe - Profihost AG
2012-05-23  7:19                     ` Josh Durgin
2012-05-23  7:22                       ` Stefan Priebe - Profihost AG
2012-05-23  7:33                         ` Josh Durgin
     [not found]                           ` <CABYiri8PXT9dpCGLE7dn=_PoW8CdLxqZF87OHe=dMXEWxogb_w@mail.gmail.com>
2012-05-23 19:54                             ` Josh Durgin
2012-05-23  8:20                       ` Stefan Priebe - Profihost AG
2012-05-23  8:29                         ` Josh Durgin
2012-05-23  7:22                   ` Andrey Korolyov
2012-05-23  8:15                     ` Stefan Priebe - Profihost AG
2012-05-23 11:47                     ` Mark Nelson
2012-05-23  8:30               ` Stefan Priebe - Profihost AG
2012-05-23  9:10                 ` Stefan Priebe - Profihost AG

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=4FBC811F.5060004@profihost.ag \
    --to=s.priebe@profihost.ag \
    --cc=ceph-devel@vger.kernel.org \
    --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 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.