• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

VMware - Cores Per Socket

bigdogchris

bigdogchris

Fully [H]
Joined
Feb 19, 2008
Messages
19,077
I'm a VMware novice, but I want to do things right.

I've been doing some reading and it seems that VMware suggest, as a best practice, you assign a socket for each core you want the CPU to have in order to improve CPU Ready time because VMware can better assign the cores to NUMA nodes.

For example, I want a server to have 4 vcores. Rather than assigning 1 socket and 4 vcores, they suggest assigning 4 sockets each with 1 vcore. In an event where the guest OS has limited socket compatibility, only then assign more vcores per socket.

Has anyone tested this and found that it's better to assign more sockets rather than more vcores?
 
Last edited:
We all need 24 core + two socket servers in our garage then we wouldn't need to worry about this!

Hurry up future + Moore's Law!!!

Thanks for the link Dytralis, good write up there.

Nick
 
Good info, I didn't know that. But does this still apply to single socket hosts?
 
Yes. The scheduler tends to work the same regardless of the physical sockets it has to work with. :) It knows what's going on.
 
I'm going to change my VM settings right now then :eek:, thanks!
 
I have a question related to this. The article addresses numa and memory size it seems. I get cpu wait measurements in the range of 150,000 to 300,000ms on each host. I had found some semi-random research that said this metric should be much lower and using a single socket with multiple cores would help. Esx needed to schedule some tasks actually on a physical socket and having a 2 socket/8 physical core host would work better using 1 socket/x core vm's. The Co-stop is usually 0 and the ready is rarely over 50ms - often 20ms or less.

None of my vm's exceed 8 cores, all hosts are 2s/8c 128GB hosts. No vm is over 64BG ram and most are less than 32GB ram. The hosts run from 8-16vm's each. Generally there are 1 6-8c vm, 2-3 4c vm, the rest are 1-2c. Is the many sockets/few cores theory still my best bet? The vm's seemed to slow down compared to the old hosts after migration (old were 4s/4c). The few I changed to 1s/xc brought the wait down and appear to be more responsive from the end user point of view.

I don't want to continue changing them to 1s/xc if they should be xs/1c. It seams like I'm not in a numa situation, and so the article above may not apply. If I'm in a physical socket scheduling situation, then perhaps my workload is different?

Running 5.5u1.

Thanks, this seems related, and for future searching better to have the answer in this thread than a different one.
 
Are you running any sort of CPU Power MGMT Feature in the BIOS?
 
Pm74 said:
I have a question related to this. The article addresses numa and memory size it seems. I get cpu wait measurements in the range of 150,000 to 300,000ms on each host. I had found some semi-random research that said this metric should be much lower and using a single socket with multiple cores would help.
Click to expand...

Before we get ahead of ourselves let's get to the bottom of what cpu wait actually measures. %WAIT includes %IDLE, so if %WAIT is high that really doesn't mean anything, or it could mean something.

If %WAIT is mostly composed of %IDLE then nothing is wrong (%VMWAIT is a better measure since it doesn't include %IDLE). If %WAIT is truly a measure of the kernel waiting for resources then it could just as well be that your disk IO or network IO is clogged up and not available.

Here are a couple KB articles to help you figure this out:

Determining if multiple virtual CPUs are causing performance issues (1005362)

Troubleshooting a virtual machine that has stopped responding: VMM and Guest CPU usage comparison (1017926) (for a decent explanation of Wait)
 
Hmm, good stuff here. I didn't know about the vmwait vs wait percentages. I wonder if this socket to core relationship is the same with other hypervisors or is it a Linux (that VMware is based on) only thing?
 
You must log in or register to reply here.
Back
Top