UCMDB and UD Practitioners Forum (Previously CMS)
Showing results for 
Search instead for 
Do you mean 

Recommendations within a virtual uCMDB environment

Occasional Contributor

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?

Trusted 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.

//Add this to "OnDomLoad" event