Wenn PRTG ins Schwitzen kommt: Arbeitsspeicher-Engpass auf dem Monitoring-Server

Ausgangslage

PRTG läuft bei mir als Windows Server 2025 VM und übernimmt einen grossen Teil der Überwachung im Homelab – Geräteverfügbarkeit, Ressourcenauslastung, diverse WMI-Sensoren auf verschiedenen Hosts. Die VM war seit der Einrichtung mit 4 GiB RAM ausgestattet, ein Wert, der bisher nie Probleme gemacht hat. Bis er es plötzlich tat.

Problem

Zwei Sensoren schlugen praktisch gleichzeitig Alarm. Der Sensor „Zustand der Probe“ meldete eine WMI-Intervallverzögerung von 1000 Prozent – die Warteschlange der WMI-Abfragen lief also komplett voll und die Sensoren konnten längst nicht mehr in ihrem eingestellten Intervall abgefragt werden. Kurz darauf folgte ein zweiter Fehler auf dem „Datenträger-Speicher“-Sensor mit dem Code PE015, dem klassischen Verbindungsfehler.

Auf den ersten Blick liessen sich die beiden Meldungen unabhängig voneinander erklären: zu viele WMI-Sensoren, ein überlasteter Zielserver, ein Netzwerkproblem. Der Blick in den Task-Manager der PRTG-VM brachte dann aber schnell Klarheit. Die CPU-Auslastung lag bei entspannten 8.87 Prozent, praktisch im Leerlauf. Der Arbeitsspeicher hingegen war zu 100 Prozent ausgereizt – 4.00 von 4.00 GiB restlos belegt.

Damit ergab sich ein stimmiges Bild: Mit vollständig ausgeschöpftem RAM gerät ein System unter Druck, Prozesse werden ausgebremst, Abfragen bleiben hängen. Die WMI-Warteschlange lief voll, weil schlicht kein Speicher mehr da war, um sie zeitnah abzuarbeiten. Und wenn einzelne Abfragen dann komplett ins Leere liefen, weil der Dienst nicht mehr rechtzeitig antworten konnte, kam der PE015-Fehler obendrauf. Zwei Symptome, eine Ursache.

Auflösung

Die naheliegende Sofortmassnahme war, der VM mehr Arbeitsspeicher zu geben. In Proxmox liess sich das unkompliziert erledigen: RAM-Zuweisung auf 5 GiB erhöht (1024 × 5 MB) und die VM neu gestartet.

Nach dem Neustart zeigte der Windows-Ressourcenmonitor ein deutlich entspannteres Bild – rund 2.2 GiB in Verwendung bei 2.7 GiB frei. Das allein sagt aber noch nicht viel, denn direkt nach einem Reboot ist ein System naturgemäss „kalt“: PRTG hat die Sensoren noch nicht wieder im vollen Intervall durchlaufen, Caches sind leer, der eigentliche Bedarf unter Last zeigt sich erst nach einiger Zeit im Normalbetrieb.

Ein Blick in die Prozessliste brachte dann eine überraschende Erkenntnis. Die PRTG-eigenen Prozesse – PRTG Server und PRTG Probe zusammen – belegten zu diesem Zeitpunkt gerade einmal rund 380 MB. Ein Bruchteil der 2.2 GiB Gesamtverbrauch. Der grössere Teil des Speicherbedarfs stammte also gar nicht von PRTG selbst, sondern vom übrigen Windows-Unterbau: Systemdienste, Caching, allgemeiner Betriebssystem-Overhead.

Das relativiert die erste Einschätzung etwas. Ob tatsächlich PRTG unter Volllast der Treiber für den Engpass war, oder ob die VM grundsätzlich zu knapp für einen vollwertigen Windows Server 2025 dimensioniert war, lässt sich erst beurteilen, wenn die Probe wieder unter normaler Last läuft – also alle WMI-Sensoren wieder im regulären Intervall abgefragt werden. Steigen dann auch die PRTG-Prozesse deutlich an, war PRTG selbst der Treiber. Bleiben sie klein und der Gesamtverbrauch klettert trotzdem wieder Richtung 100 Prozent, ist eher der Windows-Unterbau grundsätzlich zu knapp bemessen.

Lessons Learned

• Bei WMI-bezogenen PRTG-Fehlern (Intervallverzögerung, PE015) lohnt sich zuerst ein Blick auf die Ressourcen der Probe selbst, bevor man auf Netzwerk- oder Zielserver-Probleme tippt. CPU und RAM getrennt betrachten, nicht nur die Gesamtlast.
• Arbeitsspeicher, der zu 100 Prozent ausgeschöpft ist, kann Symptome erzeugen, die auf den ersten Blick wie unabhängige Fehler aussehen – hier eine Verzögerungswarnung und ein Verbindungsfehler auf zwei unterschiedlichen Sensoren.
• Ein Blick direkt nach einem Neustart zeigt nie den tatsächlichen Bedarf unter Last. Erst die Beobachtung über mehrere Stunden oder Tage im Normalbetrieb zeigt, ob eine Speichererhöhung wirklich ausreicht.
• Die Prozessliste lohnt einen zweiten Blick: Nicht jeder hohe Speicherverbrauch stammt vom Dienst, den man gerade untersucht. Bei PRTG war der eigentliche Fussabdruck des Monitoring-Dienstes überraschend klein – der Rest ging auf das Konto von Windows selbst.

Fazit

4 GiB RAM waren für die PRTG-VM offenbar too tight bemessen, allerdings nicht unbedingt wegen PRTG selbst, sondern möglicherweise wegen des Windows-Server-Unterbaus insgesamt. Die Erhöhung auf 5 GiB hat den akuten Engpass behoben, ob das mittelfristig reicht, zeigt sich erst nach ein paar Tagen Beobachtung unter echter Last. Sollte die Auslastung wieder Richtung 100 Prozent klettern, ist der nächste Schritt eine grosszügigere Aufstockung auf 6 bis 8 GiB, statt in kleinen Schritten nachzubessern. Manchmal ist die einfachste Diagnose – ein voller Task-Manager – eben doch die richtige.