nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Poor Performance on Guests. CPU Ready Values 700ms

lon21

Hi,

Was hoping someone should advise me, I have one ESXi 4.1 Update 1 host which has:

1 x SBS 2011 2vCPU
2 x Ms Svr 2K8 R2 1vCPU each
1x Ms Svr 2K3 SQL 4vCPU
1 X Linux Svr 1vCPU

The host has in total 6 Cores per socket and 12 logically processors with 1 socket and hyper-threading enabled.

The issue is some of my VM are experience slowness on performance and have a CPU ready value of 700ms over 20seconds.

How do you know how many vCPU to assign your guests? and which values should I be looking at in the performance graphs?

Thanks

Find more posts tagged with

SAVE $250 on Your Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View Boot Camps

Comments

Tackle

Going to take a shot in the dark here -

How are your disks set up? How many physical disks?

lon21

Tackle wrote: »

Going to take a shot in the dark here -

How are your disks set up? How many physical disks?

All disks are local in RAID 5

QHalo

How many and what speeds are they?

kalebksp

Is it only a particular VM that is showing high ready times? You have 9 allocated vCPUs and 6 physical cores, this isn't necessarily a problem but it can be. For example, when a VM that has 4 vCPUs allocated requests processor time there must be 4 physical cores available, if only three of the six cores are available it must wait until a forth frees up. It's counter intuitive but you may want to decrease the CPUs on your SQL server and see if there is a change.

It's also possible that you simple don't have enough cores for the work load, but I would be surprised based on the number of VM.

jmritenour

How many vCPUs do you have assigned? High CPU ready means that vCPUs are in a wait state for other CPUs to sync up. Generally speaking, start with less CPUs, and scale up as you start to see consistently high CPU usage.

Daniel333

Is this production? Or just a lab?

That said, CPU, RAM and disk space are cheap. Provision first at the Disk-IO level. Slow disk can artificially make other metrics look worse. Please post your disk Queues , disk latency and kernel latency during the problematic times?

Extremely slow Virtual Machines on HP Smart Array P410 | PepperCrew

I have had to service SOHO office clients with this kind of setup... you might just want backup,toss a RAID controller in there with a couple SSDs move the VMs over to ease the load.

Let us know how this works out?

edit: Doesn't sound like they have vCenter, but if you do snag a trial of Foglight for Vmware. Sets up pretty quick and can really be helpful in these situations.

jibbajabba

Kaleb is spot on imo. Each vCPU represents a physical core and if you assign 9 out of 6 possible then you might really run into scheduling issues.

You will notice sometimes that assigning more vCPUs is counterproductive, especially in systems with multiple sockets. But since you got only one, reduce one vCPU and see how it works out.

scott28tt

kalebksp wrote: »

For example, when a VM that has 4 vCPUs allocated requests processor time there must be 4 physical cores available, if only three of the six cores are available it must wait until a forth frees up.

That was true back in ESX 2.x days, but "relaxed co-scheduling" was introduced in ESX 3 - see this 4.1 document: http://www.vmware.com/files/pdf/techpaper/VMW_vSphere41_cpu_schedule_ESX.pdf

meadIT

Agree with Scott and Kaleb in a way. Even though the hyperthreaded cores can be used to schedule, no two vCPU's from the same VM can use the same core. For example, let's use a 6 core CPU that's hyperthreaded. Let's label them 1a, 1b, 2a, 2b, etc. When the 4 vCPU VM is waiting for it's turn, it can't use core 1a and 1b or 2a and 2b at the same time. It has to have 4 cores available out of the 6 in the pCPU.