CPU ready values

[Subatomic]

Hello All,

I was wondering what typical values for CPU ready should be for guests running under ESX server.

On a ESX 3.0.1 host we observe single digit, a low double digit values for Windows 2003 guest OSes. For Linux the CPU ready figures are into the hundreds of milliseconds.

Can my observations be simply explained by Linux accessing the hardware more "agressively" or is this possibly an issue?

Thanks

SA

[ponpalani2001]

Hi,

% CPU Ready state value should be less than 5%.

Thanks

[Subatomic]

Hi Ponpalani!

CPU ready is measured in milliseconds. Do you mean 5ms?

Is this the same for any guest OS?

[mcowger]

If you look at ESX top on the SC, its measured in %, if you look at it on the performance charts, its in milliseconds.

I would say anything over 200 ish ms is high.

--Matt

[RParker]

Just a guess, but your Windows Os are 1 CPU and your Linux Guests are 2 or 4 vCPU right?

That's why making additional CPU in a VM isn't a good idea, they aren't being used. This isn't a VM thing, this is the ability of VM to see this information outside the OS. Most machines even though many have 2 or 4 CPU doesn't mean the software is making good use of those processors, which is why you shouldn't give CPU's just for the sake of adding CPU.

[Subatomic]

Thanks for your reply.

Both Windows guests are single CPU. Our Linux guest are are mix of single and dual vcpu. (Our applications do support multi-threading and on the dual vcpus, the smp kernel is installed.

Cheers

SA

[RParker]

Well the ready time isn't bad per se, it's just an indication that the processors are ready to do something, but they have nothing to do. You will see high ready times in multi CPU environments.. One processor is typically always busy, even when it's idle. There are always tasks to perform. but 2 of them, makes things a bit more difficult because 1 processor even in a perfect Multi threaded world isn't going to be busy, simply because the machine has to be idle sometime.

So READY times are just an indication of this. Your processor(s) are just in ready state, but they aren't doing any work. It's like hiring city workers, only one of them does the work, the rest just soak up the air

[mcowger · Accepted solution]

Thats not at all what ready time means. Not even close.

CPU Ready time, in ESX land, is the amount of time a VM was waiting to be serviced by a phsyical processor core. So, if you have a VM that wanted to do stuff, but had to wait 200ms to be scheduled onto a processor, it has 200ms of ready time. Its a sign of scheduling contention.

The rub comes when you have multi core VMs - regardless of the amount of CPU needed by the VM (lets say its a 4 core VM, and only needs 1 core worth of power), it needs to schedule onto 4 cores (because it is a 4 core VM). While it is scheduled onto 4 processor cores, nothign else can use them, even though that VM isn't really using all that they can do. So, when you have a lot of low usage VM's with 2 or 4 cores, you end up with problems scheduling them onto cores, and not so much the speed of the CPUs themselves. Hence, the need to watch your CPU Ready times.

So ready times ARE always bad, but its a matter of how bad. Waiting 1ms to be scheduled onto the physical CPUs isn't very long and so isn't very bad. Waiting 800ms to be scheduled is a long ass time, and ISvery bad.

--Matt

[RParker]

CPU Ready time, in ESX land, is the amount of time a VM was waiting to be serviced by a phsyical processor core. So, if you have a VM that wanted to do stuff, but had to wait 200ms to be scheduled onto a processor, it has 200ms of ready time. Its a sign of scheduling contention.

To achieve best performance in a consolidated environment, you must consider ready time -

the time a virtual machine must wait in a ready-to-run state before it can be scheduled on a

CPU. This paper provides information to help you understand the factors that influence ready

time on an ESX Server 3.0 system

*

Processor Utilization versus Ready Time

*

The first test (Figure 1) shows how ready time changes with utilization. Six virtual machines were

running on the test server. All of them were pinned to a single CPU. Load was generated by the

CPU burner program run with a setting of approximately 15 percent, so that if it were the only

thing running, the virtual machine would consume close to 15 percent of the capacity of a

single CPU. Idle virtual machines also consumed some CPU capacity to perform guest operating

system maintenance tasks.

[mcowger]

Stop, think, read:

http://www.vmware.com/pdf/esx3_ready_time.pdf

--Matt

[RParker]

yes sire!

I updated my response, sir!

[JonRoderick]

Thanks Matt - a bit of clarity is all we need sometimes - too many people spouting off in here on occasion. Nice one.