The Windows File share the QlikView Distribution Service uses as its Root folder, the ApplicationData folder set in the QMC, is being overloaded. The ApplicationData folder hosts the trigger information, notification files, and historic data. This can affect an entire QlikView Distribution Service cluster and will occur more frequently if many tasks contain a Distribution either to the QlikView server or to a folder.
If the sanity check above does not apply (tasks should trigger, the CPU is not overloaded), the following may need to be done to fine-tune the system:
Move the Notification Folder
If a higher-performance disk is available (such as an SSD, optimized for higher levels of traffic), an easy troubleshooting step is to change the location of those high-traffic XML files to that disk. This can be done by:
Shut down all Qlikview services on all nodes
Add this under ************Misc Settings***********
<!-- Notification System alternate location, must be identical for all nodes in the cluster-->
<add key="NotificationFolder" value="\\UNCPATHTOLOCATION\"/> to QVDistributionService.exe.config on all Qlikview Distribution service nodes
3. Restart all Qlikview services on all nodes If this resolves the issue, then this confirms the disk currently used to host the Notification Folder.
Lowering simultaneous file handles to update the file system
If a high-performance disk is not available for testing, then the other option is to analyze the disk traffic with Windows Performance Monitor. Examine the Avg. Disk sec/Transfer and the Avg. Disk sec/Read disk metrics, and use a guide such as this one, which discusses general metrics for disk i/o to judge if the disk is exhausted.
Overload Protection may prevent tasks from executing due to CPU usage being above a threshold.
One of the changes that was introduced in QlikView 12.10 and up is a re-factored Notification system for the Distribution Service, where we now access more files in parallel to avoid an old problem in using a cascading Notification system which would lead to a build-up of updates needing to ripple through the file system.
The Notification system is where Task statuses are recorded, updated and retrieved by the QDSes and the Management Console. The QDSes might face issues recording the status changes correctly and end up in a status where it cannot run any more tasks because it is unable to clear that statuses of the ones already completed. We know this change to have caused the same type of behavior in other customer environments, as it now exposes any file system latency in a different way.