Yes, by not running any other apps on a QlikView server, especially not memory-hungry ones.. (=best practice)
I don't think a Windows server supports memory partitioning like a mainframe does. QVS meets halfway in that it will grab and keep to itself all memory that it ever needed. That behavior can be restrained, but that's just the opposite effect (keeping a minimum amount of RAM available to other apps).
Try to move the other apps off the QlikView server. Otherwise, your next question may be "how to reserve CPU cores for QlikView exclusive use"
I think not. there must be a deep understanding of how work the memory manager windows, his notion of the maximum and minimum working set limit for any application, not necessarily for the QV server
copy paste from internet
this is what the memory design tries to achieve
A. The three limits (all are normally in % of total RAM):
a.Low Working Set Size – Above this limit Windows is allowed to swap “QlikView memory” to disk
b.High Working Set Size – Above this limit Windows should Swap “QlikView memory” to disk
c.Cache Limit – Upper limit for what we keep in the cacheB.
QlikView assumes that it has reserved physical memory up to the “Low” limit.This means that it will NOT release cache memory even though the cache is beyond the set Cache limit.This memory is “QlikView memory” and if we do not have better use for it, extended caching is still ause…C.
The “High” limit is primarily intended to give other applications on the machine a fair chance.If you have lots of memory on a dedicated QVS machine, you can set it to very high (>95%)So, you get two distinct operating scenarios:A.
Below the “Low” limit.In this scenario, QlikView will never release any memory from the cache, so it will look like the cachereleaseis not working to someone that is not familiar with the setupB.
Above the “Low” limit.In this scenario, QlikView will keep the cache size below the set limit. QlikView will act “as you wouldsuspect it to act”