[libvirt-users] Lots of threads and increased IO load

Eric Blake eblake at redhat.com
Wed Nov 13 15:38:03 UTC 2013


On 11/13/2013 08:31 AM, Gergely Horváth wrote:
> The second problem came when I looked at `iotop`, to see how much IO
> read and write is going on. The computer, that was doing the copying
> easily had like 20-30 threads writing pieces to the disk. Some of the
> threads are obviously "processor emulators" - they been running since
> the birth of the VM, but what are these other threads?

These are qemu threads, right?  Then asking on the qemu list is a more
appropriate list; my understanding is that qemu creates transient
threads to handle aio requests on an as-needed basis, and that it is
qemu that decides when these threads are needed or not (and not libvirt).

> Two questions than, to sum up everything:
> * How can I control and maybe decrease the number of threads spawned for
> a virtual machine?

I don't know if qemu exposes a knob for limiting the number of aio
helper threads it can spawn, or even if that is a good idea.

> * How can I know what is the default IO caching for a VM, and what
> caching mechanism/policy should I set to minimise IO latency (i.e. I do
> not really care if the data is written to the disk later than the guest
> thinks)

What domain XML are you using?  Yes, there are different disk cache
policies (writethrough vs. none) which have definite performance vs.
risk tradeoffs according to the amount of IO latency you want the guest
to see; but again, the qemu list may be a better help in determining
which policy is best for your needs.  Once you know the policy you want,
then we can help you figure out how to represent it in the domain XML.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20131113/7ded9cc9/attachment.sig>


More information about the libvirt-users mailing list