Re: [Xen-users] Xen Performance

Peter Booth
Mon, 01 Jun 2009 02:37:37 -0000

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@mac.com> 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@lists.xensource.com
> http://lists.xensource.com/xen-users