QlikView Server - Das Gerücht vom Memoryleak und wie man den Cache zurücksetzt
Ü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:
Das Interessante an diesem Setting: man kann definieren wie oft der Cache geleert werden soll. Immer ausgehend von Mitternacht ergibt sich somit:
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.
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.
ClearCacheTimesPerDay=1
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
- QlikView Server Service stoppen. Settings.ini ändern, Service starten
- Bis 09:43 haben wir den Cache des Servers durch "Klicken" in unserer Testapplikation auf 2 Gigabyte hochgetrieben
- 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.
- 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).
- Um 11:00 dann wieder der Drop auf 900 MB
0 Response to "QlikView Server - Das Gerücht vom Memoryleak und wie man den Cache zurücksetzt"
Kommentar posten