UIM Slow Performance and Response Issues

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

As few environments and Unified Infrastructure Management (UIM) installations are the same, there can be different causes for performance issues. Some UIM configurations and deployments require more resources than others. 

This article applies in general to all UIM related performance situations.   

Please keep in mind when determining resource allocation (CPU, memory, disk), that UIM documentation provides only basic minimum requirements.  Also, as your UIM monitoring environment grows, so do the resource requirements.

Environment

Release: 20.x and above

 

 

Resolution

Follow the these steps, and note and think through the questions and their conclusions.

Important first questions to ask:

1. Which component specifically is impacted?  Can we identify a specific component (UIM, IM, OC or a specific probe)?
   
   
2. When did this start to occur?
   
   
3. Is it just sporadic or constant?
   
   
4. What are the system or vm specifications where the primary hub, UIM database, and OC are currently installed? (i.e., how many CPU cores and how much physical memory / virtual memory?)  Ideally, you should have at least 4GB per UIM system component.  The database server application itself (example, Microsoft SQL Server) consumes anywhere from 1.5GB to 2.5GB.  Certain probes, such as the snmpcollector, can consume more than 1GB alone.
   
   
5. How much virtual memory (Windows) or swap space (Linux) is configured on the system relative to physical memory?  For Windows you should have 1.5 times total physical memory (or 'System Managed') configured and on Linux/UNIX it is typically configured as the amount of total physical memory + 2GB.
   
   
6. How many UIM components are running on a single system? Ideally, the hub, UIM database, and OC should all be installed on their own VM or server.  Please be advised that there are other system resources used by UIM components besides physical memory and CPU for which these components will be in competition (such as java memory, pages, ports, sockets, etc.).
   
   
7. How large are the probe configurations and how many monitors are configured?  (For example, if you have a vmware probe, how large is the cfg file and how much memory is that probe consuming?  If you are looking at a multi-megabyte cfg file, there is probably too much for one probe - try breaking it up across multiple instances of the probe running on multiple robots.)
   
   
8. Why does it appear that I have plenty of free memory even though I am experiencing performance problems?  Many of the probes are configured with artificial default maximum limits in the memory consumption.  In some cases, you need to do a Raw Configure (SHIFT+rt-click on the probe) to change the the java min (-Xms) and max (-Xmx) under 'properties'->'java_options'.  Please keep in mind that the numeric value has to be followed by the letter 'm' (for Megabytes) otherwise you will only be configuring bytes.  Typically some of the probes which this is particular applicable are wasp and vmware.  However, any probe which can use auto monitors and templates may also be suspect (such as the Celerra and Clariion probes).  Again, look at the size of the cfg file and this should be an indicator.  Try setting the max java memory in these situations to 1024m or 2048m.
   
   Have a look at the memory consumption of the UIM processes (especially the 'java' processes) to see how much memory they are consuming (use Task Manager in windows or 'ps -ef' in Linux/UNIX) and then see what the available system memory is (Task Manager in windows or 'free' command in Linux/UNIX)
   
   
9. Database performance and issues can be a prime source of overall bad performance. It is consistently found that often extreme and dramatic performance improvement is achieved by applying the UIM database best practices of consistent and regular database maintenance and defragmentation, and improved governance (reducing data held by time data held and/or overall volume of QOS/Alarms generated/collected).

Additional Information

It is highly recommended to carefully apply the best practices guide attached based on your DataBase