Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have severe performance issues on an ESX client, but from where I am I cannot directly view the server configuration, yet I want to find out whether they set it up correctly.

Running CPU-Z shows me two processors with each one core, while I have Yorkfield processors and hence expect four cores to show up. Is this the way virtual CPUs show in CPU-Z?

How do I determine, from the client, how ESX has it configured? I understand that ESX can have HT enabled. My system uses SMP heavily, so it should benefit. From what I gather, the ESX is configured for two vCPUs. Is my reading of the data correct?

EDIT: there are basically two causes for the choking CPU. First, the application(s) aren't perfect, we work on that. Second, we don't have enough CPU power. The image comes from a similar native machine and is now on a virtual machine. Performance should be similar, but isn't. Normally we could deal with 500+ sessions per native system. On this system, choking starts around 280 sessions. I know it's a bit short-sighted to blame the CPU config, but after two days intensive monitoring and profiling it all really starts to point in that direction (memory, disk IO, db connection and network are performing fine).

share|improve this question
More information requested, as severe performance problems should be via the disk, io, ethernet or memory, but generally not the CPU. It's a rare box that CPU bound before disk or IO bound. –  Stephen Thompson Nov 30 '09 at 9:26
@Stephen: Q. edited with answers to your questions. –  Abel Nov 30 '09 at 10:10
add comment

2 Answers

up vote 5 down vote accepted

If you are getting 280 sessions on a VM with two vCPU's and 500+ on the same physical box using all 4 cores then you are coming close to the bare metal performance with that VM config. Reconfigure the VM to use 4 vCPU's and performance should come close provided nothing else on the ESX host is consuming significant resources. However for a 4-vCPU VM running on a 4 Core single CPU host the Hypervisor overhead is going to take up some fraction of the overall capacity and that might be quite significant. The ESX hypervisor will only schedule your VM when it can schedule all 4 vCPU's concurrently so anything else running (Hypervisor, Service Console, other VM's) will cause all 4 vCPU's to stall on a setup like this. On this setup if it is possible for you to run your application across two dual vCPU VM's you may find that it scales better even with the added overhead of running an additional Guest OS, the scheduling problem will be a lot easier for the Hypervisor to deal with as you will only stall two cores when other tasks need to be given access to CPU resources.

Each VMware vCPU equates to a single core on a multi-core system, that's how VMware carves up processor resources. The Yorkfield is a Core2 Quad and definitely does not support HT - it has 4 physical cores with no HT cores.

CPU-Z running in a VM will only report the number of vCPU's that are presented to the VM, although it will identify the underlying CPU correctly. Depending on the ESX version and how the VM is configured it can present those as a dual core single processor or as two separate processors but that has no impact on perfromance, it is simply a presentation choice that is used to facilitate certain licensing situations.

Edited to provide more accurate and current data:

The strict co-scheduling point made above was a bit of a red herring. ESX has been using a relaxed co-scheduling mechanism since ESX V3 that allows some leeway (clock drift between vCPU cores) and that has improved with subsequent versions.

It is still generally true that a VM that presents as many vCPU's as there are physical cores will have more trouble being scheduled under load than VM's with fewer vCPU's but it is not as dramatic as it comes across in my original answer. A very detailed explanation of how it actually works can be found in this VMware white paper.

share|improve this answer
Now that's an answer! +10 if I could, I was yearning for info like this. Thanks! One detail I don't really get. If I see 2 physical CPU's with CPU-Z and Yorkfield has 4 cores, this could be an excellent configuration if other VM's don't take up > 2 other cores? After posting this, I found out that the VM host has at least 3, possibly more, VM's, of which one is a heavy duty DB server, also on 2 CPU's. Seems that the (bad) ESX configuration is playing us parts here and that "busy time" can mean that others are slicing off of our CPU time, making ours look "busy". –  Abel Dec 5 '09 at 14:31
add comment

When the system is CPU bound, how many processes are taking CPU? What you're describing implies there's only one runnable process.

Yorkfield CPUs don't support HT, so you can rule that out.

share|improve this answer
Thanks for your answer, but where did you find that Yorkfield does not support HT? These are Intel Xeon processors (sorry I didn't mention Xeon in the q.) and it is my understanding that all current Xeon processors support hyperthreading. Is this not correct? There's one running process, IIS6 + ASP.NET 3.5, which runs with about 40-80 threads in my situation. –  Abel Nov 30 '09 at 10:09
While Netburst (aka Pentium 4) based Xeons had HyperThreading, Core-based Xeons didn't get HyperThreading until the Nehalem-based Gainestown/Bloomfield chips hit the market this past March. Your Yorkfield isn't "current" in the sense that they mostly came out between Summer 08 and the beginning of 09. –  phoebus Nov 30 '09 at 10:54
I'm not certain about its currency, the system seems to have been setup in May 09. CPU-Z reports Intel Xeon. Shouldn't it report Intel Core if different? How can I determine one or the other (HT or Xeon or both)? –  Abel Nov 30 '09 at 11:23
en.wikipedia.org/wiki/Yorkfield_(microprocessor) lists the specs of those CPUs. It'd probably help you to know how busy the ESX host is, and that's inherently invisible from inside the VM. It's quite possible for a busy ESX host to only be able to schedule a small fraction of a guests CPU time, say if it could only give it 75% use, you'd only see 75 % performance. I don't see how an ESX configuration choice could generate the process switching between CPUs effect you're seeing, that's an issue within the guest, and should be the same as running on a real machine. –  xenny Nov 30 '09 at 11:50
I read that article prior to posting (SF makes it a wrong link though). It is my understanding that this processor should list with CPU-Z as four cores, HT or not (maybe eight with HT). But perhaps I'm wrong. Anyway, my question, how to determine the actual configuration, isn't answered, but perhaps it is indeed impossible. –  Abel Dec 1 '09 at 11:54
show 1 more comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.