SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?


To: Saturn V who wrote (257509)12/22/2008 3:43:15 PM
From: rudedogRespond to of 275872
 
Saturn V -
Virtualization does allow multiple operating systems, but the most common use is multiple copies of a single OS to consolidate a number of servers into one. Let's say you have a number of departments who have implemented SQL based systems. Each has a SQL server running somewhere, with average utilization of 15% but peak usage of 70%. With a little analysis, you have determined that the peak loads don't usually occur at the same time. Administering those multiple servers is a headache for IT, and the low average usage means you are using power (and floor space) inefficiently.

By combining those onto a single larger server, you get the benefits of a larger peak capability for all of the instances, and improve average utilization (usual target is 70%). The reason to run each of those in its own VM include the ability to tune for each workload, the ability to upgrade and restart an instance without affecting others, and the ability to set security and other administrative domains appropriately for each set of users.

For a variety of reasons, the 'sweet spot' from an administrative, reliability and power perspective is 8 to 16 VMs per server.

With previous generation AMD designs, we were able to run 16 VMs with a performance penalty of only about 10% for the virtualization. With Shanghai, that looks like it may be down to 5%. This allows power savings of 50% or so in typical consolidations.

Current Xeon systems can do some types of virtualization pretty well, but they had a lot of overhead in database work and other I/O intensive loads - performance per instance on 16 VMs was less than half of the 4 VM performance. Testing on Nehalem shows a big improvement, but we still show more than 20% penalty for 16 VMs versus 4 VMs.

The important criteria are the ability of the server to manage power with varying loads in the upper range of utilzation, and the ability to 'world switch' (go from one VM to another) with minimum lag or overhead. Absolute processor performance is less important, since the server is sized to match the workloads being consolidated rather than to achieve peak performance in any one instance. Since the target average utilization is 70% or so, power management of low utilization states is not important.

For other workloads, Nehalem has some nice features, including the ability to drop cores and use the overall thermal capacity to accelerate the remaining cores, and the ability to turn off cores completely with little penalty. Those capabilities are useful for reducing average power in systems where the average load is low, but high burst performance is needed.