Idea ID: 2702067

close UCMDB Job thread workers and release the DB Thread Pools to return memory to the System

Status : Waiting for Votes
Waiting for Votes
See status update history
over 1 year ago

UCMDB Probe Job Thread workers are shared pool workers, once they are created, they will never be destroyed.  The same is true with the DB Pool Threads where once created, they are never to be destroyed. The only controlling mechanism is the maximum worker and maximum number of DB Thread pool.  Such a systematic behavior lead to the ever growing consumption of the system memory without ever returning them to the system.  Eventually, the system will be brought down to its knees where routine diagnostics of the system cannot be done unless the probe is restarted.  

System administrators often are tasked to maximize the usage of the system resources.  With the above system behavior, we often have to budget at least 4G of RAM that are free at all time knowing that the system once start running the jobs, it will take up all the available memory.  In the world of VM, the above system behavior works against the principle of resource sharing.  This becomes the serious offender when we know those worker threads and DB Pool Threads are simply idling in the background. 

As a result, we are requesting that those Job Workers and DB Thread Pools once finished their tasks, they shall be closed.  Then for performance reasons, they can be closed only after a certain amount of idling time. 

The same is true for the "xmlenricher_service.exe" which is the enrichment process for the handling of the scan files.  They too only get activated when scan files is available.  Once all scanning activity are done, they too remain as idling in the background with all the memory gobbled up where the only way to control its use is through the maximum memory parameter.  

In our environment, the probe scans the server and network devices once a week, and those jobs literally are all completed within one day of time during the weekend.  As you can see, after the job is completed, without any extra buffering of the memory, the system would be remaining at over 95% use of all system memories.  In that scenario, it is difficult to make any attempts to log into the system and execute any kind of commands. 


  • Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team