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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
