CPU Details - Host Test
Excessive usage of physical CPU resources by the Oracle VM Server or its VMs can be the source of prolonged slowdowns that may be experienced by those VMs. Hence, whenever users complaint of slowdowns in their virtual applications, it would be best to first check whether the hypervisor has adequate unused CPU resources, as a CPU contention can have a disastrous effect on VM performance and consequently application performance. This is why, the eG agent, with the help of its CPU Details - Host test, runs periodic usage checks on the CPU resources of the hypervisor. Besides proactively detecting abnormal CPU consumption by the hypervisor, the test also accurately points you to the root-cause of the CPU contention - did it happen because of CPU-hungry VMs on the hypervisor? did it happen because of CPU-hungry user processes or system-level processes? did it occur when the hypervisor performed Kernel Same-Page Merging? or did it happen when the CPU was idle?
Target of the Test: An Oracle VM Server 4.x
Agent running the test: A remote agent
Output of the test: One set of results for the Oracle VM Server being monitored.
| Parameter | Description |
|---|---|
|
Test period |
How often should the test be executed. |
|
Host |
The host for which the test is to be configured. |
|
Management Server Host IP, Management Server Domain, Management Server Port, Management Server User, Management Server Password |
To auto-discover the VMs on a target Oracle VM Server 4.x and obtain the outside view of the performance of each VM, the eG agent needs to connect to the OLVM Manager that manages the target Oracle VM Server 4.x. To enable the eG agent to obtain the outside view, you need to configure the test with the following:
If the Oracle VM server being monitored was discovered via an OLVM manager , then the IP address, port number, domain name, and user credentials of the OLVM manager used for discovery will be automatically displayed against the respective parameters. If the Oracle VM server being monitored was not discovered via an OLVM manager , but you still want to use an OLVM manager for obtaining the outside view, then, you can select any IP address of your choice from the Management Server Host IP list. By default, this list will be populated with the IP addresses/host names of all the OLVM managers that were configured for the purpose of discovering the Oracle VM servers. If you select an Management Server Host from this list, then the corresponding port number, domain name, and user credentials will be automatically displayed against the respective parameters. On the other hand, if the OLVM manager that you want to use for metrics collection is not available in the Management Server Host list, then, you can configure an OLVM manager on-the-fly by picking the Other option from the Management Server Host list. An ADD THE OLVM MANAGER DETAILS window will then pop up. Refer to Configuring an OLVM Manager to Use for Monitoring the Oracle VM Server 4.x to know how to add an OLVM manager using this window. Once the OLVM manager is added, its IP address, port number, domain name and user credentials will be displayed against the corresponding parameters. |
|
Confirm Password |
Confirm the Management Server Password by retyping it here. |
|
SSL |
If the OLVM manager to which the eG agent should connect is SSL-enabled, then set this flag to Yes. If not, set it to No. |
|
Hypervisor User |
Specify the name of a user who has the right to connect to the Oracle VM Server 4.x via SSH. |
|
Hypervisor Password |
Specify the password of the Hypervisor User. |
|
Confirm Password |
Confirm the Hypervisor Password by retyping it here. |
|
Hypervisor SSH Port |
Enter the SSH port at which the Oracle VM Server listens. |
|
Detailed Diagnosis |
To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:
|
| Measurement | Description | Measurement Unit | Interpretation |
|---|---|---|---|
|
User CPU utilization |
Indicates the percentage of CPU utilized by user processes. |
Percent |
Comparing the value of these measures will enable administrators to figure out where the hypervisor is spending the maximum CPU time - in processing user requests? in system - level processes? or when being idle? |
|
System CPU utilization |
Indicates the percentage of CPU resources that the hypervisor utilized for system-level processing. |
Percent |
|
|
Idle CPU utilization |
Indicates the percentage of CPU time utilized when the hypervisor was idle. |
Percent |
|
|
CPU utilization |
Indicates the percentage of CPU utilized by the hypervisor. |
Percent |
A high value of this measure is a cause for concern, as it indicates excessive CPU usage by the hypervisor. If left unchecked, it may cause a serious contention for CPU resources amidst VMs. Use the detailed diagnosis of this measure to know which VMs on the hypervisor are consuming the CPU resources excessively. |
|
Kernel samepage merging CPU utilization |
Indicates the percentage of CPU time spent by the hypervisor when performing Kernel Same-page Merging (KSM). |
Percent |
Memory page sharing is supported through a kernel feature called Kernel Same-page Merging (KSM). KSM scans the memory of each virtual machine and where virtual machines have identical memory pages KSM merges these into a single page that is shared between the virtual machines, storing only a single copy. If a guest attempts to change this shared page it will be given it's own private copy. When consolidating many virtual machines onto a host there are many situations in which memory pages may be shared – for example unused memory within a Windows virtual machine, common DLLs, libraries, kernels or other objects common between virtual machines. With KSM more virtual machines can be consolidated on each host, reducing hardware costs and improving server utilization. Use this measure to determine how CPU-intensive KSM is. |