Häufig wird bei Hardware Sizing nur über das Qlik Server Service gesprochen. Die harte Arbeit der Datenaufbereitung übernimmt in der Nacht jedoch das Publisher Modul. Viele kleinere bis mittlere Qlik Installationen nutzen für diese (nächtliche) Beladung die gleiche Maschine. Das geht oft gut, doch kämpfen Server und Publisher dann häufig um die gleichen Memory- und CPU-Ressourcen, was über die Zeit bei wachsenden Datenmengen zu unerwünschten Verhalten führt. Um die notwendigen Ressourcen für den Publisher besser monitoren zu können, installiert Qlik - gut versteckt - einige Indikatoren in Microsoft Perfmon.
Das QlikView Server Service ist sehr aggressiv in seiner Memory-Consumption. Ähnlich eines Datenbankservers reserviert es Memory (WorkingSet) vor, da es annimmt, das wichtigste Service am ganzen System zu sein. Auch in der Nacht hält das QlikView Server Service sein Memory (vor allem wenn es das untere Workingset schon einmal erreicht hat), was dazu führt, dass für die Reloads nur wenig freier Speicher zur Verfügung steht. Laufen dann noch mehrere Reloads gleichzeitig, kann es mit Memory auf einer einzelnen Maschine schnell knapp werden.
Für QMC-Administratoren ist es oft schwierig zu sagen, wann wieviel Tasks gleichzeit laufen und wieviel Last vom Publisher (bzw den qvb.exe des Distribution Services) dabei produziert wird. Seit QlikView 11.20 SR7 kann man sich zwar in jedem TaskLog eine Summary zeigen lassen, das gibt aber kein vollständiges Bild wie sich die Beladungen über einen vollen Nacht-Zyklus inklusive aller Abhängigkeiten verhält.
Um zu verstehen was nächtens bei den Reloads am Server so passiert, gibt es ein gut verstecktes Feature: Das QlikView Distribution Service registriert einige Performance Counter Indikatoren in Microsoft's PerfMon Tool das in jeder Windows Version zur Verfügung steht.
Nicht alle Indikatoren sind ganz verständlich (und werden wohl nur vom Qlik Support genutzt), aber um sich einen Überblick zu verschaffen, benutze ich gerne
Die nächsten Sceenhshots zeigen ein Beispiel wie Perfmon den Verlauf über die Zeit mitprotokolliert.
![]()
Die hellgrüne Linie zeigt die 4 gerade laufenden Tasks der QMC. Die Dunkelgrüne zeigt die Summe der verbrauchte CPU Zeit dieser Tasks (in Summe vier qvb.exe, in Screenshot sieht man nur eine qvb.exe im Taskmanager, da alle anderen gerade keine CPU verbrauchen). Rot+Blau gestrichelt zeigen den Zustand des gesamten Servers. Die gelbe Linie "Current QVB memory usage" kann ich in absoluten Zahlen nicht deuten, ist aber eine interessante Information um ressourcenfressende Skripte zu entdecken.
Werden die Reloads nach der Reihe fertig abgearbeitet, fallen auch die zwei grünen Linien entsprechend. Siehe unterhalb Screenshot mit nur noch einem laufenden Reloadtask.
![]()
Bei größeren Installationen - oder falls Sie viele untertägige Reloads fahren - empfehlen wir immer das Aufteilen der zwei Services "QlikView Server Service" und "QlikView Distribution Service (aka Publisher)". Im Zeitalter der Virtualisierung und noch immer fallender Memory-Preise ist ein Deployment mit zwei Maschinen vorzuziehen. Beide Services können die vollen Ressourcen Ihrer Maschine nutzen, und kommen sich auch unter hoher Last nicht in die Quere.
Wo das ManagementService und der Webserver läuft, ist zu vernachlässigen. Manchmal setzt man dafür auch eine dritte Maschine ein.
Das QlikView Server Service ist sehr aggressiv in seiner Memory-Consumption. Ähnlich eines Datenbankservers reserviert es Memory (WorkingSet) vor, da es annimmt, das wichtigste Service am ganzen System zu sein. Auch in der Nacht hält das QlikView Server Service sein Memory (vor allem wenn es das untere Workingset schon einmal erreicht hat), was dazu führt, dass für die Reloads nur wenig freier Speicher zur Verfügung steht. Laufen dann noch mehrere Reloads gleichzeitig, kann es mit Memory auf einer einzelnen Maschine schnell knapp werden.
Für QMC-Administratoren ist es oft schwierig zu sagen, wann wieviel Tasks gleichzeit laufen und wieviel Last vom Publisher (bzw den qvb.exe des Distribution Services) dabei produziert wird. Seit QlikView 11.20 SR7 kann man sich zwar in jedem TaskLog eine Summary zeigen lassen, das gibt aber kein vollständiges Bild wie sich die Beladungen über einen vollen Nacht-Zyklus inklusive aller Abhängigkeiten verhält.
Um zu verstehen was nächtens bei den Reloads am Server so passiert, gibt es ein gut verstecktes Feature: Das QlikView Distribution Service registriert einige Performance Counter Indikatoren in Microsoft's PerfMon Tool das in jeder Windows Version zur Verfügung steht.
 |
| PerfMon - Performance Counter Indikatoren vom QlikView Distribution Service |
Nicht alle Indikatoren sind ganz verständlich (und werden wohl nur vom Qlik Support genutzt), aber um sich einen Überblick zu verschaffen, benutze ich gerne
- # of running tasks .. wieviele Tasks (qvb.exe) laufen gerade
- Current QVB CPU Load .. CPU Zeit die von den Reload Tasks verbraucht wird.
- Current QVB memory Usage .. den absoluten Wert kann ich nicht ganz nachvollziehen, aber er zeigt Arbeitsspeicher-Ausreißer bei großen JOINs usw.
Die nächsten Sceenhshots zeigen ein Beispiel wie Perfmon den Verlauf über die Zeit mitprotokolliert.
Die hellgrüne Linie zeigt die 4 gerade laufenden Tasks der QMC. Die Dunkelgrüne zeigt die Summe der verbrauchte CPU Zeit dieser Tasks (in Summe vier qvb.exe, in Screenshot sieht man nur eine qvb.exe im Taskmanager, da alle anderen gerade keine CPU verbrauchen). Rot+Blau gestrichelt zeigen den Zustand des gesamten Servers. Die gelbe Linie "Current QVB memory usage" kann ich in absoluten Zahlen nicht deuten, ist aber eine interessante Information um ressourcenfressende Skripte zu entdecken.
Werden die Reloads nach der Reihe fertig abgearbeitet, fallen auch die zwei grünen Linien entsprechend. Siehe unterhalb Screenshot mit nur noch einem laufenden Reloadtask.
Bei größeren Installationen - oder falls Sie viele untertägige Reloads fahren - empfehlen wir immer das Aufteilen der zwei Services "QlikView Server Service" und "QlikView Distribution Service (aka Publisher)". Im Zeitalter der Virtualisierung und noch immer fallender Memory-Preise ist ein Deployment mit zwei Maschinen vorzuziehen. Beide Services können die vollen Ressourcen Ihrer Maschine nutzen, und kommen sich auch unter hoher Last nicht in die Quere.
 |
| Ein exemplarisches Deployment auf zwei Maschinen für "PRODUKTIV" |
Wo das ManagementService und der Webserver läuft, ist zu vernachlässigen. Manchmal setzt man dafür auch eine dritte Maschine ein.