Hoher RAM Verbrauch ioBroker unter Windows

[Feuersturm]

Das Speicher wieder freigegeben wird konnte ich leider bisher nicht beobachten. Das ist die Grafik von gestern wo über den Info Adapter alle 10s die Daten für RAM und CPU aktualisiert wurden:

Ich hab auch schon eine neue ioBroker Instanz aufgesetzt, welche nur die vorinstallierten Adapter enthielt und dort hatte ich das gleiche Verhalten.
Wenn ich in den nächsten Tagen keine wirkliche Lösung finde werde ich zum großen Hammer greifen und einmal Windows neu installieren.

[klassisch]

@Feuersturm sagte in Hoher RAM Verbrauch ioBroker unter Windows:

wo über den Info Adapter alle 10s die Daten für RAM und CPU aktualisiert wurden

Wo kannst Du die 10 Sekunden einstellen? Das habe ich noch nicht gefunden und meiner aktualisiert jede Sekunde. Meiner Meinung nach würde auch ein Datensatz pro Minute für solche Trenduntersuchungen reichen.

[Feuersturm]

Gehe bei den Instanzen auf die Instanz info.0 und klicke dort auf den Werkzeugschlüssel. Dann scrollst du ganz nach unten und dort kannst du über die Schieberegler die Aktualisierungsrate einstellen.

[klassisch]

Gibts bei mir nicht. Sieht so aus

Version 1.3.7

[Feuersturm]

Hmm, ich hab auch die Adapterversion 1.3.7 installiert. Bei mir sieht es so aus:

[klassisch]

Vielen Dank! Habe jetzt in der Adapteransicht den Upload Button gedrückt und dann siehts bei mir auch so aus. Aber leider ist das max Zeitintervall bei 10 Sekunden.
Temperaturen sehe ich noch immer nicht.

[klassisch]

Habe jetzt mal das Logging der Prozessorlast aktiviert. Für die Gesamtlast speichere ich Änderungen >=3 W auf und für system- und userload jeweils Änderungen >=2W auf. Weiß jemand, ob mit userload die ioBroker generierte Last gemeint ist?

[Feuersturm]

Ich habe vor kurzem erst von 8Gbyte RAM auf 16 GByte RAM aufgerüstet. Heute kam mir der Gedanke, ob ggf. der neue RAM Baustein Probleme macht. Ich habe jetzt erstmal den neuen RAM Baustein entfernt und werde mal die nächsten 24h das System beobachten. Vielleicht ist es ja nur ein Hardwaredefekt

[klassisch]

Da könnte vielleicht ein RAM-Test helfen.
Edit: Vielleicht hilft das: https://tuhlteim.de/ultimate-boot-cd-ubcd-download-usb-stick-cd-laptop-testen

Ich beobachte derweil weiter:

[Stabilostick]

Bitte haltet mich auf Windows bezgl. RAM und CPU-Verbrauch von wmiprvse.exe und vor allem bzgl. der Anzahl von WMIC.EXE-Prozessen auf dem Laufenden.

Testet bitte auch, was mit dem CPU und RAM-Verlauf passiert wenn der Info-Adapter deaktiviert oder die Intervallrate für alle Counter im Info-Adapter auf 0 steht.

Danke.

[klassisch]

Ich kann die obigen Plots gerne weiterführen und ggf ergänzen.
Nutze dazu den Info-Adapter, der dann aber auch läuft. Habe die Abtastzeiten auf max = 10 Sekunden gestellt und logge nur bei signifikaten Änderungen. So bleibt Prozessorlast und Datenaufkommen angemessen.
Zu WMI* habe ich im Task Manager nur WMI Providerhost (0 bis 3%) und ein ab und an aufblitzendes WMI Befehlszeilendienstprogramm gesehen.
Brauche ich ein anderes Logging-Tool?

[Stabilostick]

@klassisch

Wenn es sich so verhält, ist alles ok. Dann brauchst Du nicht weiter forschen.

Ich hatte bei mir in der Vergangenheit mehrfach Fälle, wo wmic.exe-Prozesse sich nicht mehr beendet haben und auch entsprechende consolehost.exe-Prozesse stehen geblieben sind. Dann war nach einiger Zeit der Rechner extrem langsam. Aber dafür scheint es Auslöser zu geben. Z.B. defekte Hardware, Treiberprobleme, RAM-Fragmentierung, ...

Ich habe die Vermutung, dass der Infoadapter aufgrund der relativ hohen Frequenz von WMI-Abfragen (ca. knapp 200 Events alle 15s) da selbst auf betroffenen Systemen Auslöser sein kann.

Mal sehen.

[klassisch]

@Stabilostick Ja, finde die Abfragefrequenz für eine normale Routineüberwachung auch etwas paranoid. Aus meiner Sicht reicht etwas im Minutenbereich für die Routineüberwachung aus. Wenn etwas richtig - also länger andauernd - schief geht, dann merkt man das auch noch bei etwas trägerer Aufzeichnung. Für die Suche von kurzzeitigen Spikes o.ä. mag die schnellere Abfrage und Aufzeichnung ihre Berechtigung haben. Aber das sind Spezialfälle.
Das viele Loggen vom info und vom systeminfo-Adapter waren wohl auch die Ursache für die überlastinduzierten Instabilitäten bei meinem OPi.
Mein i5 wird jetzt wohl nicht so schnell in die Knie gehen. Aber wenn jemand einen NUC mit Atom hat und noch eine ordentliche Grundlast durch andere Win-Anwendungen, dann könnte das auch schon mal zu Problemen kommen.

[Feuersturm]

@Stabilostick sagte in Hoher RAM Verbrauch ioBroker unter Windows:

