All of lore.kernel.org
 help / color / mirror / Atom feed
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

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