Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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: wbmw who wrote (257472)	12/20/2008 9:29:33 PM
From: rudedog	Respond to of 275872

wbmw - discussions over a couple of beers are always anecdotal... but my own experience, which is around optimizing database performance in a virtual environment, is not. I have worked in this area for a long time, and I can give you specifics for some of the cases you mention. Performance tuning of a database engine in a virtual environment is challenging, because we like to have control down to the metal, and obviously can't do that when virtualized. Average performance of the total load is important, but response time for an individual virtual machine is also key - after all, that's what a user sees. I/O performance impacts both areas. Back in 2006, I was knocked out by the base performance and power envelope of woodcrest, but a lot of that edge was used up by I/O overhead in database work. Between shadow paging and cache flush, virtual DB engines used at least twice the resource of bare metal, worse with more VMs. Opteron rev-f was the first to feature AMD-v. While world switch overhead was still too high, the performance was good enough to maintain response for multiple instances, with a hardware upsize. NPT improved that. With large numbers of VMs, cache flush was still an issue, but memory overhead was within 10% of bare metal. With Shanghai, that is down to around 5%. Intel's EPT is a big step in the right direction, but at least in our current tests, not as efficient. The Nehalem cache architecture improves VM efficiency, but at the expense of raw DB performance. I can't discuss Nehalem numbers in any detail... Intel has made a lot of progress with this architecture, but has work to do.