QlikView Server Crashes down regurlarly

[Bodo]

Hi all,

after installing QV12 in a new server environment, we unfortunately have often performance problems regurlarly and in a not systematic pattern and often ad-hoc in not scalable time-frames (for example apart from regular script runs). 

With reagrds to server metrics (CPU, Memory, Disk) we cannot determine the exact reason as technical critical thresholds are not exceeded.

In a very simple heuristic approach, I have the suspect that a single frontend user (in the web application) might cause the crash by using existing documents and displaying all dimensions in a object, without setting selection filters upfront.

Is this possible or can we exclude my suspect? If possible, how can I analyze my suspect more deeply?

Thanks in advance,

B.

[marcus_sommer]

Please elaborate it more detailed how your environment look like - single server, clustered, physically machine or VM, releases of OS and QlikView including the used clients and of course what you mean with crash? Certain QlikView services become unresponsive or be terminated or the access to the QMC/Access Point breaks or the whole server goes down or ....

Further how differs the new environment from the old one? Just a new server and/or any upgrades of OS / QlikView releases? Was it a image-duplication, a complete new installation including all new configurations or were they copy & paste from the old one? Also any major changes within the configuration like authentication method and so on?

Beside of all this the various log-files from OS and QlikView may provide valuable hints of what's going wrong.

- Marcus

[Bodo]

Hi Marcus,

Thanks a lot for your prompt answer.

It is a VM and windows server 2019.  By crash I mean sometimes the whole server goes down. If not the whole server goes down, at least services are not responding and the frontend user cannot see any documents on a dashboard.

Regarding differences between the new and old environment, we have now windows 2019 (as mentioned above) and before we had windows 2012. The version of QV was 11.2 and now we have QV 12. We had a complete new installation and applied manually old configurations in the new installation. Existing QVDs has been copied & pasted from the old one, processing those in our regular task proceedings work fine and do not cause any problems. Just the processing of one certain task needs more time, but this do not lead to an incident/ break down. We do not have any further changes within the configuration like authentication.

Best regards,

B.

.

[Chip_Matejowsky]

Hi @Bodo,

What is the full version of QlikView Server (e.g. 12.60 SR1, 12.50 SR2)?  The Qlik Support article Troubleshooting a QlikView Server: Performance and crashes is a good guide on how to start investigating QVS crashes.  These issues can be very difficult to troubleshoot so you may also want to reach out to Qlik Support and create a case.
Best Regards

[marcus_sommer]

We also did a very late upgrade from 11.2 to 12.5 but we started nearly everything from the beginning. Reasons for it was that between both releases were multiple major-releases with a lot of changes on (default) configurations and features and some applications had a quite old age from the creation point of view - back until 8.0 - and we wanted a new unified basis to avoid any potential risks of release-conflicting between them and the new release.

Further we needed also a new business release of our reporting because of the huge number of new and changed requirements of the last years which were often only patchwork and it became meanwhile quite unhandy.

By smaller changes and/or only replacing the server or OS or switching between the test- and productive-environment we do it exactly like you by a more or less copy & paste approach including the configurations. And usually it worked very smoothly.

Beside of the recommendation from Chip you may take a look on the VM settings/logs because QlikView (and partly also the OS) is quite sensitive in regard of dynamically switching the resources between the VM's on a host. Not everything might be restored properly or in time and AFAIK especially the authentication against the active directory and between the qlikview-services are critically. Like above mentioned the various log-files should cover valuable hints. In this regard it might be also useful to enable all and to increase their granularity.

- Marcus

[Albert_Candelario]

Hello @Bodo ,

If you suspect of a user, maybe who has created a server object on the app and leading to such problems you could check the QlikView event logs and audit one to trace the actions perform by the users at the moment when the QlikView server has crashed to see if you see a pattern or not. This would also help to exclude your suspicious or not.

I hope this is useful for your debugging exercise.

Cheers.

[Bodo]

Hi all,

thanks a lot for your answers, it was very helpful to me - for my concrete problem as well as for my understanding. However, I made a deeper analysis based on the performance logs and found out a positive correlation between "Ø CacheBytesAdded" or "Ø CacheTimeAdded" to the probablity of a server shut down.

With other words: the more the value of Ø CacheBytesAdded is, the more is the probability of a server shut down, based on our data. From your perspective: is this logical, i.e. what is the rationale behind the correlation? And what can we do in order to decrease Ø CacheBytesAdded in order to decrease probability of a server shut down?

Does it make sense to increase RAM? Would this lead, ceteris paribus, to a lower Ø CacheBytesAdded?

Best,

Bodo

[Chip_Matejowsky]

@Bodo,

The  technical brief - The Qlik® Associative Engine memory management and CPU usage will likely be helpful to you in better understanding how the QlikView engine uses memory and CPU cycles.

What is the total amount of RAM on this server currently?  How many QVWs are in use and what are their sizes in MB on disk?

Best Regards 

[Bodo]

Hi @Chip_Matejowsky ,

thanks a lot for your answer and for your document. 

Regarding memory: we have 32 GB RAM on the server and use in total 7 QVWs with a total size of 1.703 MB.

We have 4 small sized QVWs (0,1-0,2 MB) and 3 big sized QVWs (540, 545 and 616 MB).

Best regards,

B.

[marcus_sommer]

If the qvw's are compressed their RAM consumption might be much higher as their size on the disk. We don't use this feature anymore since many years and therefore I don't remember the compression-rates exactly. I think it was usually something between 5 - 7 but even a factor of 10 and higher wouldn't surprise me - of course always depending on the kind of data.

Further could you be sure that the VM has always an exclusively access on the resources? Like above already hinted Qlik and other tools are sensitive if as reserved marked resources aren't always available. We have already noticed occasions in which an overload on one of our servers led to a lost of access/connectivity from another server - although the IT says that they are independent of each other ...

- Marcus