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:

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.

Weitere Links