Vmware probe - Best Practices for better performance
Article ID: 33588
Updated On:
Products
DX Unified Infrastructure Management (Nimsoft / UIM)
DX Unified Infrastructure Management (Nimsoft / UIM)
CA Unified Infrastructure Management SaaS (Nimsoft / UIM)
Unified Infrastructure Management for Mainframe
Issue/Introduction
List of vmware best practices for better overall performance.
Symptoms of bad performance may include:
- slow load times for the GUI/checkpoints or data values
- empty GUI window showing no checkpoints/data
- missing metrics
- ESX host / Guest monitoring gaps
Environment
- Component: UIMVMW
- vmware probe - any version
Resolution
The java_jre package should be installed on the machine where the probe is going to be installed. In mid-2010, Nimsoft started packaging our own 'java_jre' which is available in the Archive. You simply need to deploy this package prior to deploying any java-based Nimsoft probes to the Robot. Deactivate the vmware probe, wait until it turns grey, then Activate it.
We do not recommend setting up the probe 'on' the vCenter machine itself.
Sizing Recommendations
Establish resources at the vCenter Level
The vmware probe operates most efficiently when resources are configured at the vCenter level or, at the absolute minimum, ESX host level. Typically, we do not recommend setting up more than 1 vCenter (up to 10 ESX hosts) per vmware probe. Again, if you have 10 ESX hosts all under the same vCenter, it is most efficient to setup the resource at the vCenter level. That said, for medium and larger environments, please also refer to the sizing recommendations.
Automonitors vs. Templates vs. Explicitly Set Monitors
Typically it is always most efficient to set monitors up as automonitors. This makes dealing with monitors more efficient for the probe and it's management of memory and cpu resources to handle monitors. On occasion, you may need to setup a monitor explicitly because you may need a very customized monitor for that specific resource, but we recommend setting up all monitors as automonitors when possible. Also, you can drag templates to Auto Configuration as a way of setting up automonitors. As of the introduction of the web-based Admin Console, you would use vmware templates instead.
However, note that applying templates to resources directly (static monitors)is just as inefficient for the vmware probe as setting monitors explicitly.
Workload Balancing
Start by looking at the size of the vmware config file. If it is over 8-10 MBs in size, there is likely a workload balancing issue.
You can often either split up the resources being monitored or the monitor volume among multiple instances of the vmware probe deployed among multiple robots. So balancing the workload helps. Avoid using static monitors if possible.
Performance Log File
Under the vmware probe directory, you will find a log file that is titled 'performance.log' (sometimes there may be more than one which are suffixed with a number). Looking at these logs, you never want to have times larger than 10's of thousands of milliseconds. When the milliseconds start translating into minutes, you need to investigate whether or not there are either too many resources or monitors configured for that probe AND/OR if the monitoring (check interval) is set too low.
Check Interval
You may want to consider increasing the resource check interval(s) initially. A 1 minute check interval is considered too tight for response back from the ESX host or vCenter. If certain monitors are more critical than others that the check interval needs to be set at 1 minute intervals, you may want to consider setting up 2 resources for the same ESX host or vCenter and then you will be able to set a smaller check interval for those more critical monitors on a resource and a longer check interval on the other resource for those monitors that are less critical.
Memory and CPU available to the probe
Review the resource utilization and availability on the host/VM where the vmware probe is deployed and make sure there is ample memory and CPU available to the probes running on that robot. Typically if you are below 20 percent memory or CPU available, you may need to either move probes off that robot to another less loaded robot, or increase the CPU and/or memory resources available on that robot.
If the availability of resources isn't the issue, you can look at the vmware probe's Raw Configure and setting the starting and maximum java heap size in the 'properties' -> 'java_options' section. The '-Xms' value is the number of bytes the probe will claim when starting and the '-Xmx' value is the number of maximum bytes the probe will claim if needed. Always remember to append the number with the letter 'm' (megabytes).
Additional Information
Feedback
Yes
No
Powered by
