Large QlikView deployments may see a variety of issues caused by the backend file server. Symptoms can range from task failing to trigger as expected, QMC failing to display the current status of the system, or delays in displaying the document list in the AccessPoint, as well as Qlikview Server service crashes due to Fiber loop stalls, or bookmarks being lost when the service cannot lock on to the new TShared files.
When planning the QlikView deployment, it is important to keep in mind the type of storage (SAN, NAS?) and resource capacity.
Possible symptoms:
Is the storage used supported?
See Does QlikView Support NAS Storage? for details around NAS storage. Use of alternate storages, like Amazon FSx, is currently not supported. As a rule, QlikView currently only supports a Windows File Share, shared directly by a Windows server.
File storage monitoring:
- Average % of CPU usage
- I/O activity and read/write queues on the affected disk
- Request queue for disk access - if this is above 2, we expect to see problems
- Network utilization
- If a virtual environment is used: Are resources dedicated?
Possible solutions based on the above findings:
- Add additional CPU cores
- If the file share storage is used for both front end and backend, dedicate one to each
- File storage should always serve only one QlikView Server cluster
- The QlikView Distribution Service Notification system can be relocated to a different storage for performance improvements
Environment:
QlikView any version
