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).
-
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.
Abel : 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.phoebus : 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.Abel : 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)?xenny : http://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.Abel : 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.xenny : It would list as four core, if you were on the hardware. ESX is exposing 2 cores to the VM, so a program running in the VM will only see 2 cores. Try and think of the hardware you're running on as what the VM is configured to have, not the actual physical hardware.From xenny -
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.
Abel : 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".From Helvick
0 comments:
Post a Comment