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 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.