Unsolved
This post is more than 5 years old
40 Posts
0
1354
BCA2320 follow up question: PreferHT vmx setting
First, let me say I really enjoyed most of the BCA2320 presentation at VMworld. I've seen Jeff present numerous times and always found him entertaining and educational. This was (I think) my first time seeing Sam present and it was also excellent.
After seing the presentation and then reviewing it this past weekend, I've got a number of follow up questions.
Second one: On Slide 54, one of the best practices is setting PreferHT=TRUE in the .vmx file and this is then explained in further detail in slides 56 and 57.
I'm confused why this would be needed and if it's a corner case.
I thought that in vSphere 4 and even more so with vSphere 5 (with vNUMA) ESX tries to schedule cores to take advantage of NUMA. So wouldn't threads/cores on the same socket CPU be utilized even without the PreferHT command?
On a more general note, what performance improvement have you seen with vNUMA in vSphere 5?
dba_hba
63 Posts
1
October 11th, 2011 06:00
See VMware KB Article: 2003582 : Configure virtual machines to use hyper-threading with NUMA
Covers both ESX(i) 4.1 and 5.0
DarrylBSmith
28 Posts
1
October 11th, 2011 12:00
vShpere is NUMA aware and will try to schedule processes to work with on the socket holding the memory the process needs. The problem with databases is that the memory you need is not known until after the process starts up and the database has determined the optimizer plan that your process will use. Generally this is not an issue as you will utilize the buffer cache that your process just populated. Given that vShpere is actually providing a virtual CPU to the OS, the next instruction that the process issues, it will likely move to a new processor/socket.
Using the preferHT=TRUE forces the vCPUs to the fewest number of physical sockets and increases the likelyhood of the process staying in the same socket. We have seen about a 5% transaction latency reduction using this option. Be cautioned, if your database workload is pushing your vCPUs beyond 50% utilization, this setting is not for you, as your VM would benefit from using the full core, over the hyperthreaded core.