RAM usage is the result of what you include in the application.
This includes the data model and objects visited by the users.
It is not mainly how many users that consumes resources, it’s what objects they view, what data they view through the objects, the rate of cache-hits and how often they are triggered.
There are two measures of how RAM is consumed: initial and growth. Usage might change what measure is most important.
Initial size will depend on the data model, loaded fields and the uniqueness of the values in these fields.
The next thing to measure is the slope of the growth of RAM with usage. Application design, objects with dimensions and expressions determine this measure.
A steeper growth curve will naturally push the server towards WorkingSet-Low faster than a lower curve. When reaching this level, QlikView will have to start to purge previously stored cached data. This consumes some CPU, but as long as the CPU isn’t highly utilized this is handled very smoothly.
If the amount of RAM is mainly occupied with the actual application, leaving little room for the cache, will put pressure on the CPU to both manage the cache at the same time as calculating things that might have been calculated before but was purged from the cache.
If QlikView doesn’t manage to purge enough cache, then messages regarding WorkingSet will appear in the Event log.
If these messages start to occur, then I suggest increasing the amount of RAM in the server or assess the application design to see how the two RAM measures can be tuned for better user experience.
QlikView is very efficient when it comes to managing RAM so as long as you have “enough” for the current usage. Understanding how your data, application and users will consume RAM will make it easier to determine how much is “enough”.
Understanding how QlikView utilize CPU is equally important. Well-designed applications consume CPU in way that benefit both users and the server-administrators.
There's a White paper on Qlik.com where you can read about how QlikView use resources, as well as other White papers and Tech Briefs,, worth reading.
Hi! What is your source for saying you have a 80 GB source? Is this your database source size or, a QVW size?
If it is a Database, mind that indexes, log files, temp tables, and static views also amount for space, and it wont necessarily create an 80 GB QVW.
Additionally to what Lars is saying, you must also check your Data Model in relation to what is really needed, and aggregate some of your data in the Script, instead of rendering every single detail (i.e. In a telephone company maybe its valuable to know how much calls were made in a day, than have all calls mapped in the application).