VMware Cloud Community
NSITPS
Contributor
Contributor

CPU ready times - ESX 4.0

Hi

Would you say a cpu ready time of 300ms is high enough to cause sluggish behavior in an SQL 2000 VM with 2vCPUs?

I have not checked the cpu ready time via esxtop as I believe this can not give you historical data?????

Thanks

Reply
0 Kudos
25 Replies
cfizz34
Contributor
Contributor

Any update on this?

Reply
0 Kudos
Rohail2004
Enthusiast
Enthusiast

After reading this question I have been having the same issue with my heavy SQL box. My physical box is 6 cores per socket and has 128GB ram, the host itself now running only 4 VM's. SQL guys ran the single threaded application and it worked fine, but they're going to run multithreaded apps some time this week and then I will know for sure if it is working fine or not, becuas last week my CPU ready time was jumping from 500ms to 1400ms, but after moving VM's off from that host the cpu ready time went down dramatically and now it is at from 50ms to 150ms.

Reply
0 Kudos
NSITPS
Contributor
Contributor

Reconfiguring NUMA etc still did not resolve my issue - I am now looking to build an SQL VM from scratch and upgrade in the process to x64....

Reply
0 Kudos
babyg_wc
Enthusiast
Enthusiast

I have experienced the extact same issue... I still have a SR with VMware.

Here are a few things Ive learnt

BUG 1

ESX scheduler less than optimal at distributing VM's evenly across all available physical cores. EG the first numa nodes get heavily favoured, with the majority of VM's being placed in the first numa nodes (really obvious when you have a 8 socket box (dl785), and even 4 socket boxes(dl585).

WORKAROUND 1

change the numa round robining defaults by issuing the following command "esxcfg-advcfg -s 0"

BUG 2

4/5 VCPU boxes seem to have higher ready time than 6 VCPU boxes.

WORKAROUND 2

VMWARE engineering team said there are scheduling restrictions for 4 CPU VM's on 6 Core NUMA nodes, engineering recommends not to configure vcpu's for a VM between N/2 and N vcpu's where N is the number of cores in each NUMA nodes.

I think BUG 2, is actually a side affect of BUG 1. What in fact Is happening was that the 6 vcpu machines were getting their OWN numa node (not because they were 6 vcpu, but because we had given our 6vcpu VMS so much RAM) and therefore the VM’s with 25+gb of RAM assigned ended up a NUMA node to itself because of RAM and not because its a 6vcpu (hence low CPU ready time). I don’t know if I agree with WORKAROUND 2.

Heres what you can do.

Implement workaround 1 (which seems to have helped my enviroment alot)

Other things I have toyed with

Disable NUMA (in the BIOS)

REMOVE RAM from your ESX hosts (thus forcing ESX to use the other NUMA nodes because it will run out of RAM in each node quicker)

Add RAM to all your VM's (same thing as above)

Reply
0 Kudos
NSITPS
Contributor
Contributor

What exactly does this command do?

esxcfg-advcfg -s 0

Thanks

Reply
0 Kudos
staticRavi
Enthusiast
Enthusiast

Thank you, its very useful.

Cheers!

Reply
0 Kudos