There are more queues populated in the below probes .Whether it affects any process ?
That affects pretty much all meaningful services. I'd recommend grabbing a manual..
[Queued] column represents for number of data "Sitting in the queue. It is just waiting to be picked up by probe displayed in [Id] column".
alarm_enrichment / nas - Alarm data
data_engine - Performance Metric data
ProbeDiscovery - Inventory data
The large number of display in this column is an indicator of problem.
- Probe (picks the data) is hanging.
If it happens, [Queued] column continues to grow.
- Probe picks the data slowly or can't afford to process quickly than the data comes in.
If it happens, [Queued] column up and down.
QUEUE is managed via flat file.
Thing to confirm
- There are probes sending too much data.
- Your storage performance may not be matching what you need.
- You are collecting too much data than your infrastructure can afford to maintain.
I've seen scenarios like this, where queues backing up may be after restarting the services. But, as long as the queues are in contact (green) this should eventually get pushed off. The problem comes in only when the queue status is yellow. You can use the Dr.Nimbus to view the messages in queue and run the subscriber so that they get pushed off. But post this, you might need to restart the nimsoft services again. But as long as the queues are in contact, at times the queues grow but gradually it will get cleared off. All that it needs is some time.
I saw this in the past on Windows Hubs. If the Hub has to handle more than 64 subscribers/queues the Hub slows down.
Use hubs-Callback "list_subscriber" to figure out how many subscribers are active. If more than 64 you must split the queues to a second hub.
Hope this helps,
Yes it is a windows hub ,and there are 50 subscribers/queues active .
What you can also do is increase the bulk size to speed up the processing of each of these queues. You can do it thru the RAW_CONFIG of the primary hub and also thru the respective probes that subscribe to these specific queues.
I second Daniel's comments. You may have to adjust the bulk size a couple time to tune it correctly based on the size of your deployment and the # of alarms being generated. You can find info in the support portal.
In my opinion I'd agree with the slow IO/disk comment. I'm assuming that you do no enrichment based on the question so that fact that alarm_enrichment is backed up indicates that the system isn't able to keep up with simply reading from one queue and writing to another. Any server class machine manufactured in the past 10 years should easily keep up. I'd take one step further and guess that this server running UIM is actual virtual and that it is being starved for resources from the host side of things.
Retrieving data ...