From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1XI4-0007Xz-MZ for qemu-devel@nongnu.org; Wed, 25 Nov 2015 05:27:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1XI1-0001zp-So for qemu-devel@nongnu.org; Wed, 25 Nov 2015 05:27:08 -0500 Received: from mailpro.odiso.net ([89.248.209.98]:40754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1XI1-0001zh-Jl for qemu-devel@nongnu.org; Wed, 25 Nov 2015 05:27:05 -0500 Date: Wed, 25 Nov 2015 11:27:03 +0100 (CET) From: Alexandre DERUMIER Message-ID: <1889409144.174054246.1448447223250.JavaMail.zimbra@oxygem.tv> In-Reply-To: References: <1726113162.173817902.1448446101295.JavaMail.zimbra@oxygem.tv> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] poor virtio-scsi performance (fio testing) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vasiliy Tolstov Cc: qemu-devel >>I'm try with classic lvm - sometimes i get more iops, but stable results is the same =3D) I have tested with a raw file, qemu 2.4 + virtio-scsi (without iothread), I= 'm around 25k iops with an intel ssd 3500. (host cpu are xeon v3 3,1ghz) randrw: (g=3D0): rw=3Drandrw, bs=3D4K-4K/4K-4K/4K-4K, ioengine=3Dlibaio, io= depth=3D32 ... fio-2.1.11 Starting 10 processes Jobs: 4 (f=3D3): [m(2),_(3),m(1),_(3),m(1)] [100.0% done] [96211KB/96639KB/= 0KB /s] [24.6K/24.2K/0 iops] [eta 00m:00s] randrw: (groupid=3D0, jobs=3D10): err=3D 0: pid=3D25662: Wed Nov 25 11:25:2= 2 2015 read : io=3D5124.7MB, bw=3D97083KB/s, iops=3D24270, runt=3D 54047msec slat (usec): min=3D1, max=3D34577, avg=3D181.90, stdev=3D739.20 clat (usec): min=3D177, max=3D49641, avg=3D6511.31, stdev=3D3176.16 lat (usec): min=3D185, max=3D52810, avg=3D6693.55, stdev=3D3247.36 clat percentiles (usec): | 1.00th=3D[ 1704], 5.00th=3D[ 2576], 10.00th=3D[ 3184], 20.00th=3D[= 4016], | 30.00th=3D[ 4704], 40.00th=3D[ 5344], 50.00th=3D[ 5984], 60.00th=3D[= 6688], | 70.00th=3D[ 7456], 80.00th=3D[ 8512], 90.00th=3D[10304], 95.00th=3D[= 12224], | 99.00th=3D[17024], 99.50th=3D[19584], 99.90th=3D[26240], 99.95th=3D[= 29568], | 99.99th=3D[37632] bw (KB /s): min=3D 6690, max=3D12432, per=3D10.02%, avg=3D9728.49, std= ev=3D796.49 write: io=3D5115.1MB, bw=3D96929KB/s, iops=3D24232, runt=3D 54047msec slat (usec): min=3D1, max=3D37270, avg=3D188.68, stdev=3D756.21 clat (usec): min=3D98, max=3D54737, avg=3D6246.50, stdev=3D3078.27 lat (usec): min=3D109, max=3D56078, avg=3D6435.53, stdev=3D3134.23 clat percentiles (usec): | 1.00th=3D[ 1960], 5.00th=3D[ 2640], 10.00th=3D[ 3120], 20.00th=3D[= 3856], | 30.00th=3D[ 4512], 40.00th=3D[ 5088], 50.00th=3D[ 5664], 60.00th=3D[= 6304], | 70.00th=3D[ 7072], 80.00th=3D[ 8160], 90.00th=3D[ 9920], 95.00th=3D[= 11712], | 99.00th=3D[16768], 99.50th=3D[19328], 99.90th=3D[26496], 99.95th=3D[= 31104], | 99.99th=3D[42752] bw (KB /s): min=3D 7424, max=3D12712, per=3D10.02%, avg=3D9712.21, std= ev=3D768.32 lat (usec) : 100=3D0.01%, 250=3D0.01%, 500=3D0.02%, 750=3D0.03%, 1000= =3D0.05% lat (msec) : 2=3D1.49%, 4=3D19.18%, 10=3D68.69%, 20=3D10.10%, 50=3D0.45= % lat (msec) : 100=3D0.01% cpu : usr=3D1.28%, sys=3D8.94%, ctx=3D329299, majf=3D0, minf=3D7= 6 IO depths : 1=3D0.1%, 2=3D0.1%, 4=3D0.1%, 8=3D0.1%, 16=3D0.1%, 32=3D10= 0.0%, >=3D64=3D0.0% submit : 0=3D0.0%, 4=3D100.0%, 8=3D0.0%, 16=3D0.0%, 32=3D0.0%, 64= =3D0.0%, >=3D64=3D0.0% complete : 0=3D0.0%, 4=3D100.0%, 8=3D0.0%, 16=3D0.0%, 32=3D0.1%, 64= =3D0.0%, >=3D64=3D0.0% issued : total=3Dr=3D1311760/w=3D1309680/d=3D0, short=3Dr=3D0/w=3D0= /d=3D0 latency : target=3D0, window=3D0, percentile=3D100.00%, depth=3D32 Run status group 0 (all jobs): READ: io=3D5124.7MB, aggrb=3D97082KB/s, minb=3D97082KB/s, maxb=3D97082KB= /s, mint=3D54047msec, maxt=3D54047msec WRITE: io=3D5115.1MB, aggrb=3D96928KB/s, minb=3D96928KB/s, maxb=3D96928KB= /s, mint=3D54047msec, maxt=3D54047msec Disk stats (read/write): sdb: ios=3D1307835/1305417, merge=3D2523/2770, ticks=3D4309296/3954628, i= n_queue=3D8274916, util=3D99.95% ----- Mail original ----- De: "Vasiliy Tolstov" =C3=80: "aderumier" Cc: "qemu-devel" Envoy=C3=A9: Mercredi 25 Novembre 2015 11:12:33 Objet: Re: [Qemu-devel] poor virtio-scsi performance (fio testing) 2015-11-25 13:08 GMT+03:00 Alexandre DERUMIER :=20 > Maybe could you try to create 2 disk in your vm, each with 1 dedicated io= thread,=20 >=20 > then try to run fio on both disk at the same time, and see if performance= improve.=20 >=20 Thats fine, but by default i have only one disk inside vm, so i prefer=20 increase single disk speed.=20 >=20 > But maybe they are some write overhead with lvmthin (because of copy on w= rite) and sheepdog.=20 >=20 > Do you have tried with classic lvm or raw file ?=20 I'm try with classic lvm - sometimes i get more iops, but stable=20 results is the same =3D)=20 --=20 Vasiliy Tolstov,=20 e-mail: v.tolstov@selfip.ru=20