From: Josh Durgin <josh.durgin@inktank.com>
To: Stefan Priebe <s.priebe@profihost.ag>
Cc: Gregory Farnum <greg@inktank.com>,
Alexandre DERUMIER <aderumier@odiso.com>,
Sage Weil <sage@inktank.com>,
ceph-devel@vger.kernel.org, Mark Nelson <mark.nelson@inktank.com>
Subject: Re: speedup ceph / scaling / find the bottleneck
Date: Mon, 02 Jul 2012 13:30:19 -0700 [thread overview]
Message-ID: <4FF204DB.80709@inktank.com> (raw)
In-Reply-To: <4FF1F4F6.4030403@profihost.ag>
On 07/02/2012 12:22 PM, Stefan Priebe wrote:
> Am 02.07.2012 18:51, schrieb Gregory Farnum:
>> On Sun, Jul 1, 2012 at 11:12 PM, Stefan Priebe - Profihost AG
>> <s.priebe@profihost.ag> wrote:
>>> @sage / mark
>>> How does the aggregation work? Does it work 4MB blockwise or target node
>>> based?
>> Aggregation is based on the 4MB blocks, and if you've got caching
>> enabled then it's also not going to flush them out to disk very often
>> if you're continuously updating the block — I don't remember all the
>> conditions, but essentially, you'll run into dirty limits and it will
>> asynchronously flush out the data based on a combination of how old it
>> is, and how long it's been since some version of it was stable on
>> disk.
> Is there any way to check if rbd caching works correctly? For me the I/O
> values do not change if i switch writeback on or of and it also doesn't
> matter how large i set the cache size.
>
> ...
If you add admin_socket=/path/to/admin_socket for your client running
qemu (in that client's ceph.conf section or manually in the qemu
command line) you can check that caching is enabled:
ceph --admin-daemon /path/to/admin_socket show config | grep rbd_cache
And see statistics it generates (look for cache) with:
ceph --admin-daemon /path/to/admin_socket perfcounters_dump
Josh
>>> Ceph:
>>> 2 VMs:
>>> write: io=2234MB, bw=25405KB/s, iops=6351, runt= 90041msec
>>> read : io=4760MB, bw=54156KB/s, iops=13538, runt= 90007msec
>>> write: io=56372MB, bw=638402KB/s, iops=155, runt= 90421msec
>>> read : io=86572MB, bw=981225KB/s, iops=239, runt= 90346msec
>>>
>>> write: io=2222MB, bw=25275KB/s, iops=6318, runt= 90011msec
>>> read : io=4747MB, bw=54000KB/s, iops=13500, runt= 90008msec
>>> write: io=55300MB, bw=626733KB/s, iops=153, runt= 90353msec
>>> read : io=84992MB, bw=965283KB/s, iops=235, runt= 90162msec
>>
>> I can't quite tell what's going on here, can you describe the test in
>> more detail?
>
> I've network booted my VM and then run the following command:
> export DISK=/dev/vda; (fio --filename=$DISK --direct=1 --rw=randwrite
> --bs=4k --size=200G --numjobs=50 --runtime=90 --group_reporting
> --name=file1;fio --filename=$DISK --direct=1 --rw=randread --bs=4k
> --size=200G --numjobs=50 --runtime=90 --group_reporting --name=file1;fio
> --filename=$DISK --direct=1 --rw=write --bs=4M --size=200G --numjobs=50
> --runtime=90 --group_reporting --name=file1;fio --filename=$DISK
> --direct=1 --rw=read --bs=4M --size=200G --numjobs=50 --runtime=90
> --group_reporting --name=file1 )|egrep " read| write"
>
> - write random 4k I/O
> - read random 4k I/O
> - write seq 4M I/O
> - read seq 4M I/O
>
> 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-07-02 20:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-29 10:46 speedup ceph / scaling / find the bottleneck Stefan Priebe - Profihost AG
2012-06-29 11:32 ` Alexandre DERUMIER
2012-06-29 11:49 ` Mark Nelson
2012-06-29 13:02 ` Stefan Priebe - Profihost AG
2012-06-29 13:11 ` Stefan Priebe - Profihost AG
2012-06-29 13:16 ` Stefan Priebe - Profihost AG
2012-06-29 13:22 ` Stefan Priebe - Profihost AG
2012-06-29 15:28 ` Sage Weil
2012-06-29 21:18 ` Stefan Priebe
2012-07-01 21:01 ` Stefan Priebe
2012-07-01 21:13 ` Mark Nelson
2012-07-01 21:27 ` Stefan Priebe
2012-07-02 5:02 ` Alexandre DERUMIER
2012-07-02 6:12 ` Stefan Priebe - Profihost AG
2012-07-02 16:51 ` Gregory Farnum
2012-07-02 19:22 ` Stefan Priebe
2012-07-02 20:30 ` Josh Durgin [this message]
2012-07-03 4:42 ` Alexandre DERUMIER
2012-07-03 4:42 ` Alexandre DERUMIER
2012-07-03 7:49 ` Stefan Priebe - Profihost AG
2012-07-03 15:31 ` Sage Weil
2012-07-03 18:20 ` Stefan Priebe
2012-07-05 21:33 ` Gregory Farnum
2012-07-06 3:50 ` Alexandre DERUMIER
2012-07-06 8:54 ` Stefan Priebe
2012-07-06 17:11 ` Gregory Farnum
2012-07-06 18:09 ` Stefan Priebe - Profihost AG
2012-07-06 18:17 ` Gregory Farnum
2012-07-09 18:21 ` Stefan Priebe
2012-07-03 19:16 ` Stefan Priebe
2012-07-02 13:19 ` Stefan Priebe - Profihost AG
2012-06-29 12:33 ` 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=4FF204DB.80709@inktank.com \
--to=josh.durgin@inktank.com \
--cc=aderumier@odiso.com \
--cc=ceph-devel@vger.kernel.org \
--cc=greg@inktank.com \
--cc=mark.nelson@inktank.com \
--cc=s.priebe@profihost.ag \
--cc=sage@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