WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: Distro kernel and 'virtualization server' vs. 'server that sometimes

To: Luke S Crawford <lsc@xxxxxxxxx>
Subject: Re: Distro kernel and 'virtualization server' vs. 'server that sometimes runs virtual instances' rant (was: Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops))
From: Tim Post <echo@xxxxxxxxxxxx>
Date: Fri, 29 May 2009 16:31:22 +0800
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 29 May 2009 01:32:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1243558839.5469.38.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <e5322423-6944-432f-911e-2f5beb18eaee@default> <m3r5y94epv.fsf@xxxxxxxxxxxxxxxxxx> <1243517950.5849.151.camel@xxxxxxxxxxxxxxxxxxxxx> <m3bppc3m09.fsf@xxxxxxxxxxxxxxxxxx> <1243558839.5469.38.camel@xxxxxxxxxxxxxxxxxxxxx>
Reply-to: echo@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2009-05-29 at 09:00 +0800, Tim Post wrote:
> Right now, what we're doing is not quite overcommitment, its more like
> accounting. By placing the output of sysinfo() and more (bits
> of /proc/meminfo) on Xenbus, its easy to get a bird's eye view of what
> domains are under or over utilizing their given RAM. If a domain has
> 1GB, yet its kernel is consistently committing only 384MB (actual size),
> there's a good chance that the guest would do just as well with 512MB,
> depending on its buffer use. The reverse is also true. Its looking at
> the whole VM big picture, including buffers, swap, etc.

Sorry, forgot to mention, average (aggregate) IOWAIT is also a key
factor. Users can do odd things like bypass buffers with relational
databases. So, when we see the kernel overselling, next to nill buffers
and a very high aggregate average IOWAIT across all vcpus, we have a
pretty good idea of what's going on.

Xenbus/Xenstore exists, the combined size of these vitals are small ..
until admin friendly introspection surfaces, its really the best way to
put any given host under a stereo microscope.

The problem is differentiating disk I/O from network I/O.

Cheers,
--Tim



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>