<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 26, 2017 at 6:33 AM, Patrick O'Callaghan <span dir="ltr"><<a href="mailto:poc@usb.ve" target="_blank">poc@usb.ve</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Sun, 2017-03-26 at 10:58 +0100, Bronek Kozicki wrote:<br>
> Assuming you use libvirt, make sure to use vCPU pinning. For disk access, try cache='writeback' io='threads'. If you switch to scsio-vfio, this will give you the ability to define queue length which might additionally improve IO. Also, try QCOW2 format for guest disk, it might enable some additional optimizations. However given you host seem to have little spare capacity, YMMV<br>
<br>
</span>Thanks. I'm already using CPU pinning as I said. The disk options are<br>
both set to "hypervisor default" so I'll try changing them. I'd<br>
configured the guest disk as 'raw' assuming that would be faster than<br>
QCOW2 but I'll look into it.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div>Here's a link with some benchmarks. If configured correctly, QCOW2 can be more efficient than native i/o:</div><div><br></div><div><a href="http://jrs-s.net/2013/05/17/kvm-io-benchmarking/">http://jrs-s.net/2013/05/17/kvm-io-benchmarking/</a> </div></div></div></div>