Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi David, our issue was that we were on v10 r4 and were experiencing memory leaks - in brief after a reload a second document remained in memory and could not be flushed hence when we hit wsl we started paging. We've upgraded to v11 sr2 and memory leaks are much less frequent though they sometimes do occur. Some people will tell you that QlikView does not have memory leaks but they're mistaken, unfortunately many people report normal behaviour as memory leaks because they don't understand qlikview which gives those who claim Qlikview does not experience memory leaks credence.
The chances are though that you just need to configure your environment and are not experiencing a true issue with QlikView, so the onus is on you to do some analysis and tweaking. You need to start monitoring QVS process to see how it grows and understand if you've got enough RAM for all your documents - they'll be 4.25x as big in Memory as on disk. Then you'll need more RAM for cached results so you need to understand how quickly that gets depleted with user activity. Depending on the size of your environment you may wish to alter the working set low - we're currently at 92% and 96% but with 288GB of RAM. This allows about 22GB of RAM for processes other than QVS. This was a figure arrived at after analysis of usage, not guess work.
What's important is that you understand what else is consuming memory. If publisher is on the same server then QVB process(es) will be directly competing for RAM with QVS and paging will occur long before hitting working set low. If that's the case you may wish to have a separate publisher.
i.e.
You should monitor QVB process(es) sizes when tasks are running and see if they are consuming more RAM then the server has got hence use Pagefile. We have a process that runs once a month that consumers about 120GB and the server is 100GB but as we have a separate Publisher and it's only once a month for 2 hours it's not worth investing in more hardware.
Take a look at these 2 documents on how to use Perfmon to monitor QlikView usage:
How to set up Windows Performance Monitor For QlikView Servers
QlikView Performance Monitoring
n.b. There's no configuring of Pagefile that you need to do, you need to configure your environment to avoid using it if possible,
From my experience the difference between wsl and wsh has no relevance. It's the wsl figure that is key.
We have an application that reloads every night. When the reload is complete the new versions gets distributed then loaded in Memory to replace the old version. However more often than not the older versions does not drop out of memory (even though only allow 1 version in memory is enabled). i.e.
This extra document cannot be flushed from cache like the "cached results" therefore the system starts paging when we reach wsl. We've got a case open with Qlik since January, we were able to prove this was a genuine memory leak (as the only system activity is reload at this time) and we provided them with a document so they were able to recreate the issue, however they still have come up with a fix. Therefore we schedule regular restarts of QVS to avoid running out of memory.
My advice would be to ignore the QlikView Performance Logs and instead set up windows perfmon monitoring as per above links. Collect and look at the following 3:
\Paging File(_Total)\% Usage
\Memory\Available MBytes
\Process(qvs)\Private Bytes
When Paging % Usage starts growing you want to compare that to how many Avail MBytes you have left and the size of QVS in Private Bytes. If you've run out of 'Avail MBytes' when paging occurs then your WSL us too high, if you've got plenty (i.e. more than 5GB) spare then adjust your WSL upwards.
n.b. The '% Committed Bytes In Use' metrics combines RAM and Paging file so if you don't understand this and know the size of your paging file it can be misleading.
We also have system managed page file, this is the best way to go. However what you want to do is avoid using paging file totally for QlikVIew (and not worry about how big it is set to). You really need to understand your application and how it consumes memory over time - for example our 10-12 documents have a base footprint of 80-100GB and at peak times we consumer 40GB an hour with cached results etc and when we reach WSL Qlikview becomes unpredictable so we have cache flushes and recycles to avoid hitting that point.
If you've got a large document (in Memory) you don't want to be at wsl when it has finished reloading. QlikView does not seem to cope well with loading a document int o Memory and flushing cache at the same time.