Bitte haltet mich auf Windows bezgl. RAM und CPU-Verbrauch von wmiprvse.exe und vor allem bzgl. der Anzahl von WMIC.EXE-Prozessen auf dem Laufenden.
Danke.

@Stabilostick Ich hatte seit gestern abend nur noch meinen 8 GByte RAM Riegel im Server, welcher dort schon seit längerer Zeit ohne Probleme werkelt. Innerhalb von etwas mehr als 12 Stunden war der komplette RAM belegt und die CPU wieder im Grenzbereich von 80 bis 100%.
Ich versuche gerade auf den Server zu kommen, es sieht aber nicht gut aus. Bei den ganzen letzten Malen hat wmiprvse.exe ca. 30% an CPU Last verbraucht. Das ganze System reagiert gerade so schwerfällig, dass es schwer ist die genaue Anzahl zu zählen. Bei 50 WMIC.exe hab ich jetzt mal aufgefhört zu zählen.

Ich werde heute abend mal ein paar Tests über meine RAM Bausteine laufen lassen.
Was könnte denn die Ursache dafür sein, dass es so viele WMIC Prozesse sind. Es scheint ja nicht normal zu sein.

[klassisch]

Wenn ich @Stabilostick richtig verstanden habe, wäre es interessant, den Info Adapter zu deaktivieren und dann neu zu starten. Prüfen, ob der Info Adapter immer noch aus ist und von Zeit zu Zeit den Rechner manuell prüfen.
Du kannst die Prozessorlast auch indirekt remote prüfen. CoreTemp prüft die Temp und speichert das in ein Log. Ich lasse alle 5 Sekunden die Temp messen und alle 30 Sekunden in ein csv file schreiben. Diese Datei hole ich mir dann über Dateizugriff und schaue sie mit mit libreoffice auf meinem Office-Rechner an. So muß nicht so oft remote verbinden, was ja extra Last erzeugt und die Messung verfälscht. Und es geht recht stabil und ressourenschonend.

[Feuersturm]

@klassisch Das werde ich machen, wenn die RAM Tests durch sind.

[klassisch]

So sieht es mittlerweile bei mir aus:

Die Garbage Collection scheint bei Bedrf stattzufinden. War heute mit UltraVNC drauf, hab etwas nachgeschaut und Defender aktualisiert. Das hat wieder etwas Last erzeugt und er hat dann Speicher freigeräumt.
Alles läuft normal, keine WMI* Auffälligkeiten.
Meine rechenzeitdominante Parallelapplikation braucht am Teg mehr Rechenleistung als nachts, was man bei der Prozessorauslastung auch schön sieht.
Bei meinen Einstellungen bringen die Prozessolastdaten ca. 550kByte/Tag und die Memory-Daten ca. 120kByte / Tag bei.
Werde die Prozessordaten durch Erhöhen der Aufzeichnungsdeltas noch etwas ausdünnen.

[Feuersturm]

Meine Speichertests mit dem Tool memtest86 sind durchgelaufen.
Test-1
Ich hab einmal meinen alten 8 GByte Riegel drin gehabt, wo der Test keine Fehler festgestellt hat
Mit diesem 8 GByte Riegel hat sich das System so verhalten wie ich es im Beitrag vom 18. Aug. 2019, 19:14 beschrieben habe.

Test-2
Ich hab die beiden identischen 8 GByte Riegel eingebaut und memtest86 lief wieder ohne Fehlermeldungen durch. Das Verhalten mit diesen beiden Riegeln hatte ich am 16. Aug. 2019, 23:08 beschrieben.

Wenn ich nur den neuen 8 GByte RAM Riegel in den Server einsetze startet Windows gar nicht erst Komischerweise stehen mir die 15,6 GByte RAM zur Verfügung, wenn beide Riegel verbaut sind.
Eine logische Erklärung habe ich dafür nicht.
Angenommen der neue Riegel hat eine Macke, dann hab ich trotzdem Probleme mit meinem System, wenn der alte 8 GByte RAM Riegel verbaut ist.

Im nächsten Schritt werde ich dann mal den Info Adapter deaktivieren und schauen was dann bei mir passiert.

[klassisch]

Vor dem Neuaufsetzen von Windows steht meiner Meinung nach noch ein Experiment aus:

• Rechner mit dem alten 8GB RAM-Riegel aufbauen. So wie es mal stabil lief
  -ioBroker starten
• info-Adapter deaktivieren
• CPU-Leistung beobachten

Aus der Github-Beschreibung des Info-Adapters schließe ich:
Der Info-Adapter nutzt die WMI*-Prozesse für seine HW-Abfragen.
Bei Deinem N3050 scheinen sich die zu türmen, also schneller rein zu kommen als sie abgearbeitet werden können. Deshalb arbeitet der arme Celeron unter Volldampf ohne Aussicht auf Erfolg - das gibt es manchmal auch im richtigen Leben.
Die RAM-Verbrauchskurve Deines i7 Laptops würde mich noch nicht nervös machen - solange die CPU-Belastung im Rahmen bleibt und nicht kontinuierlich ansteigt. (RAM) Aufräumen kostet Kraft und Zeit (wie im richtigen Leben), deshalb scheint Win das Aufräumen nur bei Bedarf zu machen. Solange die Rechenleistung nicht ansteigt, beunruhigen die RAM-Kurven erst mal nicht.
Also bei Deinem N3050 System erst mal den info-Adapter deaktivieren und schauen wie sich die Sache entwickelt.

[Feuersturm]

@klassisch Hallo klassisch, ich hatte meinen Beitrag nach der Veröffentlichung nochmal überarbeitet, da mir auch einfiel, dass die Messung ohne Info Adapter noch offen ist. Ich habe gestern Nacht den Infoadapter deaktiviert und werde jetzt die nächsten 24h einmal abwarten und schauen, wie sich das System verhält.