Re: Performace data when running Windows VMs

[Avi Kivity <avi@redhat.com>]

On 08/26/2009 07:14 PM, Andrew Theurer wrote:
> On Wed, 2009-08-26 at 18:44 +0300, Avi Kivity wrote:
>    
>> On 08/26/2009 05:57 PM, Andrew Theurer wrote:
>>      
>>> I recently gathered some performance data when running Windows Server
>>> 2008 VMs, and I wanted to share it here.  There are 12 Windows
>>> Server2008 64-bit VMs (1 vcpu, 2 GB) running which handle the concurrent
>>> execution of 6 J2EE type benchmarks.  Each benchmark needs a App VM and
>>> a Database VM.  The benchmark clients inject a fixed rate of requests
>>> which yields X% CPU utilization on the host.  A different hypervisor was
>>> compared; KVM used about 60% more CPU cycles to complete the same amount
>>> of work.  Both had their hypervisor specific paravirt IO drivers in the
>>> VMs.
>>>
>>> Server is a 2 socket Core/i7, SMT off, with 72 GB memory
>>>
>>>        
>> Did you use large pages?
>>      
> Yes.
>    

The stats show 'largepage = 12'.  Something's wrong.  There's a commit 
(7736d680) that's supposed to fix largepage support for kvm-87, maybe 
it's incomplete.

>>> I/O on the host was not what I would call very high:  outbound network
>>> averaged at 163 Mbit/s inbound was 8 Mbit/s, while disk read ops was
>>> 243/sec and write ops was 561/sec
>>>
>>>        
>> What was the disk bandwidth used?  Presumably, direct access to the
>> volume with cache=off?
>>      
> 2.4 MB/sec write, 0.6MB/sec read, cache=none
> The VMs' boot disks are IDE, but apps use their second disk which is
> virtio.
>    

Chickenfeed.

Do the network stats include interguest traffic?  I presume *all* of the 
traffic was interguest.

>> linux-aio should help reduce cpu usage.
>>      
> I assume this is in a newer version of Qemu?
>    

No, posted and awaiting merge.

>> Could it be that Windows uses the debug registers?  Maybe we're
>> incorrectly deciding to switch them.
>>      
> I was wondering about that.  I was thinking of just backing out the
> support for debugregs and see what happens.
>
> Did the up/down_read seem kind of high?  Are we doing a lock of locking?
>    

It is.  We do.  Marcelo made some threats to remove this lock.

-- 
error compiling committee.c: too many arguments to function