-----Original Message----- From: David Boyes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 8:17 AM To: [EMAIL PROTECTED] Subject: Re: Recommended VM Linux Configuration sizing?
> Does anyone have any references/pointers for the recommended sizing for VM > Linux images (region, cpus, etc.)? As Rich already said, it depends a lot on what you intend to do with the images. Keep in mind also that there are two sizing problems at hand: the base VM instance, and the individual Linux instance. Both need sizing in tandem for good performance. For the base VM instance, you need a goodly amount of central storage *and* some amount of XSTORE to get best performance (the default way the paging algorithms are set up makes XSTORE attractive, as page migration is a lot less expensive than a full page in/page out to disk). Having a chunk of XSTORE that's at least 10% the size of real storage can make a significant difference in how VM behaves -- see Barton Robinson's voluminous discussions on this topic in his newsletter and past postings to the VMESA-L list. For the Linux guests, smaller is better. Remember that to VM, these things look like great big opaque blobs of work that want to come and go in their entirity. Given the behavior discussed here wrt to how Linux uses storage for disk buffers, the smaller the virtual machine, the more likely it is that VM will schedule it frequently (less work to do so). Linux then needs to page somewhere -- VDISK is the best answer in most cases, as it takes advantage of the VM storage management by being pagable at 1st level (you don't allocate xstore in this scenario until you use it and xstore can be shared between lots of guests if VM controls it's usage (which is the disadvantage with using the Linux xstore drivers, as they dedicate the storage to one guest)). The rule of thumb I use for VM sizing is start with at least 1G real, 256M XSTORE, and at least 6-8 full-pack paging areas (pref on as many different spindles and controllers as possible). IMHO, that's an absolute minimum to support a "toy" environment. Desirable minimum for something that's intended to support real workloads is about 4G real and 1G XSTORE with 16-20 paging areas; more in both RAM categories is obviously better, # of paging areas will vary depending on your hardware setup (ie if your hardware supports PAV or "mini-volumes", you may be better off doing things a bit differently by having lots of smaller paging areas to maximize the number of paging I/Os that can be in flight at any one time). For Linux, we have to get more granular -- starting rule is for images supporting open source infrastructure tools only, I start at a virtual storage of 18M and a 500M VDISK for Linux paging and go up as needed. For development systems, start at 64M and go up. For Websphere or similar applications, start at 256M and start allocating paging packs now...8-). If you're moving applications from another environment, your best bet is to get some performance data on what the app is doing now, and start with about 25-50% of the current resources as a initial stake in the ground. It's fairly easy to adjust during testing, so you can tinker with the values and get a good matchup. Someone else commented (rightly so), that going one-to-one for resources when moving an application into the environment is likely to be a recipe for poor performance. This is a *very* important observation. In many cases, cutting the virtual machine size in half can double or triple the performance of a system in this environment. It's counter-intuituve as heck, but the tradoffs for tuning this environment are completely different, and if you try to apply "similar" sizing, you'll lose on performance. -- db
