Some number of CPU instructions are always emulated when running in a VM, anything that would affect real processor state with respect to hardware or affecting the integrity of other tasks. MMU functions are virtualized/shadowed and require an extra level of mediation. Emulation of privileged operations is done usually with a combination of dynamic code rewriting and traps up to the hypervisor. This has a measurable performance impact.
Furthermore, device I/O is virtualized. The best you can do here is run paravirtualized Linux guests on Xen boxes. This had the lowest measured performance impact of the available options when I last looked (about a year ago), but it still costs you -- longer instruction paths, possibly more data copies. Virtualization of I/O is the bit that I'd expect would have the largest impact on HDFS and HBase function. On Xen you have the option of running HDFS and HBase in dom0 at least, exporting HDFS as a cluster filesystem or a global Bigtable service to apps or whatever running in domUs. No point to do that for a dedicated HBase storage cluster or HBase + mapreduce platform. - Andy --- On Wed, 8/19/09, llpind <[email protected]> wrote: From: llpind <[email protected]> Subject: Re: HBase in a real world application To: [email protected] Date: Wednesday, August 19, 2009, 2:33 PM Ryan Rawson wrote: > > Absolutely not. VM = low performance, no good. > If you have a box with a lot of RAM, and you split the box into VMs allocating enough RAM for each. Lets say you have a box with 32GB of RAM, and you put two VMs on it allocating 16GB each... will that be slow too? please explain why you think VM = low performance. thanks -- View this message in context: http://www.nabble.com/HBase-in-a-real-world-application-tp24920888p25052355.html Sent from the HBase User mailing list archive at Nabble.com.
