CEPH filesystem development
 help / color / mirror / Atom feed
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

  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