|Symptom: qos_processor alarms
Example alarm-> The queue 'qos_processor_qos_message' is 410 MB. Check the hub configuration.
Cause: known issue of slow memory leak in version 1.20/1.21/1.22 (to be fixed in a future release)
Interim workaround: restart the qos_processor probe when the queue gets backed up
Open the nas probe and select the Scripts Tab.
Rt-click and create a new script, edit the address if necessary and use this as the script and save it as qos_processor restart or whatever name you prefer.
addr = "/NMS/NMS-Server/NMS-Robot/hub" -- insert the Nimsoft address for the robot where the hub runs
probe = "qos_processor"-- ***specify the probe to be restarted***
local args = pds.create() -- create data structure to pass arguments to probe callbacks
Create an Auto-Operator profile with:
- Action type of 'script'
- Action mode of "On message arrival"
- Severity: Warning
- Message Filter: /.*The queue 'qos_processor_qos_message' is.*/
- Message Counter: Greater than
- Value: 1
- Select the qos_processor restart script from the pulldown.
- Name the profile, e.g., Restart qos_processor on alarm
- Click Ok, then click Ok again to restart the nas probe.
- Make sure the AO Profile is enabled.
The script will automatically restart the qos_processor probe when more than one alarm occurs and it will alleviate the qos_processor_qos_message queue backup.
Note that for customers who experience qos_processor queue backups but don?t have any enrichment scripts configured you can set the following qos_processor probe parameter via Raw Configure:
enrichment-enabled = false
This allows the qos_processor to process faster and still perform origin lookups.? This is often sufficient to keep the qos_processor queue empty.