| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] Xen Performance
Luke,
Apologies for my first incomplete reply.
Here's more context. The VMs weren't page scanning. They did show non-
trivial %steal (where non-trivial is > 1%)
These VMs are commercially hosted on five quad core hosts with approx
14 VMs per host and just under 1GB RAM per VM. Thats not a lot of
memory, but then the workload of one nginx and three mongrels per VM
is comfortably under 512MB of RSS.
I have heard numerous mentions of similar behavior from users of other
utility platforms . There is a recent (Feb 2009) report by IBM that
also describes this behavior once #domU exceeds six.
My point, however, is that Xen performance is not well understood in
general, and there are situations where virtualization doesnt perform
well.
Peter
On May 30, 2009, at 4:11 PM, Peter Booth wrote:
In this example, swapping/page scanning was not an issue.
On May 30, 2009, at 4:05 PM, Luke S Crawford wrote:
Peter Booth <peter_booth@xxxxxxx> writes:
One real world example:
native Linux: page response times of ( 400ms/150ms)
[mean/standard deviation]
Xen VM: page response times of ( 700ms/3.5s)
[mean/standard deviation]
In this scenario, we have mean response times that are almost 100%
worse, and the 90th percentile is 1000% worse.
Yeah, but if your average native times are 400ms, you are very likely
already hitting swap and experiencing what I would call unacceptable
performance. It's no suprise that swap on a shared device is going
to be
slower than a non-shared swap.
Hm. unless that xen vm is on a xen box doing nothing else, in
which case
the results whould suprise me quite a lot (unless you were using
HVM mode
or had less ram in the xen vm than in the native box)
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home