|
From: | ein |
Subject: | Re: [Qemu-devel] Very poor IO performance which looks like some design problem. |
Date: | Mon, 13 Apr 2015 14:28:50 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 |
Dear Fam, Check out my update please: http://lists.nongnu.org/archive/html/qemu-devel/2015-04/msg01318.html Using aio=native,cache=none results in 500%-2000% performance drop comparing to bare metal and 300%-1000% comparing to aio=threads,cache=unsafe. I'd like to know what numbers should I expect. Can somebody share what results do you have with aio=native in sequential IO ops? And of course please add some info about disk and controller configuration. Maybe there's some bug in current version of Qemu in Debian 8 - testing. Package details: https://packages.debian.org/jessie/qemu-kvm . Version: qemu-kvm (1:2.1+dfsg-11) On 04/13/2015 03:45 AM, Fam Zheng
wrote:
On Fri, 04/10 22:38, ein wrote:Qemu creates more than 70 threads and everyone of them tries to write to disk, which results in: 1. High I/O time. 2. Large latency. 2. Poor sequential read/write speeds. When I limited number of cores, I guess I limited number of threads as well. That's why I got better numbers. I've tried to combine AIO native and thread setting with deadline scheduler. Native AIO was much more worse. The final question, is there any way to prevent Qemu for making so large number of processes when VM does only one sequential R/W operation?aio=native will make QEMU only submit IO from the IO thread, so you shouldn't see 70 threads with that. And that should usually be a better option for performance. Fam |
0xF2C6EA10.asc
Description: application/pgp-keys
[Prev in Thread] | Current Thread | [Next in Thread] |