VMware’s conservative guidance about overcommitting your pCPU:vCPU ratio for Monster virtual machines is simple – don’t do it.
Example:
If you have a quad socket, 8 core host, this means you have 32 cores, or 64 SMT threads, which vSphere sees as potential logical CPUs. The actual largest monster virtual machine we’d recommend you create is 32 vCPUs for that host.
Why is that?
It is assumed you’ve assigned all those vCPUs because not only are they required by the application, but also that they will be highly utilized.
SMT enables two threads to run simultaneously on a processors core, but since they still share the execution resources of a single core, it does not provide the same throughput as two independent processors cores.
So with that in mind, if you were to assign additional vCPUs, say increase the configuration from 32 vCPU to 64 vCPUs, you are now going to be sharing processor execution resources. This means that while you may see an increase in overall performance, the benefit of using Hyper-Threading SMT technology is measured typically somewhere between 10-15% – not double.
It is this misunderstanding that is often at the root of past performance issues and why this conservative guidance has been adopted. It makes for an easy rule of thumb.
Note: This does not mean you cannot oversubscribe the pCPUs on a host, like we’re all doing today with massive consolidation ratios. It is meant as guidance to not over subscribe a single Monster virtual machine. Incidentally, your consolidation ratios will typically drop when using Monster virtual machines, and that’s okay, as these configurations will be consuming many times the resources of your smaller workloads.
That said, there are times when this oversubscribed configuration can be beneficial.
Examples:
You want massive parallelism. Some applications (Ex: Mapreduce) would rather have access to more threads than a smaller count of faster threads.
Your application can use these additional threads and you want to squeeze every last cycle out of your host. I commonly refer to this as benchmarking 😉
Monster virtual machines should not be feared, but they do need to be created responsibly and with knowledge of the hosting infrastructure, to offer maximum performance and meet your businesses KPIs.
