PRTG Sensor Performance
Sie haben sicher schon gesehen, dass es im Bereich PRTG jede Menge eigene Sensoren für PRTG von mir gibt. Die meisten davon sind aber PowerShell-Skripte, die von PRTG als 32bit PowerShell gestartet werden. PRTG kann aber auch VBScript und EXE-Programme starten. Je mehr diese Sensoren dann auf den Probes laufen und diese in engeren Abständen gestartet werden, desto eher muss dann doch mal die Performance berücksichtigt werden.
Sie können in PRTG für jeden Sensor einen "Timeout" anlegen, d.h. nach welcher Zeit da Ergebnis anstehen muss. Ansonsten wir das Script als "Failed" angezeigt.
Beispielsensor
Ich habe die Performance-Betrachtung in Verbindung mit dem Sensor PRTG FileRead angestellt. Dieser Sensor hat die Aufgabe, eine Datei von einem UNC-Pfad einfach möglichst schnell zu lesen. Diese Aufgabe kann sehr schnell in PowerShell, VBScript und mit Visual Studio auch als EXE-Programm erstellt werden.
Aber selbst da muss man aufpassen, wie man auf den Beispielen auf PS Performance sieht. Die "Laufzeit" des Skript kann durchaus von der Implementierung abhängen. Hüten Sie sich z.B. die Ausgabe mit einem "| out-null" zu verwerfen. Das Dauert viel länger als die Zuweisung an eine Variable, die mit dem Skriptende einfach frei gegeben wird.
PRTG FileRead PowerShell # Simple Custom Sensor to measure ReadFile- Throughout # # Execution Policy must be able to run 32bit PS1-Scripts # Set-ExecutionPolicy -ExecutionPolicy remotesigned # # Sending Output to "out-File" is much slower ! param ( [string]$filename ) $time = Measure-Command { $a= [system.IO.File]::ReadAllBytes($filename) } write-host (([int]$time.totalmilliseconds).tostring() + ":OK")
Bei der VBScript-Version musste ich mit der Zeitmessung tricksen, da die Funktion "NOW" nur einen Datum/Zeit-Wert mit einer Sekunde Auflösung liefert. Das ist nicht ausreichend für eine Zeitmessung, so dass ich mit der Funktion "Timer" arbeiten muss, die aber nur vergangene Sekunden/Millisekunden seit Mitternacht liefert. für eine Messung reicht es aber aus.
const forreading = 1 set objFSO = CreateObject("Scripting.FileSystemObject") set objTextFile = objFSO.OpenTextFile (WScript.Arguments(0),ForReading) dtmstart = timer strtext = objTextFile.ReadAll dauer = timer -dtmstart if dauer < 0 then dauer = dauer + 86400 end if wscript.echo int(dauer*1000) & ":OK" objTextFile.close
Und weil es so schnell geht, habe ich gleich noch eine EXE mit Visual Studio gebaut
Alle drei Skripte lesen einfach die angegeben Datei und verwerfen die Daten. Sie eignen sich daher in Grenzen für eine regelmäßige Messung eines Dateiservers in Stichproben.
Performance
Ich habe dann pro Variante jeweils einen Sensor angelegt und immer nur einen aufrufen lassen. Leider ist mein PRTG-System nie ganz "Idle", so dass ich nicht wirklich die CPU-Last für einen einzelnen Sensor ermitteln kann. Aber dafür habe ich die "ExecutionTime", die PRTG für die Ausführung des Sensors erfasst und die gemessene Zeit für die Aktion. Hier nehme ich mal an, dass PRTG die Zeit vor dem Aufruf der LaufzeitUmgebung bis zur Rückgabe der Ergebnisse nach dem Ende des Programms misst. Das ganze habe ich über viele Aufrufe gemittelt.
Version | Host | 290kByte Testdatei | 150MB Testdatei | 650MB Testdatei | Instanzzeit | |||
---|---|---|---|---|---|---|---|---|
Executiontime | Sensorwert | Executiontime | Sensorwert | Executiontime | Sensorwert | gemittelt | ||
prtg-fileread.ps1 |
conhost.exe |
1500 ms |
26 ms |
1578ms |
131 ms |
nicht getestet |
2949/550 |
14800-1550 ms |
prtg-fileread.vbs |
cscript.exe |
66 ms |
15 ms |
11585 ms |
11507 ms |
nicht getestet |
40769/27863 |
50-80 ms |
prtg-fileread.exe |
|
51 ms |
15 ms |
187ms |
109 ms |
nicht getestet |
2949/452 |
35-90ms |
Achtung: Da Dateiserver einen "Cache" nutzen, wir bei größeren Dateien der zweite Aufruf immer schneller sein. Wenn der Sensor mit längerem Abstand gestartet wird, kann der Cache nicht mehr wirken. Bei größeren Dateien dürfte auch das Speicher der Daten in einer Variable abhängig vom internen Speichermanagement der LaufzeitUmgebung sein. Solche "Fehler" verwässern natürlich die Messwerte. Wer also z.B. den maximalen Durchsatz müssen will, sollte sicher sein, dass nicht das Skript selbst der limitierende Faktor ist.
Achten Sie auch auf
Speichergrenzen. 650 Megabyte mit dem oben
aufgeführten Code zu lesen, kann auch mal zu
einem Fehler führen:
Noch nicht analysiert habe ich natürlich den Einfluss jeder Version auf die Systemleistung. Es kann ja gut sein, dass eine EXE so viel schneller ist, weil sie z.B. einfach mehr CPU-Last in Anspruch nimmt. Subtrahiert man den Sensorwert von der Ausführungszeit, hat man aber etwas eine Größenordnung für die Instanzierung der SensorUmgebung.
- PowerShell liest größere
Dateien schneller als VBScript
Vermutlich nutzt VBScript eine andere Codebase, die aber bei kleineren Dateien schneller ist. - PowerShell Instanzierung
braucht auf meinem Computer ca.
1,5Sek
Ziehen sie von der Executiontime den Sensorweg ab, da dieser die innere Laufzeit ist. Die 1,5 Sekunden können auf einem schnelleren System natürlich auch schneller sein - Kompilierte EXE ist am
schnellsten.
Selbst wenn es ein in Visual Basic geschriebenes Programm für .NET4-Framework ist und kein C++-Code, ist das Ergebnis beeindruckend. Sowohl die Leseperformance ist in am schnellsten aber vor allem dauert das Instanzieren immer deutlich kürzer. - VBScript ist ein Kompromiss, da die LaufzeitUmgebung schneller als PowerShell gestartet wird. Aber man muss auf die Performance des eigentlichen Codes achten.
Wie Sie sehen können, gibt es schon einige unterschiede bei den verschiedenen Sensoren und ihren Auswirkungen auf das System.
Auch wenn PowerShell vielleicht nicht so gut abschneidet, so ist es für viele Dinge für eine Adhoc-Entwicklung die beste Wahl. Insbesondere wenn eine Remote-PowerShell zu Office 365, Exchange oder Lync aufgebaut werden soll oder andere Funktionen schnell entwickelt werden sollen.
Allerdings muss man auch überlegen, dass sehr oft eingesetzte Sensoren vielleicht besser doch als EXE-Programm entwickelt werden. Es ist übrigens auch sehr einfach, mit einem Editor C#-Code zu schreiben und mit dem Kommandozeilenkompiler des .NET-Frameworks mal schnell zu kompilieren:
- Command-line Building With
csc.exe
https://msdn.microsoft.com/en-us/library/78f4aasd.aspx - Compiling a C# Project using
Command Line Tools (Example)
http://www.tomasvera.com/programming/compiling-a-c-project-using-command-line-tools-tutorial/
Ich habe schon oft gehofft, es könnte man ein PowerShell Compiler geben aber letztlich ist PowerShell eine Scriptsprache und wenn es etwas umfangreicher wird, dann darf es eben doch C# o.ä. werden.
Timeout
Ein zweiter Faktor bei der Systembelastung ist der Timeout, der beim Sensor mit definiert wird. Per Default sind hier 60 Sekunden hinterlegt.
Wie die Hilfe treffend beschreibt, wird der Prozess nach der angegeben Zeit von PRTG terminiert und der Aufruf als "Fehler" gewertet.
Der Wert ist in mehrerer Hinsicht interessant:
- Anpassen für Langläufer
Wenn Sie Sensoren einsetzen, die lange laufen, dann muss der Wert erhöht werden, damit das Skript auch fertig werden kann. Das ist z.B. der Fall, wenn Sie per Exchange PowerShell in größeren Umgebungen entsprechende Daten einsammeln. (Siehe auch PRTG:ExMetric u.a.). Am besten starten Sie den Sensor manuell und ermitteln die Laufzeit um dann diesen Parameter etwas höher anzusetzen. So sollte der Sensor korrekt Daten erfassen und im Fehlerfall auch zuverlässig dies melden. - Anpassen für Kurzläufer
Denkbar ist aber auch die Reduzierung des Timeout. Wenn ein Sensor einige Zeit gelaufen ist, können Sie die "ExecutionTime" als Kriterium wählen. So können Sie eine Verschlechterung der Laufzeit frühzeitig erkennen. Das wird in größeren Installationen ein Thema, wenn Sensoren plötzlich länger laufen und das PRTG-System damit verlangsamen. Ich habe noch keinen eingebauten Sensor gesehen, der z.B. die Laufzeit aller Sensoren pro Probe und Stunde addiert, um so ein Maß für die Aktivität zu bekommen. Das könnte man aber aus PRTG selbst auslesen. - Optimierung von
Langlaufsensoren
Interessant können aber auch Sensoren für ein End2End-Monitoring sein, die nicht möglich schnell etwas auslesen, sondern möglichst langsam und gleichmäßig müssen. Diese Sensoren laufen dann "länger" aber müssen natürlich rechtzeitig zum Ende kommen, damit PRTG die Rückgabe noch auswertet und dann den Sensor erneut startet. Vor Vorteil ist hier natürlich, wenn das Skript selbst seine eigene Laufzeit überwacht um rechtzeitig sich zu beenden.
Der Timeout ist ein effektives Hilfsmittel, um "hängende Sensoren", die vielleicht noch eine hohe Last verursachen, beenden zu lassen. So vermeiden Sie kostbare Rechenleistung, Verzögerungen anderer Sensoren und erkennen problematische Skripte. Zumindest wenn Sie die Laufzeit der Sensoren etwas im Auge behalten.
Soweit ich gesehen habe, hat PRTG (Stand Juli2015) kein Frühwarnsystem, wenn die Execution-Time eines Sensors deutlich vom vorherigen Mittelwert abweicht ohne gleich den Timeout zu reissen. Das könnte ich mir schon als interessanten Frühwarnindikator vorstellen.
Throttling
In PRTG kann man so viele Sensoren einrichten, wie die Lizenz hergibt und jeder Sensor kann ja ein lastintensives Skript oder Programm sein. Im Extremfall würden dann 100 PowerShell-Skripte o.ä. nebeneinander laufen?
Ich habe daher das PowerShell-Script einfach mal mit einem "Start-Sleep" zum pausieren gebracht und den Sensor gecloned. selbst nach 26 parallel laufenden Sensoren konnte ich weitere starten. Bei einer Recherche habe ich leider nur eine Aussage zu PRTG 5 und 6 gefunden.
As of version 6.0.6.x, PRTG has
an internal limit of 300 concurrently busy
sensors (previous V6 verisons had a limit of
100, whereas there was no defined limit for V5
versions). Under normal usage the busy sensors
value should always be much smaller on your
system.
The busy sensors value should be below 150 für normal use. Values above 250 are critical
because this means that not all sensors can be
monitored within the desired intervals. If the
value 300 is reached all pending sensors are
halted until one of the 300 busy sensors is
finished, then one of the halted sensors is
executed.
Quelle: Details about the meaning of the "Busy
Sensors" value in PRTG Traffic Grapher
https://www.paessler.com/support/kb/questions/152
Wenn wir auch für die aktuelle Version von 300 parallel aktiven Sensoren ausgehen, dann sollten Sie in größeren Umgebungen die Intervalle der einzelnen Sensoren, insbesondere der "Langläufer" entsprechend vergrößern oder die Last auf mehrere Probes verteilen.
Für mich bedeutet dies aber, dass "Langlaufsensoren" am besten auf dem Host selbst ausgeführt werden und PRTG nur die Ergebnisse abholt.
- Details about the meaning of
the "Busy Sensors" value in PRTG
Traffic Grapher
https://www.paessler.com/blog/2007/01/09/all-about-prtg/details-about-the-meaning-of-the-busy-sensors-value-in-prtg-traffic-grapher
Weitere Links
- PRTG
- PRTG:weitere Proben
- PRTG:Custom Sensor
- PRTG FileRead
- End2End
- PS Beispiele
- PS Performance
- Visual Studio
-
How can I speed up PRTG—especially für large installations?
http://kb.paessler.com/en/topic/2733-how-can-i-speed-up-prtgespecially-for-large-installations -
The ultimate guide to boosting your PRTG performance
https://blog.paessler.com/the-ultimate-guide-to-boosting-your-prtg-performance