Server freezes

[jonip_78]

We have had this problem for some time. A couple of times a week the server gets stuck, everything slows down, for example it takes a while to open the task manager and we have to restart the server to fix the problem.

We have recently moved QV to a new server Server 2008 R2 > Windows Server 2022. The problem has now gotten worse on the new server. Before when the server slowed down on 2008 R2, we still managed to restart the server ourselves. Now, when the problem starts, the server usually disconnects RDP connection, and we can't restart the server ourself anymore.

Often the problem seems to start if there are two people on the server with RDP editing some QV files at the same time. For example, on weekends, the server works fine by itself.

The Qlik forums are full of messages about the same problem. I think that by now we've tried all the solutions that have been suggested.

The server has QlikView Enterprise Edition. There are about 150 QMC tasks from different databases. The server has 48Gb of memory and 8 cores.

In QMC > QV distribution service the  "Max number of simultaneous QlikView engines for distribution" is currently set to 4.

This has worked fine in the past for years and this started on 2019 I think. Does anyone have any ideas?

[vincent_ardiet_]

There are many possible reasons.
However, if I understand well your message, on your server, you are running the distribution services (reload engine) and you also have user doing RDP using QlikView client right? And have you another machine for the QVS process or this is also managed by the same server?

[jonip_78]

Hi,

That's correct. QVS is also managed by the same server.

[vincent_ardiet_]

Try maybe to play with the CPU affinity and memory working set, QVS is always trying to use the maximum amount of memory possible and here you need to keep some for the distribution service.

[marcus_sommer · Accepted solution]

It sounds like a lack of RAM in regard to your usage-scenario of having all services running on the same machine and allowing several users to connect to this machine - probably to develop and/or maintain anything in QlikView.

Each time the RAM consumption hits the 100% or comes quite near you have to view the OS session as invalide. So the simplest approach might just be to increase the RAM maybe by doubling it or even a bit more. But this won't exclude each occurrence else only minimizing the risks respectively the frequency. Better would be to separate the services to dedicated machines - especially the server and the distribution service and not developing, maintaining or testing anything on the production machine (only troubleshooting in critical cases) else using separate environments and/or local machines. 

[jonip_78]

I'll try this.

[Or · Accepted solution]

A possible reason for this to happen would be if a user created a personal object that is unreasonably difficult for Qlik to calculate, e.g. something with a large Cartesian join. If you enable more detailed logging, you should be able to see if there's a common thread for these situations - a specific user/app combination that seems to happen just before the server hiccups.

Of course, this may be entirely unrelated - just throwing it out there as something to potentially look at.

[jonip_78]

Thank you all. I think that the problem is because of combination of issues that has been mentioned above.

We download data directly from databases and do all the heavy work in QlikView or Qlik Sense. 1Tb QVD files are not uncommon. The amount of data has grown a lot over the years so this might be why this problem started for no apparent reason in our QlikView server.

I'll ask some more memory, try to play with the CPU throttle again and we'll try to move development into another server. It has just been easiest way to make the changes directly on the production server.

[marcus_sommer]

I think that doing everything in Qlik is in general very sensible but using large QVD's might be not optimal especially if there isn't much RAM available. Therefore I suggest to consider if a slicing of them and also by the creation-tasks would be possible - maybe by adding one or two more layers within the incremental logic.