Re: [Xen-devel] Re: [Xen-users] Max. PV and HVM Guests

["Mr. Teo En Ming (Zhang Enming)" <space.time.universe@xxxxxxxxx>]

Hi,

This is the new video demo of my Rocks HPC compute cluster after I have set dom0_mem=1024M for my Xen hypervisor.

I started all 5 nodes at one go without crashing and without sluggishness.

Please watch the video at http://www.youtube.com/watch?v=vWHIImVBr4o

It's only 6 minutes.

Previous video demo shows that I can only start 3 nodes with-out setting dom0_mem for the Xen hypervisor. If I try to start the 4th node, dom0 will freeze.

This is proof that setting dom0_mem really works and improves overall system performance.

-- 
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics) BEng(Hons)(Mechanical Engineering)
Alma Maters:
(1) Singapore Polytechnic
(2) National University of Singapore
My Primary Blog: http://teo-en-ming-aka-zhang-enming.blogspot.com
My Secondary Blog: http://enmingteo.wordpress.com
My Youtube videos: http://www.youtube.com/user/enmingteo
Email: space.time.universe@xxxxxxxxx
Mobile Phone (Starhub Prepaid): +65-8369-2618
Street: Bedok Reservoir Road
Country: Singapore

On Mon, Nov 9, 2009 at 11:29 PM, Nick Couchman <Nick.Couchman@xxxxxxxxx> wrote:

Thanks for the information!  Looks like I'll be adjusting some boot-time options on my Xen servers.  I have seen a couple of issues now and then with either migration or starting a domU, but it happens once every few months at the most, and usually I blame the migration issues on a fault network connection or something like that.  I'll have to try out limiting my dom0s to 1 or 2 GB of RAM and see if those issues go away!

Thanks!
-Nick

>>> On 2009/11/09 at 08:18, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 09/11/2009 15:06, "Nick Couchman" <Nick.Couchman@xxxxxxxxx> wrote:
>
>> Really?  I thought current conventional wisdom was to allow Xen to
>> self-manage memory in both dom0 and domUs, and not to manually adjust
>> this?  I run several Xen systems with anywhere from 8 to 24 GB of RAM
>> and 20 to 30 domUs on some of these systems and have *never* specified
>> the dom0 memory at boot time - the Xen ballooning has always functioned
>> perfectly fine, and never crashed my dom0.  Furthermore, while I'm not
>> Linux developer and so not familiar with how Linux calculates buffering
>> and caching, I do know that my Linux systems dynamically manage buffers
>> and caches, and when memory is reduced or some application requires a
>> larger amount of physical memory, Linux reduces the amount of data in
>> buffers and caches.
>
> If you are not using dom0 as a general-purpose OS then it is a very good
> idea to specify dom0's memory allowance via dom0_mem= and disable
> auto-ballooning in the xend-config.sxp. There are a few reasons for this,
> the most compelling being that Linux will have a metadata overhead for
> tracking memory usage, and this will be a fraction (say a percent or so) of
> its initial memory allocation. So, that overhead may be just 2% of 24GB,
> say, but then if dom0 gets ballooned down to 1GB it'll be more like 50%!
> Clearly you are limited in how far you can balloon down without risking the
> OOM killer in dom0.
>
> Apart from that, the auto-ballooner has been implicated in various quirky
> bugs in the past -- failing domain creations and migrations for the most
> part -- so it's nice to turn it off if you can, as that's one less thing to
> fail. And if dom0 is single-purpose you should be able to work out how much
> memory it needs for that purpose and statically allocate it. Using
> auto-ballooner is actually perverse in this scenario, in that dom0 gets the
> least memory when it needs it the most (because it presumably has highest
> load when servicing the most VMs, but in that case auto-ballooner has stolen
> lots of memory from dom0).
>
> My 2c!
>
>  -- Keir

--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

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