From: Denis Fondras <ceph@ledeuns.net>
To: ceph-devel@vger.kernel.org
Subject: Re: Ceph performance improvement
Date: Fri, 24 Aug 2012 18:41:28 +0200 [thread overview]
Message-ID: <5037AEB8.5030905@ledeuns.net> (raw)
In-Reply-To: <5034D210.8060109@inktank.com>
Hello Mark,
> Not sure what version of glibc Wheezy has, but try to make sure you have
> one that supports syncfs (you'll also need a semi-new kernel, 3.0+
> should be fine).
>
Wheezy has a fairly recent kernel :
# uname -a
Linux ceph-osd-0 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012
x86_64 GNU/Linux
>
> default values are quite a bit lower for most of these. You may want to
> play with them and see if it has an effect.
>
I found these values on this ML. I haven't tried to tweak them but it is
much better than with default values. I will try to change it.
>
> RBD caching should definitely be enabled for a test like this. I'd be
> surprised if you got 42MB/s without it though...
>
root@ceph-osd-0:~# ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok
config show | grep rbd
debug_rbd = 0/5
rbd_cache = false
rbd_cache_size = 33554432
rbd_cache_max_dirty = 25165824
rbd_cache_target_dirty = 16777216
rbd_cache_max_dirty_age = 1
In my opinions, performances from RBD client are decent.
Unfortunately I need concurrent access and CephFS is really appealing in
that respect.
>
> Ouch, that's taking a while! In addition to the comments that David
> made, be aware that you are also testing the metadata server with
> cephFS. Right now that's not getting a lot of attention as we are
> primarily focusing on RADOS performance at the moment. For this kind of
> test though, distributed filesystems will never be as good as local
> disks...
>
Yes, it may be the MDS that is the bottleneck. Perhaps I should have a
lot of them...
>
> Are you putting both journals on the SSD when you add an OSD? If so,
> what's the throughput your SSD can sustain?
>
Both journals are on the SSD. It seems that when I do "ceph-osd -i $id
--mkfs --mkkey" it creates the journal according to the settings in
ceph.conf.
I did some tests and my SSD drive is somewhat broken... Crucial C300 is
a bit old and can only do 80MB/s writing.
>
> You may want to check and see how big the IOs going to disk are on the
> OSD node, and how quickly you are filling up the journal vs writing out
> to disk. "collectl -sD -oT" will give you a nice report. Iostat can
> probably tell you all of the same stuff with the right flags.
>
Thank you for that tool.
Denis
next prev parent reply other threads:[~2012-08-24 16:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-22 8:54 Ceph performance improvement Denis Fondras
2012-08-22 10:24 ` David McBride
2012-08-22 12:10 ` Denis Fondras
2012-08-23 3:51 ` Mark Kirkwood
2012-08-22 12:35 ` Mark Nelson
2012-08-22 12:42 ` Alexandre DERUMIER
2012-08-24 16:41 ` Denis Fondras [this message]
2012-08-24 17:42 ` Wido den Hollander
2012-08-22 16:03 ` Tommi Virtanen
2012-08-22 16:23 ` Denis Fondras
2012-08-22 16:29 ` Tommi Virtanen
2012-08-22 19:12 ` Ceph performance improvement / journal on block-dev Dieter Kasper (KD)
2012-08-22 23:19 ` Tommi Virtanen
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=5037AEB8.5030905@ledeuns.net \
--to=ceph@ledeuns.net \
--cc=ceph-devel@vger.kernel.org \
/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