Re: qemu-img convert vs rbd import performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It's already in qemu 2.9

http://git.qemu.org/?p=qemu.git;a=commit;h=2d9187bc65727d9dd63e2c410b5500add3db0b0d


"
This patches introduces 2 new cmdline parameters. The -m parameter to specify
the number of coroutines running in parallel (defaults to 8). And the -W parameter to
allow qemu-img to write to the target out of order rather than sequential. This improves
performance as the writes do not have to wait for each other to complete.
"

----- Mail original -----
De: "aderumier" <aderumier@xxxxxxxxx>
À: "dillaman" <dillaman@xxxxxxxxxx>
Cc: "Mahesh Jambhulkar" <mahesh.jambhulkar@xxxxxxxxx>, "ceph-users" <ceph-users@xxxxxxxxxxxxxx>
Envoyé: Vendredi 21 Juillet 2017 10:51:21
Objet: Re:  qemu-img convert vs rbd import performance

Hi, 

they are an RFC here: 

"[RFC] qemu-img: make convert async" 
https://patchwork.kernel.org/patch/9552415/ 


maybe it could help 


----- Mail original ----- 
De: "Jason Dillaman" <jdillama@xxxxxxxxxx> 
À: "Mahesh Jambhulkar" <mahesh.jambhulkar@xxxxxxxxx> 
Cc: "ceph-users" <ceph-users@xxxxxxxxxxxxxx> 
Envoyé: Jeudi 20 Juillet 2017 15:20:32 
Objet: Re:  qemu-img convert vs rbd import performance 

Running a similar 20G import test within a single OSD VM-based cluster, I see the following: 
$ time qemu-img convert -p -O raw -f raw ~/image rbd:rbd/image 
(100.00/100%) 

real 3m20.722s 
user 0m18.859s 
sys 0m20.628s 

$ time rbd import ~/image 
Importing image: 100% complete...done. 

real 2m11.907s 
user 0m12.236s 
sys 0m20.971s 

Examining the IO patterns from qemu-img, I can see that it is effectively using synchronous IO (i.e. only a single write is in-flight at a time), whereas "rbd import" will send up to 10 (by default) IO requests concurrently. Therefore, the higher the latencies to your cluster, the worse qemu-img will perform as compared to "rbd import". 



On Thu, Jul 20, 2017 at 5:07 AM, Mahesh Jambhulkar < [ mailto:mahesh.jambhulkar@xxxxxxxxx | mahesh.jambhulkar@xxxxxxxxx ] > wrote: 



Adding rbd readahead disable after bytes = 0 did not help. 

[root@cephlarge mnt]# time qemu-img convert -p -O raw /mnt/data/workload_326e8a43-a90a-4fe9-8aab-6d33bcdf5a05/snapshot_9f0cee13-8200-4562-82ec-1fb9f234bcd8/vm_id_05e9534e-5c84-4487-9613-1e0e227e4c1a/vm_res_id_24291e4b-93d2-47ad-80a8-bf3c395319b9_vdb/66582225-6539-4e5e-9b7a-59aa16739df1 rbd:volumes/24291e4b-93d2-47ad-80a8-bf3c395319b9 (100.00/100%) 

real 4858m13.822s 
user 73m39.656s 
sys 32m11.891s 
It took 80 hours to complete. 

Also, its not feasible to test this with huge 465GB file every time. So I tested qemu-img convert with a 20GB file. 

Parameters Time taken 
-t writeback 38mins 
-t none 38 mins 
-S 4k 38 mins 
With client options mentions by Irek Fasikhov 40 mins 
The time taken is almost the same. 

On Thu, Jul 13, 2017 at 6:40 PM, Jason Dillaman < [ mailto:jdillama@xxxxxxxxxx | jdillama@xxxxxxxxxx ] > wrote: 

 
On Thu, Jul 13, 2017 at 8:57 AM, Irek Fasikhov < [ mailto:malmyzh@xxxxxxxxx | malmyzh@xxxxxxxxx ] > wrote: 
> rbd readahead disable after bytes = 0 


There isn't any reading from an RBD image in this example -- plus 
readahead disables itself automatically after the first 50MBs of IO 
(i.e. after the OS should have had enough time to start its own 
readahead logic). 

-- 
Jason 






-- 
Regards, 
mahesh j 

 




-- 
Jason 

_______________________________________________ 
ceph-users mailing list 
ceph-users@xxxxxxxxxxxxxx 
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com 

_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux