Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..
300 views

Recommendations within a virtual uCMDB environment

We have recently implemented uCMDB within our network and have determined that we need the standard sizing based on the number of systems we have. Within our production network, all of our systems are virtual including the database server running MS SQL 2012. We have one application server (8 processors, 16GB RAM), two main probes (4 processors, 16 GB RAM), and one database server (8 processors, 16 GB RAM).

We have discovery jobs running daily for both infrastucture and inventory templates, and are experiencing a lot of timeouts and bottlenecks. I've researched some of this and did find a whitepaper on suggested application and probe settings to help alleviate these issues. So far they have not worked. I also read that it is suggested to house the database server on a physical server when dealing with performance issues.

Is there any merit to this suggestion? Also, does anyone have any suggestions on other ways we can improve the performance of these jobs?

0 Likes
1 Reply
Highlighted
Honored Contributor.. Honored Contributor..
Honored Contributor..

Re: Recommendations within a virtual uCMDB environment

Can you articulate in more detail where the issues arise - what kind of timeouts you see? Improving performance can be as simple as updating certain fuses/thresholds, and a surgical as changing the JVM memory allocation and ratios between young and permanent.

the short is that there is no one-size-fits-all solution. I wouldn't look at the database unless you see a lot of CPU usage, and/or slowness reports (in the cmdb.dal.slow.log) consistently. 8 CPU on the DB seems more than enough for what you mentioned - memory is something that can always increase (just make sure you configure the DB to actually use it).

E.g., review the reconciliation logs if there is a backlog in seeing discovered info in the GUI, as everything that comes from the probes must go through this single-threaded process.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.