Adding to Peter above, and in short, no, it's not normal that the server crashes or locks up but it can happen that the server is undersized and overloaded.
What it may be causing those locks or freezes are reloads which indeed, take more resources in QlikView 12 than they did in QlikView 11. This can be mitigated by reducing the number of concurrent tasks in the QMC, along with the measures in this post.
With regards to the possible undersizing of the current environment, that could also be the cause. What it is important here is not how big those apps are in disk but in memory, and what percentage each new user adds to that usage. Big apps with lots of distinct values can make every user add 1%, 2%, 3% or even more to the existing memory, if several of these applications are hosted in the same server, memory might need increase.
Compression level is irrelevant, it only affects to the use of the QVW in disk, not in memory. The difference between using high compression or none regarding opening and saving times should be small (there is a little overhead while the app is compressed).
If the server is virtual, it might need some tweaking to make sure it does not share vCPUs or RAM with other VMs hosted in the same server.
Also, the applications themselves should be checked, in case there are complex expressions in the front end that can use flags or preaggregations in the script, use of numeric values, reducing the app size (and therefore memory footprint) by using loop and reduce, etc.
It could also be that there are a lot of apps and a lot of users and that hardware is simply not enough.
And finally, after checking all the above, it might be worth checking with Qlik Support for a newer release or in case this is a known issue with that version specifically.
EDIT: forgot to mention Qlik Consulting or a Partner who can check the environment, perform benchmarkings and assess whether a bigger hardware is required or which improvements can be made in the app/reload process.
.png "Miguel_Angel_Baeyens"){kind=avatar}
