2,187
edits
Difference between revisions of "Installation (ESX)"
Jump to navigation
Jump to search
→Poor performance: Expanded
(→Poor throughput: Added indicative table) |
(→Poor performance: Expanded) |
||
| Line 551: | Line 551: | ||
== CPU == | == CPU == | ||
=== Poor performance === | === Poor performance === | ||
Basic things to check are that the VM or the ESX its hosted on aren't saturating their available CPU. However if VM's are performing sluggishly and/or are slow to start, depsite not appearing to be excessively using CPU time futehr investigation is required... | |||
* Use <code>esxtop</code> on the ESX service console. Look at Ready Time (%RDY), which is how long a VM is waiting for CPUs to become available. | |||
* Alternatively look for CPU Ready in performance charts. Here its measured in msec, over the normal 20 sec sampling interval. | |||
CPU Ready can creep up if the the system is pushed, or if the VM has multiple CPUs (as it needs multiple physical CPUs to become available at the same time, aka CPU Co-Scheduling). Multiple CPU's are especially a problem in environments where there are large number of SMP VM's. | |||
{|cellpadding="2" cellspacing="0" border="1" | |||
|- | |||
! % CPU Ready !! MSec CPU Ready !! Performance | |||
|- | |||
| < 1..25 % || < 500 msec || Excellent | |||
|- | |||
| < 2.5 % || < 500 msec || Good | |||
|- | |||
| < 5 % || < 1000 msec || Acceptible | |||
|- | |||
| < 10 % || < 2000 msec || Poor | |||
|- | |||
| > 15 % || > 3000 msec || Bad | |||
|} | |||
CPU Co-Scheduling is more relaxed in ESX4 than ESX3, due to changes in the way that differences to seperate vCPU's progress within a single VM are calculated. Meaning that the derogatory affect on pCPU effciency of having multiple CPU VM is reduced (but ''not'' eliminated). See http://www.vmware.com/files/pdf/perf-vsphere-cpu_scheduler.pdf for further info. | |||
== Storage == | == Storage == | ||