From: Mark Nelson <mark.nelson@inktank.com>
To: Stefan Priebe <s.priebe@profihost.ag>
Cc: ceph-devel@vger.kernel.org
Subject: Re: how to debug slow rbd block device
Date: Tue, 22 May 2012 15:48:37 -0500 [thread overview]
Message-ID: <4FBBFBA5.9090604@inktank.com> (raw)
In-Reply-To: <4FBBF74C.9020608@profihost.ag>
On 05/22/2012 03:30 PM, Stefan Priebe wrote:
> Am 22.05.2012 21:52, schrieb Greg Farnum:
>> On Tuesday, May 22, 2012 at 12:40 PM, Stefan Priebe wrote:
>> Huh. That's less than I would expect. Especially since it ought to be
>> going through the page cache.
>> What version of RBD is KVM using here?
> v0.47.1
>
>> Can you (from the KVM host) run
>> "rados -p data bench seq 60 -t 1"
>> "rados -p data bench seq 60 -t 16"
>> and paste the final output from both?
> OK here it is first with write then with seq read.
>
> # rados -p data bench 60 write -t 1
> # rados -p data bench 60 write -t 16
> # rados -p data bench 60 seq -t 1
> # rados -p data bench 60 seq -t 16
>
> Output is here:
> http://pastebin.com/iFy8GS7i
>
> 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
Hi Stefan,
Can you use something like iostat or collectl to check and see if the
write throughput to each SSD is roughly equal during your tests? Also,
what FS are you using and how did you format/mount it? I've been doing
some tests internally using 2 nodes with 5 OSDs each backed by SSDs for
both data and journal and am seeing about 600MB/s from the client (over
10GE) on a fresh ceph fs.
Mark
next prev parent reply other threads:[~2012-05-22 20:48 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 [this message]
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
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=4FBBFBA5.9090604@inktank.com \
--to=mark.nelson@inktank.com \
--cc=ceph-devel@vger.kernel.org \
--cc=s.priebe@profihost.ag \
/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.