search cancel

qos_processor_qos_message and _baseline alarms persist


Article ID: 33952


Updated On:


DX Unified Infrastructure Management (Nimsoft / UIM)


Example alarms: The queue 'qos_processor_qos_baseline' is xx MB. Check the hub configuration. The queue 'qos_processor_qos_message' is xxxx MB. Check the hub configuration


Component: UIMQOS


If the qos_processor queues tend to backup and not drain but you don?t have any enrichment scripts configured you can set the following setting to avoid this situation:

Open the qos_processor probe and set:
enrichment-enabled = false

Then the qos_processor can process faster but still do origin lookups.? This is often sufficient to keep the qos_processor queue from backing up.

Otherwise, if you do have alarm enrichment scripts in place, you can adjust the following settings:

Make sure you have enough physical memory to spare and increase the startup options of the probe:






and set message-receiver-bulk-size

to 2000 (as recommended by Development).

Make sure you also set the data_engine's bulk_size to 999 using the hub Raw Configure window->postroute section.

To remedy the situation right away you can usually just restart the probe but if you have a lot of messages queued, you may have to wait for it to drain after making the changes in 1 and 2 above.

As a fallback, if none of he above works as expected you might have a corrupted message in the qos_processor's .sds file. That .sds file is just a copy of the messages so it can be deleted after stopping the robot, if need be. Then activate the robot again.

Alternatively if really necessary, you could set up an AO profile to run a command to restart the qos_processor probe periodically or use an AO profile to restart it when the queue size reaches a specific size. See Article number: 000004427