From: Stefan Priebe <s.priebe@profihost.ag>
To: Mark Nelson <mnelson@redhat.com>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: speed decrease since firefly,giant,hammer the 2nd try
Date: Tue, 10 Feb 2015 22:11:32 +0100 [thread overview]
Message-ID: <54DA7404.4060201@profihost.ag> (raw)
In-Reply-To: <54DA6BB9.7000306@redhat.com>
Am 10.02.2015 um 21:36 schrieb Mark Nelson:
>
>
> On 02/10/2015 02:24 PM, Stefan Priebe wrote:
>> Am 10.02.2015 um 20:40 schrieb Mark Nelson:
>>> On 02/10/2015 01:13 PM, Stefan Priebe wrote:
>>>> Am 10.02.2015 um 20:10 schrieb Mark Nelson:
>>>>> On 02/10/2015 12:55 PM, Stefan Priebe wrote:
>>>>>> Hello,
>>>>>>
>>>>>> last year in june i already reported this but there was no real
>>>>>> result.
>>>>>> (http://lists.ceph.com/pipermail/ceph-users-ceph.com/2014-July/041070.html)
>>>>>>
>>>>>>
>>>>>>
>>>>>> I then had the hope that this will be fixed itself when hammer is
>>>>>> released. Now i tried hammer an the results are bad as before.
>>>>>>
>>>>>> Since firefly librbd1 / librados2 are 20% slower for 4k random iop/s
>>>>>> than dumpling - this is also the reason why i still stick to
>>>>>> dumpling.
>>>>>>
>>>>>> I've now modified my test again to be a bit more clear.
>>>>>>
>>>>>> Ceph cluster itself completely dumpling.
>>>>>>
>>>>>> librbd1 / librados from dumpling (fio inside qemu): 23k iop/s for
>>>>>> random
>>>>>> 4k writes
>>>>>>
>>>>>> - stopped qemu
>>>>>> - cp -ra firefly_0.80.8/usr/lib/librados.so.2.0.0 /usr/lib/
>>>>>> - cp -ra firefly_0.80.8/usr/lib/librbd.so.1.0.0 /usr/lib/
>>>>>> - start qemu
>>>>>>
>>>>>> same fio, same qemu, same vm, same host, same ceph dumpling storage,
>>>>>> different librados / librbd: 16k iop/s for random 4k writes
>>>>>>
>>>>>> What's wrong with librbd / librados2 since firefly?
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> Just off the top of my head, some questions to investigate:
>>>>>
>>>>> What happens to single op latencies?
>>>>
>>>> How to test this?
>>>
>>> try your random 4k write test using libaio, direct IO, and iodepth=1.
>>> Actually it would be interesting to know how it is with higher IO depths
>>> as well (I assume this is what you are doing now?) Basically I want to
>>> know if single-op latency changes and whether or not it gets hidden or
>>> exaggerated with lots of concurrent IO.
>>
>> dumpling:
>> ioengine=libaio and iodepth=32 with 32 threads:
>>
>> Jobs: 32 (f=32): [wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww] [100.0% done]
>> [0K/85224K /s] [0 /21.4K iops] [eta 00m:00s]
>>
>> ioengine=libaio and iodepth=1 with 32 threads:
>>
>> Jobs: 32 (f=32): [wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww] [100.0% done]
>> [0K/79064K /s] [0 /19.8K iops] [eta 00m:00s]
>>
>> firefly:
>> ioengine=libaio and iodepth=32 with 32 threads:
>>
>> Jobs: 32 (f=32): [wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww] [100.0% done]
>> [0K/55781K /s] [0 /15.4K iops] [eta 00m:00s]
>>
>> ioengine=libaio and iodepth=1 with 32 threads:
>>
>> Jobs: 32 (f=32): [wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww] [100.0% done]
>> [0K/46055K /s] [0 /11.6K iops] [eta 00m:00s]
>>
>
> Sorry, please do this with only 1 thread. If you can include the
> latency results too that would be great.
Sorry here again.
Cache on:
dumpling:
file1: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=1
2.0.8
Starting 1 thread
Jobs: 1 (f=1): [w] [100.0% done] [0K/42892K /s] [0 /10.8K iops] [eta
00m:00s]
file1: (groupid=0, jobs=1): err= 0: pid=3203
write: io=1273.1MB, bw=43483KB/s, iops=10870 , runt= 30001msec
slat (usec): min=5 , max=183 , avg= 8.99, stdev= 1.78
clat (usec): min=0 , max=6378 , avg=81.15, stdev=44.09
lat (usec): min=59 , max=6390 , avg=90.35, stdev=44.22
clat percentiles (usec):
| 1.00th=[ 59], 5.00th=[ 62], 10.00th=[ 64], 20.00th=[ 66],
| 30.00th=[ 69], 40.00th=[ 71], 50.00th=[ 74], 60.00th=[ 80],
| 70.00th=[ 87], 80.00th=[ 95], 90.00th=[ 105], 95.00th=[ 114],
| 99.00th=[ 135], 99.50th=[ 145], 99.90th=[ 179], 99.95th=[ 237],
| 99.99th=[ 2320]
bw (KB/s) : min=36176, max=46816, per=99.96%, avg=43465.49,
stdev=2169.33
lat (usec) : 2=0.01%, 4=0.01%, 20=0.01%, 50=0.01%, 100=85.24%
lat (usec) : 250=14.71%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%
cpu : usr=2.95%, sys=12.29%, ctx=329519, majf=0, minf=133
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued : total=r=0/w=326130/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=1273.1MB, aggrb=43482KB/s, minb=43482KB/s, maxb=43482KB/s,
mint=30001msec, maxt=30001msec
Disk stats (read/write):
sdb: ios=166/325241, merge=0/0, ticks=8/24624, in_queue=24492,
util=81.64%
firefly:
file1: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=1
2.0.8
Starting 1 thread
Jobs: 1 (f=1): [w] [100.0% done] [0K/44588K /s] [0 /11.2K iops] [eta
00m:00s]
file1: (groupid=0, jobs=1): err= 0: pid=2904
write: io=1212.1MB, bw=41401KB/s, iops=10350 , runt= 30001msec
slat (usec): min=5 , max=464 , avg= 8.95, stdev= 2.34
clat (usec): min=0 , max=4410 , avg=85.81, stdev=41.82
lat (usec): min=59 , max=4418 , avg=94.96, stdev=41.97
clat percentiles (usec):
| 1.00th=[ 59], 5.00th=[ 63], 10.00th=[ 65], 20.00th=[ 68],
| 30.00th=[ 72], 40.00th=[ 76], 50.00th=[ 80], 60.00th=[ 85],
| 70.00th=[ 94], 80.00th=[ 102], 90.00th=[ 112], 95.00th=[ 122],
| 99.00th=[ 145], 99.50th=[ 155], 99.90th=[ 189], 99.95th=[ 239],
| 99.99th=[ 2192]
bw (KB/s) : min=34352, max=45992, per=99.91%, avg=41363.80,
stdev=3314.63
lat (usec) : 2=0.01%, 50=0.01%, 100=77.26%, 250=22.69%, 500=0.02%
lat (usec) : 750=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%
cpu : usr=2.92%, sys=11.63%, ctx=313889, majf=0, minf=133
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued : total=r=0/w=310521/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=1212.1MB, aggrb=41401KB/s, minb=41401KB/s, maxb=41401KB/s,
mint=30001msec, maxt=30001msec
Disk stats (read/write):
sdb: ios=166/309726, merge=0/0, ticks=16/24772, in_queue=24688,
util=82.30%
sorry the old cache off results were wrong here are new ones also with
only one thread:
dumpling:
Jobs: 1 (f=1): [w] [100.0% done] [0K/2140K /s] [0 /535 iops] [eta 00m:00s]
file1: (groupid=0, jobs=1): err= 0: pid=2906
write: io=64424KB, bw=2147.5KB/s, iops=536 , runt= 30001msec
slat (usec): min=14 , max=848 , avg=30.27, stdev= 8.70
clat (usec): min=914 , max=74110 , avg=1826.25, stdev=604.49
lat (usec): min=1395 , max=74138 , avg=1857.26, stdev=604.48
clat percentiles (usec):
| 1.00th=[ 1592], 5.00th=[ 1656], 10.00th=[ 1688], 20.00th=[ 1736],
| 30.00th=[ 1768], 40.00th=[ 1784], 50.00th=[ 1816], 60.00th=[ 1832],
| 70.00th=[ 1864], 80.00th=[ 1896], 90.00th=[ 1928], 95.00th=[ 1960],
| 99.00th=[ 2064], 99.50th=[ 2384], 99.90th=[ 5024], 99.95th=[ 5600],
| 99.99th=[11712]
bw (KB/s) : min= 1768, max= 2240, per=100.00%, avg=2149.53,
stdev=56.30
lat (usec) : 1000=0.01%
lat (msec) : 2=97.67%, 4=2.11%, 10=0.20%, 20=0.01%, 100=0.01%
cpu : usr=0.72%, sys=2.12%, ctx=19289, majf=0, minf=133
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued : total=r=0/w=16106/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=64424KB, aggrb=2147KB/s, minb=2147KB/s, maxb=2147KB/s,
mint=30001msec, maxt=30001msec
Disk stats (read/write):
sdb: ios=168/16067, merge=0/0, ticks=164/29004, in_queue=29144,
util=96.93%
firefly:
file1: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=1
2.0.8
Starting 1 thread
Jobs: 1 (f=1): [w] [100.0% done] [0K/2141K /s] [0 /535 iops] [eta 00m:00s]
file1: (groupid=0, jobs=1): err= 0: pid=3034
write: io=63100KB, bw=2103.3KB/s, iops=525 , runt= 30001msec
slat (usec): min=17 , max=388 , avg=33.26, stdev= 6.55
clat (usec): min=1392 , max=54698 , avg=1862.25, stdev=478.79
lat (usec): min=1507 , max=54716 , avg=1896.28, stdev=478.69
clat percentiles (usec):
| 1.00th=[ 1624], 5.00th=[ 1688], 10.00th=[ 1720], 20.00th=[ 1768],
| 30.00th=[ 1800], 40.00th=[ 1832], 50.00th=[ 1848], 60.00th=[ 1880],
| 70.00th=[ 1896], 80.00th=[ 1928], 90.00th=[ 1960], 95.00th=[ 1992],
| 99.00th=[ 2096], 99.50th=[ 2512], 99.90th=[ 5344], 99.95th=[ 5984],
| 99.99th=[11840]
bw (KB/s) : min= 1760, max= 2160, per=100.00%, avg=2104.68,
stdev=49.36
lat (msec) : 2=95.18%, 4=4.57%, 10=0.23%, 20=0.01%, 100=0.01%
cpu : usr=0.88%, sys=2.09%, ctx=18938, majf=0, minf=133
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued : total=r=0/w=15775/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=63100KB, aggrb=2103KB/s, minb=2103KB/s, maxb=2103KB/s,
mint=30001msec, maxt=30001msec
Disk stats (read/write):
sdb: ios=170/15740, merge=0/0, ticks=268/28856, in_queue=29116,
util=96.45%
>>>>> How's CPU usage? (Does perf report show anything useful?)
>>>>> Can you get trace data?
>>>>
>>>> I'm not familiar with trace or perf - what should do exactly?
>>>
>>> you may need extra packages. Basically on VM host, during the test with
>>> each library you'd do:
>>>
>>> sudo perf record -a -g dwarf -F 99
>>> (ctrl+c after a while)
>>> sudo perf report --stdio > foo.txt
>>>
>>> if you are on a kernel that doesn't have libunwind support:
>>>
>>> sudo perf record -a -g
>>> (ctrl+c after a while)
>>> sudo perf report --stdio > foo.txt
>>>
>>> Then look and see what's different. This may not catch anything though.
>>
>> Don't have unwind.
>
> Too bad, oh well.
>
>> Output is only full of hex values.
>
> You'll at least need the correct debug symbols either compiled into the
> library or available wherever your OS puts them. Sometimes the perf
> cache needs to be manually edited so they point to the right place, it's
> super annoying.
mhm i installed librbd1-dbg and librados2-dbg - but the output still
looks useless to me. Should i upload it somewhere?
Stefan
next prev parent reply other threads:[~2015-02-10 21:11 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 18:55 speed decrease since firefly,giant,hammer the 2nd try Stefan Priebe
2015-02-10 19:05 ` Gregory Farnum
2015-02-10 19:12 ` Stefan Priebe
2015-02-10 19:10 ` Mark Nelson
2015-02-10 19:13 ` Stefan Priebe
2015-02-10 19:40 ` Mark Nelson
2015-02-10 20:24 ` Stefan Priebe
2015-02-10 20:36 ` Mark Nelson
2015-02-10 21:11 ` Stefan Priebe [this message]
2015-02-10 21:38 ` Mark Nelson
2015-02-10 22:18 ` Stefan Priebe
2015-02-11 4:45 ` Mark Nelson
2015-02-11 5:42 ` Stefan Priebe
[not found] ` <1032317804.358821.1423634390142.JavaMail.zimbra@oxygem.tv>
2015-02-11 5:59 ` Alexandre DERUMIER
2015-02-15 18:40 ` Stefan Priebe
[not found] ` <1880785650.892634.1424077856500.JavaMail.zimbra@oxygem.tv>
2015-02-16 9:11 ` Alexandre DERUMIER
2015-02-16 14:50 ` Stefan Priebe - Profihost AG
2015-02-16 15:35 ` Mark Nelson
2015-02-16 15:36 ` Alexandre DERUMIER
2015-02-16 19:10 ` Stefan Priebe
[not found] ` <198700848.1004998.1424124086231.JavaMail.zimbra@oxygem.tv>
2015-02-16 22:01 ` Alexandre DERUMIER
[not found] ` <1760409866.980984.1424105112443.JavaMail.zimbra@oxygem.tv>
2015-02-16 16:45 ` Alexandre DERUMIER
2015-02-16 19:40 ` Stefan Priebe
2015-02-16 21:22 ` Stefan Priebe
[not found] ` <2015376321.1005004.1424124122884.JavaMail.zimbra@oxygem.tv>
2015-02-16 22:02 ` Alexandre DERUMIER
2015-02-16 22:08 ` Stefan Priebe - Profihost AG
[not found] ` <1975903570.1005549.1424125095286.JavaMail.zimbra@oxygem.tv>
2015-02-16 22:18 ` Alexandre DERUMIER
2015-02-17 9:15 ` Stefan Priebe - Profihost AG
[not found] ` <1999473015.1036573.1424165503094.JavaMail.zimbra@oxygem.tv>
2015-02-17 9:31 ` Alexandre DERUMIER
[not found] ` <764258391.358931.1423634637318.JavaMail.zimbra@oxygem.tv>
2015-02-11 6:04 ` Alexandre DERUMIER
[not found] ` <1971513819.362434.1423640637237.JavaMail.zimbra@oxygem.tv>
2015-02-11 7:44 ` Alexandre DERUMIER
2015-02-11 8:32 ` 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=54DA7404.4060201@profihost.ag \
--to=s.priebe@profihost.ag \
--cc=ceph-devel@vger.kernel.org \
--cc=mnelson@redhat.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