- QlikView scheduled tasks are not triggering as expected
- Schedules and task chains fail
- Tasks are listed as in Queued status
- QMC shows wrong task status
After an upgrade to QlikView 12, the disk may not be able to handle the increased traffic compared from QlikView 11 to QlikView 12.
- Qlikview 12.10 and higher
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.
QlikView 12.10 introduced a feature called Overload Protection. Please first review the article Tasks are not executed as expected and are shown in status Queued
to confirm if this is the behavior you are experiencing, as this could simply be working-as-expected behavior.
It may be worth verifying how many concurrent reloads are allowed in the system. See How many reload engines (QVB) to allow in an environment
File Share and Disk
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.
See QlikView and its backend File Share System
for background information on the above.
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 the 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
See QlikView Distribution Service / Publisher (QDS) high CPU usage without active tasks
Move the temporary storage of QlikView files for distribution
See QlikView: How to change the temporary storage of QlikView documents created before a distribution
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.
Review the below to monitor the system:
Related Root Causes:
QlikView 12 - Task randomly skip trigger