Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..
157 views

bottleneck  uCMDB

Jump to solution

Hello dear community,

Is there any possibilities to have a bottleneck on the ucmdb server (like number of simultaneous connection using HTTPS,...)

i ask you because we have a 45 millions CIs park and our server is like doing nothing. Or maybe we have  a beast server  😄

 

Best regards. 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: bottleneck  uCMDB

Jump to solution

Oh there are so many parameters, written in the Infrastructure Settings, DataFlowProbe.properties or on the job level (you can check the Range by ICMP). The goal of the fuses and the limiters is exactly to prevent bottlenecks by limiting the simultaneous executions of each job or sending too many results to UCMDB. 

On the Data Flow Probe Status during discovery you can see the size of the outstanding queue from the probe to UCMDB. To minimize the impact on ucmdb there is also a touching mechanism implemented - the probe caches the results sent to UCMDB and when it discovers the same assets again, it only sends changes. 1 time per 24 hours it may send also a "touch" operation, which is kind of keepalive that this CI  is still discovered and shouldn't be aged if nothing if modified on it (this operation updates the LastAccessTime). 

In summary it is very hard to say where a bottleneck may appear. If you are happy with the speed of discovery. Monitor the parameters of the probes and ucmdb and check if java memory usage doesn't reach its limits.

 

Likes are appreciated!

View solution in original post

3 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: bottleneck  uCMDB

Jump to solution

I have never seen UCMDB's bottleneck to be the number of users connected. Even if the users are numerous, they use simple searches or views which are often cached. 

What causes the bottleneck is the database performance on operations like enrichments, join queries, discovery with a lot of reconciliation, integrations. These operations are database intensive and cause slowdowns and more memory usage, which may cause java memory heap size exceptions.

 

Cheers,

Petko Popadiyski

Freelance Microfocus CMS UCMDB Consulting

Likes are appreciated!
Highlighted
Trusted Contributor.. Trusted Contributor..
Trusted Contributor..

Re: bottleneck  uCMDB

Jump to solution

Hi @popadiyski,

Thanks for the reply.

I'm not talking about user's connection but https connection for each probe and each jobs to the uCMDB server. Is ther any way that's a bottleneck cause if there is one ? i don't know how much http connection windows server accept at the same time. Or UCMDB. 

 

It's a reflexion subject. We are auditing our ucmdb park. 

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: bottleneck  uCMDB

Jump to solution

Oh there are so many parameters, written in the Infrastructure Settings, DataFlowProbe.properties or on the job level (you can check the Range by ICMP). The goal of the fuses and the limiters is exactly to prevent bottlenecks by limiting the simultaneous executions of each job or sending too many results to UCMDB. 

On the Data Flow Probe Status during discovery you can see the size of the outstanding queue from the probe to UCMDB. To minimize the impact on ucmdb there is also a touching mechanism implemented - the probe caches the results sent to UCMDB and when it discovers the same assets again, it only sends changes. 1 time per 24 hours it may send also a "touch" operation, which is kind of keepalive that this CI  is still discovered and shouldn't be aged if nothing if modified on it (this operation updates the LastAccessTime). 

In summary it is very hard to say where a bottleneck may appear. If you are happy with the speed of discovery. Monitor the parameters of the probes and ucmdb and check if java memory usage doesn't reach its limits.

 

Likes are appreciated!

View solution in original post

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.