From: Roman Alekseev <rs.alekseev@gmail.com>
To: Gregory Farnum <greg@inktank.com>
Cc: Sam Lang <sam.lang@inktank.com>, ceph-devel@vger.kernel.org
Subject: Re: Ceph performance
Date: Tue, 30 Oct 2012 14:04:56 +0400 [thread overview]
Message-ID: <508FA648.1060401@gmail.com> (raw)
In-Reply-To: <CAPYLRzhfv08vS0CNEHP2d6+M1FpwNDgtU28DTYn9vjFmLnP9XA@mail.gmail.com>
On 30.10.2012 13:10, Gregory Farnum wrote:
> On Tue, Oct 30, 2012 at 9:27 AM, Roman Alekseev <rs.alekseev@gmail.com> wrote:
>> On 29.10.2012 22:57, Sam Lang wrote:
>>>
>>> Hi Roman,
>>>
>>> Is this with the ceph fuse client or the ceph kernel module?
>>>
>>> Its not surprising that the local file system (/home) is so much faster
>>> than a mounted ceph volume, especially the first time the directory tree is
>>> traversed (metadata results are cached at the client to improve
>>> performance). Try running the same find command on the ceph volume and see
>>> if the cached results at the client improve performance at all.
>>>
>>> In order to understand what the performance of ceph should be capable of
>>> doing with your deployment for this specific workload, you should run iperf
>>> between two nodes to get an idea of your latency limits.
>>>
>>> Also, I noticed that the real timings you listed for ceph and /home are
>>> offset by exactly 17 minutes (user and sys are identical). Was that a
>>> copy/paste error, by chance?
>>>
>>> -sam
>>>
>>> On 10/29/2012 09:01 AM, Roman Alekseev wrote:
>>>> Hi,
>>>>
>>>> Kindly guide me how to improve performance on the cluster which consist
>>>> of 5 dedicated servers:
>>>>
>>>> - ceph.conf: http://pastebin.com/hT3qEhUF
>>>> - file system on all drives is ext4
>>>> - mount options "user_xattr"
>>>> - each server has :
>>>> CPU:Intel® Xeon® Processor E5335(8M Cache, 2.00 GHz, 1333 MHz FSB) x2
>>>> MEM: 4Gb DDR2
>>>> - 1Gb network
>>>>
>>>> Simple test:
>>>>
>>>> mounted as ceph
>>>> root@client1:/mnt/mycephfs# time find . | wc -l
>>>> 83932
>>>>
>>>> real 17m55.399s
>>>> user 0m0.152s
>>>> sys 0m1.528s
>>>>
>>>> on 1 HDD:
>>>>
>>>> root@client1:/home# time find . | wc -l
>>>> 83932
>>>>
>>>> real 0m55.399s
>>>> user 0m0.152s
>>>> sys 0m1.528s
>>>>
>>>> Please help me to find out the issue. Thanks.
>>>>
>> Hi Sam,
>>
>> I use the Ceph fs only as kernel module, because we need to get its
>> powerful performance but as I can see it is slower then distributed file
>> system based on fuse, for example, MooseFS performed the same test for 3
>> min.
>> Here is the result iperf test beetwen client and osd server:
>> root@asrv151:~# iperf -c client -i 1
>> ------------------------------------------------------------
>> Client connecting to clientIP, TCP port 5001
>> TCP window size: 96.1 KByte (default)
>> ------------------------------------------------------------
>> [ 3] local osd_server port 50106 connected with clientIP port 5001
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0- 1.0 sec 112 MBytes 941 Mbits/sec
>> [ 3] 1.0- 2.0 sec 110 MBytes 924 Mbits/sec
>> [ 3] 2.0- 3.0 sec 108 MBytes 905 Mbits/sec
>> [ 3] 3.0- 4.0 sec 109 MBytes 917 Mbits/sec
>> [ 3] 4.0- 5.0 sec 110 MBytes 926 Mbits/sec
>> [ 3] 5.0- 6.0 sec 109 MBytes 915 Mbits/sec
>> [ 3] 6.0- 7.0 sec 110 MBytes 926 Mbits/sec
>> [ 3] 7.0- 8.0 sec 108 MBytes 908 Mbits/sec
>> [ 3] 8.0- 9.0 sec 107 MBytes 897 Mbits/sec
>> [ 3] 9.0-10.0 sec 106 MBytes 886 Mbits/sec
>> [ 3] 0.0-10.0 sec 1.06 GBytes 914 Mbits/sec
>>
>> ceph -w results:
>>
>> health HEALTH_OK
>> monmap e3: 3 mons at {a=mon.a:6789/0,b=mon.b:6789/0,c=mon.c:6789/0},
>> election epoch 10, quorum 0,1,2 a,b,c
>> osdmap e132: 5 osds: 5 up, 5 in
>> pgmap v11720: 384 pgs: 384 active+clean; 1880 MB data, 10679 MB used,
>> 5185 GB / 5473 GB avail
>> mdsmap e4: 1/1/1 up {0=a=up:active}
>>
>> 2012-10-30 12:23:09.830677 osd.2 [WRN] slow request 30.135787 seconds old,
>> received at 2012-10-30 12:22:39.694780: osd_op(mds.0.1:309216
>> 10000017163.00000000 [setxattr path (69),setxattr parent (196),tmapput
>> 0~596] 1.724c80f7) v4 currently waiting for sub ops
>> 2012-10-30 12:23:10.109637 mon.0 [INF] pgmap v11720: 384 pgs: 384
>> active+clean; 1880 MB data, 10679 MB used, 5185 GB / 5473 GB avail
>> 2012-10-30 12:23:12.918038 mon.0 [INF] pgmap v11721: 384 pgs: 384
>> active+clean; 1880 MB data, 10680 MB used, 5185 GB / 5473 GB avail
>> 2012-10-30 12:23:13.977044 mon.0 [INF] pgmap v11722: 384 pgs: 384
>> active+clean; 1880 MB data, 10681 MB used, 5185 GB / 5473 GB avail
>> 2012-10-30 12:23:10.587391 osd.3 [WRN] 6 slow requests, 6 included below;
>> oldest blocked for > 30.808352 secs
>> 2012-10-30 12:23:10.587398 osd.3 [WRN] slow request 30.808352 seconds old,
>> received at 2012-10-30 12:22:39.778971: osd_op(mds.0.1:308701 200.000002e5
>> [write 976010~5402] 1.adbeb1a) v4 currently waiting for sub ops
>> 2012-10-30 12:23:10.587403 osd.3 [WRN] slow request 30.796417 seconds old,
>> received at 2012-10-30 12:22:39.790906: osd_op(mds.0.1:308702 200.000002e5
>> [write 981412~6019] 1.adbeb1a) v4 currently waiting for sub ops
>> 2012-10-30 12:23:10.587408 osd.3 [WRN] slow request 30.796347 seconds old,
>> received at 2012-10-30 12:22:39.790976: osd_op(mds.0.1:308703 200.000002e5
>> [write 987431~61892] 1.adbeb1a) v4 currently waiting for sub ops
>> 2012-10-30 12:23:10.587413 osd.3 [WRN] slow request 30.530228 seconds old,
>> received at 2012-10-30 12:22:40.057095: osd_op(mds.0.1:308704 200.000002e5
>> [write 1049323~6630] 1.adbeb1a) v4 currently waiting for sub ops
>> 2012-10-30 12:23:10.587417 osd.3 [WRN] slow request 30.530027 seconds old,
>> received at 2012-10-30 12:22:40.057296: osd_op(mds.0.1:308705 200.000002e5
>> [write 1055953~20679] 1.adbeb1a) v4 currently waiting for sub ops
>>
>>
>> At the same time I'm copy data to ceph mounted storage.
>>
>> I dunno what can I do to resolve this problem :(
>> Any advices will be greatly appreciated.
> Is it the same client copying data into cephfs or a different one?
> I see here that you have several slow requests; it looks like maybe
> you're overloading your disks. That could impact metadata lookups if
> the MDS doesn't have everything cached; have you tried running this
> test without data ingest? (Obviously we'd like it to be faster even
> so, but if it's disk contention there's not a lot we can do.)
> -Greg
Dear Greg,
Yes, this was the same client. Sorry, could you please explain me with
more details how can I "test without data ingest"?
Also I can rebuild my cluster from scratch and make all tests again.
I have 5 dedicated servers and I think if I create ceph cluster from
them it shouldn't be slower then the same cluster based on fuse
technology. Am I right?
Thanks.
--
Kind regards,
R. Alekseev
--
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-10-30 10:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-29 14:01 Ceph performance Roman Alekseev
2012-10-29 18:57 ` Sam Lang
2012-10-30 8:27 ` Roman Alekseev
2012-10-30 9:10 ` Gregory Farnum
2012-10-30 9:54 ` Maciej Gałkiewicz
[not found] ` <508FAB9A.20307@gmail.com>
2012-10-30 10:47 ` Maciej Gałkiewicz
2012-10-30 10:53 ` Roman Alekseev
2012-10-30 10:57 ` Maciej Gałkiewicz
2012-10-30 10:04 ` Roman Alekseev [this message]
2012-10-30 10:14 ` Gregory Farnum
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=508FA648.1060401@gmail.com \
--to=rs.alekseev@gmail.com \
--cc=ceph-devel@vger.kernel.org \
--cc=greg@inktank.com \
--cc=sam.lang@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