Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi all:
I am having a problem with a new application where there is a customisable report builder.
Every time when the user make some selections and show the table, the Qlikview Server use a lot of memories. And after the user logout of Access Point, the RAM will not released from the Qlikview Server.
I have read some discussion about this. It it believed that Qlikview Server actually will release RAM but not cache which is showing as memory in Task Management. And they are saying that the cache cannot be cleared unless restart the service.
Just wondering if anyone has a solution or any updates for this issue?
Thank you very much.
PC
You are right, cache can only be cleared upon a service restart. However, QlikView server manages memory in an optimal way. Cached results are shared between users so there is no duplication within memory as such.
Here's a summary from QlikView's Server Memory tech brief:
Hope that helps.
George
QlikView use massive caching. This good and done by good design.
When QlikView starts to use more RAM that your Working Memory Set High % as configured in the QMC it will flush old things out of cache.
Hence this is not problem per se, merely QlikView doing goo in memory analytics.
I know this is a bit unnerving until you get used to it, but notwithstanding that is it causing any actual issues ?.
You are right, cache can only be cleared upon a service restart. However, QlikView server manages memory in an optimal way. Cached results are shared between users so there is no duplication within memory as such.
Here's a summary from QlikView's Server Memory tech brief:
Hope that helps.
George
The behavior of the QlikView Server (QVS) memory manager can be summarized as follows:
In reality, QlikView Sister (QVS) will not acknowledge QlikView brother (QDS = Qlik Distressed Son - or Slave -, the reload manager) and therefor they will fight for precious memory bytes to the death...May cause some family fights...
And the cache will not necessarily play an active part in this, because even when nobody is visiting the QlikView AP (and all document loads have timed-put), the memory will not be released. Ever.
Peter
Hi Bill:
Thanks for your reply.
We only have limited amount of RAM. Definitely not massive. We need to think of a way to reduce the cache.
If the cache cannot be release, how can we reduce it?
Thank you.
Paco
Hi George:
Thank you very much for your reply.
Can we reduce cache by optimising the data structure?
What would be the best practise in this situation, small tables with lots of links or large tables?
Thank you
Paco
The cache is only populated by "query" results, things you select or search.
Optimization of QlikView docuemnts starts with not loading any columns you don't really need, reducing the number of discrete field values AKA cardinality (improves compression, symbol table size, and overall lookup speed) and the number of hops between data model extremities (press Ctrl-T in QV Desktop with your document loaded and count the number of association jumps).
But then again, a document with an inordinated amount of tables and a disgusting number of associative key values my perform decently on a huge number of fast cores with 1 Tb of RAM, while a simple 1 fact table-and-three-dimension-table document may perform in a sluggish way on a low-end server.. YMMV.
Best,
Peter
Hi Paco,
I wonder if you are getting confused between cache and general performance? QV Server will always take as much RAM as you allow it. So if you allow it 75% of your available RAM, it will always use all of that. You can reduce this by editing your Working Set settings.
You can certainly improve performance by optimising data structures. As of Best Practice, the rule of thumb would be use a link table for small data structures (eg dimensions around a large link table) and when performance starts to wane (as data volumes grow), then start consolidating into a single table. There's no point in prematurely optimising, you're better to go for simplicity and maintainability first.
There's obviously lots more to it and there's never a one size fits all but hopefully this is enough to answer your original question.
George