We are experiencing intermittent crashes and automatic restarts of QlikView Server (QVS) in our environment, and would like to request your assistance.
1. Current Environment
QlikView Server: 12.40.20100.0 (June 2019 SR1)
Configuration: Single-node, dedicated server (no resource sharing with other VMs/hosts)
Server Memory: 2TB
Operating System: Windows Server (exact version to be confirmed)
Target Documents: Specific QVW and its associated .meta / .shared / .tshared files
Engine Settings:
NUMA detected and enabled (NUMA DETECTED, Engine adapt to NUMA)
Working Set memory configured to 60%–90% (1.2–1.8TB)
2. Current Situation and Crash History
September 23
Approximately 64 QVS crashes occurred
Repeated log errors observed:
Internal inconsistency type CPV
StdServer: Fiber loop stall detected
Action: Suspected QVW and its .meta / .shared / .tshared files were excluded from operation
Result: QVS stabilized, no further crashes
September 24 (morning)
Same state maintained → no crashes
September 24 (after 13:00)
Deployed with .shared excluded, but QVW + .meta + .tshared included
Crashes occurred again
Logs at the time:
Fiber loop stall detected
Restart: Server aborted
Core dump
3. Findings Afterward
Shared File Analysis
Viewer showed records with missing IDs → possible corruption
Stable when excluded, crashes reappeared when reintroduced
Shared file size: approximately 257MB
.tshared / .meta File Impact
Even with .shared excluded, crashes occurred when .meta + .tshared were included
Possible corruption of .tshared cannot be excluded
QVW File Size
Target QVW size: approximately 16GB
Large QVW may contribute to instability when combined with shared/meta/tshared during session load
Performance Logs
9/23: VMAllocated remained around and above 1.5TB, and repeated crashes occurred during this high memory usage period. Crashes were not limited to a specific threshold exceedance.
Fiber Loop stall may be related to NUMA/Working Set configuration
NUMA Logs (repeatedly observed during crash/restart sequences)
NUMA: Engine configured toget adapt to NUMA environment NUMA: NUMA DETECTED
These logs are recorded every time the engine restarts after a crash
It is unclear whether they are only normal startup logs or related to the issue
4. Questions to Qlik Support (1) Memory-Related
During 9/23, VMAllocated stayed around and above 1.5TB and repeated crashes occurred. Is high sustained memory usage directly related to the crashes?
Can Fiber Loop stall occur purely due to memory exhaustion or fragmentation?
Is the current Working Set setting (60%–90%) appropriate, and what would be the recommended value?
(2) QVW and Shared/Meta/TShared
Can Fiber Loop stall during QVW execution be caused by corruption or abnormal records in the QVW or its associated files?
Since crashes also occurred with .meta + .tshared but without .shared, could .tshared corruption be a contributing factor?
What are Qlik’s recommended best practices for maintaining, repairing, and managing .shared/.tshared files?
Could the size of the QVW (~16GB) and shared file (~257MB) contribute to abnormal termination or Fiber Loop stall?
(3) NUMA and Engine Settings
In NUMA environments, can Fiber Loop stall or deadlock-like issues occur?
Are the repeated NUMA logs during crash/restart sequences just normal startup messages, or do they indicate something related to the issue?
Would disabling NUMA or adjusting the Working Set configuration help stabilize the environment?
5. Additional Notes
If there is any further information, such as detailed logs, configuration files, or file samples, that would help in the investigation, please let us know and we will provide them.
Thank you in advance for your support and guidance.
In the earlier days there were the Power Tools which provided features to look and repair shared-files. Nowadays it seems to be changed in some way - here a starting point for the matter: Cleaning and converting the shared files | QlikView Help
Your observing that the shared- and meta-files are related to the crashes hints in two directions.
One are in any way invalid access-information within the files (shared-files contain for example bookmarks which may call partly deleted/corrupt objects/groups/variables/expressions ... maybe even nested and/or for not existing users/user.groups which are maintained within the meta-files). AFAIK are the elder shared-files quite vulnerable for any issues and the newer tshared much more stable (your descriptions isn't clear which one are really in use).
Both files are accessed within a user-context and related to the user-interactions. Therefore it might be possible to trace the crashes to certain users and their actions which means that a look for the users which were active to the crash-times (session-log) and what were they doing (audit-log) may give useful insights.
The other hint goes further to any timing/address conflicts. If the I/O address for a certain handle was changed and the tool must take an extra jump the needed time will increase and may in the end too long. Qlik is quite sensible in this regard.
Just for the testing purpose you look what happens if NUMA is disabled and further a check against a hardware-impact to reduce the RAM maybe to 1 TB (not mixing different sizes/types/speed ... only one socket ... reducing any risks of conflicts).
Daniele - Principal Technical Support Engineer & SaaS Support Coordinator at Qlik If a post helps to resolve your issue, please accept it as a Solution.
