Thanks Alexandre!
We were using ceph - Hammer before and we never had these performance issues with qemu-img convert.
Is there anything changed from Hammer to Jewel that might be affecting the qemu-img convert performance?
On Fri, Jul 21, 2017 at 2:24 PM, Alexandre DERUMIER <aderumier@xxxxxxxxx> wrote:
It's already in qemu 2.9
http://git.qemu.org/?p=qemu.git;a=commit;h= 2d9187bc65727d9dd63e2c410b5500 add3db0b0d
"
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
On Thu, Jul 13, 2017 at 8:57 AM, Irek Fasikhov < [ mailto:malmyzh@xxxxxxxxx | malmyzh@xxxxxxxxx ] > wrote: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@trilio.io | 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:
> 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
Regards,
mahesh j
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
