QlikView + Qlik Sense Blog von Heldendaten

Über das Memory & Cache-Verhalten des QlikView Servers wurde schon viel geschrieben. Trotzdem bleibt das Gerücht hartnäckig, dass der QlikView Server ein Memory Leak hat.



Wenn man sich jedoch einmal mit dem WorkingSetLimit-Setting in der QMC beschäftigt hat, wird einem  klar, dass der QlikView Server einfach gerne aggressiv cached. (Fast) jedes gerechnete "Chart", welches sich aus einer Userselektion ergibt, will der QlikView Server cachen, sofern er noch Memory (<= WorkingSetLimit Low) dafür zur Verfügung hat. Damit braucht ein QlikView Server immer weniger CPU-Zeit, "frisst" aber für gewöhnlich im Verlaufe eines Tages das Memory des Servers auf (und gibt es auch nicht mehr frei, sofern er das WorkingSetLimit Low getroffen hat).

Dieses Verhalt kann nerven - speziell wenn man am gleichen Server auch noch den Publisher/ServerReload laufen hat, und jemand zusätzlich mit dem QlikView Developer entwickelt. Dieses Deployment trifft auf  viele Testserver bei unseren Kunden zu!

Abhilfe kann ein Easteregg schaffen, das in der settings.ini des QlikView Servers gesetzt werden kann.


Das Setting löscht um Mitternacht den Cache des QlikView Server Services. Das bedeutet:

•  Memory das von den Daten der .qvws belegt wird, bleibt belegt
• Alle  gecachten Berechnungen werden gelöscht, und der QlikView Server gibt diesen Teil des Memorys wieder an das Betriebssystem frei.

Das Interessante an diesem Setting: man kann definieren wie oft der Cache geleert werden soll. Immer ausgehend von Mitternacht ergibt sich somit:

ClearCacheTimesPerDay=1	Einmal am Tag um Mitternacht 00:00
ClearCacheTimesPerDay=2	00:00 und 12:00
ClearCacheTimesPerDay=3	00:00 08:00 16:00
...	usw.
ClearCacheTimesPerDay=24	jede Stunde

Die Teststellung

Wir haben ClearCacheTimesPerDay=24 auf einer Teststellung bei uns überprüft.Und tatsächlich - zu jeder vollen Stunde wurde wieder das Memory des Caches freigegeben! Unterhalb unsere Vorgehensweise.

Server

Wir haben auf einem Win2016 Server mit 8GB RAM getestet. Das Workingset des Serves ist auf  50% beschränkt, damit sollte der QlikView Server Prozess bis maximal 4GB Daten cachen.

Workingset des QlikView Server Service auf 50% = 4GB

Das Testscript

Die .qvw für den Test ist recht simple. Das Script lautet:

load
  'A'&rowno() as row,
  rand() as value
autogenerate(1000000)

Im Layout gibt es eine einfache Tabelle. Wenn man einige Werte auswählt und dann Rechtsklick "Select excluded" wählt, füllt man mit jeder neuen Selektion den Server-Cache mit einigen Dutzend Megabytes.

Viele distinkte Daten füllen den Cache ganz gut!

Konfiguration & Test

1. QlikView Server Service stoppen. Settings.ini ändern, Service starten
   
2. Bis 09:43 haben wir den Cache des Servers durch "Klicken" in unserer Testapplikation  auf  2 Gigabyte hochgetrieben
   
3. Um 10:00 sieht man im Performance Monitor eine steile Flanke nach oben. Memory wird also freigegeben!  Die Größe des QlikView Server Prozesses ist im Taskmanager auf 192 Megabyte gefallen! Das Setting hat also 1,98 GB Cache geleert! Die restlichen 192 MB sind die Daten in unserer Testapplikation plus ein wenig Overhead des QlikView Server Prozesses.
   
4. Gleiches Spiel bis 10:40, nur dass wir mehr Zeilen im autogenerate()-Script der .qvw generiert haben  (ca 900 MB Daten im Memory). Damit füllt sich mehr Cache mit weniger Klick ;-)
   
   Diesmal haben wir den Cache bis an das Maximum von 4 Gigabytes hochgetrieben (wegen des definierten Workingset Low 50% von 8GB geht auch nicht mehr).
   
   
5. Um 11:00 dann wieder der Drop auf 900 MB
   
   

Conclusio

Das Setting ClearCacheTimesPerDay funktioniert, und ist eleganter als ein net stop/start des QlikViewServer Services (bei dem alle Online-User aus ihrer QlikView Session fliegen). Für den Testserver kann es also sehr nützlich sein. Für den Produktiven Server ist es nicht zu empfehlen - da muss man schon ein sinnvolles HardwareSizing durchführen (gerne auch mit uns!).