QlikView QVS Incident Inquiry

qwebnm — Mon, 26 Jan 2026 16:26:21 GMT

Dear Qlik Support,

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.
- 9/24: VMAllocated ~650GB, VMFree ~1.6TB → crash occurred despite sufficient free memory
NUMA / Working Set
- NUMA enabled, Working Set configured at 1.2–1.8TB
- Fiber Loop stall may be related to NUMA/Working Set configuration
NUMA Logs (repeatedly observed during crash/restart sequences)

NUMA: Engine configured to get 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.

Re: QlikView QVS Incident Inquiry

marcus_sommer — Thu, 25 Sep 2025 07:41:48 GMT

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).

Re: QlikView QVS Incident Inquiry

Daniele_Purrone — Thu, 25 Sep 2025 09:22:00 GMT

Hi @qwebnm I would definitely recommend disabling NUMA as the first step:
https://community.qlik.com/t5/Official-Support-Articles/QlikView-Server-Settings-For-NUMA-Performance-Improvement/ta-p/1710234

topic Re: QlikView QVS Incident Inquiry in QlikView

QlikView QVS Incident Inquiry

Re: QlikView QVS Incident Inquiry

Re: QlikView QVS Incident Inquiry