![]() If you are interested in measuring the vCPU overprovisioning from the point of view of the host, you can use the host’s cpu_avg metric to see if it’s too close to 1.0 (rather than 0.8, i.e. The background to understand this and details of how to do this can be found within this blog:> This is especially worth monitoring if you are overprovisioning. VM runstate_ metrics, these allow you to assess vCPU contention. Memory used as reported by the guest agent (KiB).įraction of time that all VCPUs are running.įraction of time that all VCPUs are runnable (i.e., waiting for CPUįraction of time that some VCPUs are running and some are runnableįraction of time that all VCPUs are blocked or offlineįraction of time that some VCPUs are running, and some are blockedįraction of time that some VCPUs are runnable and some are blocked Memory currently allocated to VM (Bytes).Enabled by default on a 3400MHz Intel system, P0 will be logged as 3401MHz, where the maximal non-turbo mode is P1 with 3400MHz. There is a convention of labelling turbo-mode with a frequency +1MHz above normal maximum frequency means that XenCenter does not reflect the true frequency of the turbo mode and as such users may interpret it that turbo mode is not occurring. P-state (P0) the highest mode is traditionally used to indicate if turbo is in use but you must be very careful if using XenCenter to note the convention that if turbo is in use, P0 will be turbo mode and P1 the highest non-turbo mode. Catia is one such application that has often been like this. Many CAD/3D applications can be highly single-threaded and benefit from using turbo mode. I wrote a guide to C/P-states a long time ago: I’m not sure whether the information is correct with respect to the XenServer commands to optimally configure a system but the monitor instructions should be correct. This needs to be changed in the BIOS to allow the hypervisor and hence app to use the full range of P/C-States. Many servers are shipped in power saving mode rather than for maximum performance. EnabledĬ-State and P-state information is particularly insightful in the context of bursty (CAD applications often are) applications where peak vs. Mean utilization of physical CPUs (fraction). Time CPU spent in P-state in milliseconds. Time CPU spent in C-state in miliseconds. Those pertaining to CPU usage on the Host Metrics that are particularly worth checking include: If you are trouble-shooting a performance issue it is important that you identify which resource is the bottleneck. Note: GPU metrics are available in XenCenter for GPU-passthrough but because of the nature of PCIe pass-through the hypervisor has no access to the actual data (pass-through means only the VM can see/access the GPU) and so these graphs and metrics will be zero (i.e. Proportion of time over the past sample period during which global (device) memory was being read or written on this GPU Proportion of time over the past sample period during which one or more kernels was executing on this GPU I’ve blogged about the availability of these metrics: įor NVIDIA vGPU the main metrics of interest are This guide does contain all the information on how to add graphs for metrics such as those for GPUs and how to set up alerts etc. ![]() ![]() The metrics for monitoring GPU usage though are not documented in the administrator guide as this is a set of metrics currently associated with the NVIDIA vGPU feature rather than available for any GPU vendor. for XS6.5 - Citrix XenServer® 6.5 Administrator's Guide. Always consult the version of the guide pertaining to the version of XenServer you are using e.g. There is a very detailed guide on which metrics are available, how to configure thresholds for alerts and how to trigger email alerts within Chapter 9 of The XenServer Administrator Guide. Many metrics are off by default to avoid unnecessary system load where they not normally be needed. XenServer MonitoringĬitrix XenServer has a good deal of metrics which can be accessed from a command prompt in the hypervisor or from within the XenCenter management console. This article focuses on monitoring CPU alongside GPU resources. Resource limitations may result in issues such as slow sessions, freezing sessions, sluggish mouse movements (particularly networking/bandwidth issues may cause this). ![]() Customers experiencing issues are encouraged to use their virtualization stack to monitor GPU alongside other resources. Frequently it is not the GPU resource causing the issue but CPU contention, too low a CPU spec (applications such as Petrel benefit greatly from a CPU >3.0GHz), RAM, IOPS, bandwidth etc. Many performance or scalability bottlenecks are caused by resource bottlenecks. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |