Hoher RAM Verbrauch ioBroker unter Windows
-
@Feuersturm sorry, das Editing hatte ich nicht bemerkt. Hatte den Beitrag in der Nacht zwar gelesen, habe mich aber erst heute morgen zur Antwort rangesetzt.
Bin jedenfalls gespannt, ob das Abstellen des info-Adapters hift. In der github Beschreibung des Adapters werden die WMI* Prozsse explizit erwähnt. Allerdings in Umfeld von Themen mit Zugriffsrechten; wenn z.B. gar keine Werte angezeigt werden. Und in einer MS Beschreibung zu den WMI Prozessen steht, daß man damit an HW-Informationen kommt. Deshalb nehme ich an, daß diese Prozesse vom Adapter ausgelöst werden.
Der Adapter bietet anscheinend auch die Möglichkeit, das Laden der aktuellen Systemdaten zu unterdrücken.
Wenn Dein Test mit dem komplett deaktivierten info Adapter erfolgreich sein sollte (= keine CPU Überlast mehr), könnte das der nächste Schritt sein. Zumindest so lange, bis es eine gemäßigte Adapterversion mit längeren Zuriffsintervallen (als default) gibt. Aber das ist noch Zukunftsmusik.
Ansonsten gibt es bei mir auch noch eine Ungereimtheit mit dem Adapter. Ich bekomme viele Infos angezeigt - also kein Rechteproblem - aber keine Temp. Andere Tools können aber die Temp anzeigen. -
Die Ermittlung der Systeminformationen im Infoadapter beruht auf dem Paket https://github.com/sebhildebrandt/systeminformation
-
@klassisch sagte in Hoher RAM Verbrauch ioBroker unter Windows:
Bin jedenfalls gespannt, ob das Abstellen des info-Adapters hift.
Ich hatte in den letzten Tagen den Server mit 16 GB RAM bestückt und den info Adapter deaktivert mit folgendem Ergebnis:
Nach 2 Tagen und 18h Laufzeit waren 35 wmi Prozesse aktiv. Die CPU Auslastung betrug 100%. Die 16 GByte RAM waren zu 99% belegt. Der Prozess WMI Provider Host verursachte eine Prozessorlast zwischen 30 und 50%
Hierzu muss man aber auch sagen, dass ich parallel die Leistungsdaten mit dem Tool "perfmon" / "Leistungsüberwachung" aufgezeichnet habe. Ich vermute es hat einen ähnlichen Einfluss auf das System wie der info Adapter.Ich hatte danach den Server mit den alten 8 GByte RAM bestückt und den info Adapter komplett gelöscht. Leider wurde der Test durch eine Spannungsunterbrechung unterbrochen. Habe den Server heute wieder hochgefahren und werde einmal schauen, wie sich das System verhält. Aktuell laufen keine weiteren Analysetools. Aktueller Stand nach 10h Laufzeit CPU Auslastung im Durchschnitt 20%, RAM zu 59% belegt, Prozess WMI Provider Host ca. 10% CPU Auslastung
-
Bitte verwende das Tool „Process Explorer“ von Microsoft/Sysinternals, um herauszubekommen, welcher Prozess die WMIC-Prozesse gestartet hat. Außerdem kannst Du in den Aufrufdetails der WMIC-Prozesse sehen, welche WMI-Abfrage sie ausführen. Und viele mehr. Speicher und CPU-Verluf eines jeden Prozesses graphisch....
Auch der ioBroker js-controller startet IMHO alle ca. 10s WMIC-Prozesse.
Die 35 WMI-Prozesse sind das Problem. Ich wette, sie sind irgendwie „stecken“ geblieben und verursachen die 100% CPU-Last dann. (Z.B. In WMIPRVSE)
-
Hallo @Stabilostick, aktuell sieht es so aus
Wie komme ich zu den von dir genannten "Aufrufdetails"? Meinst du das Fenster "Properties" das sich öffnet, wenn ich einen Doppelklick auf den WMIC.exe Prozess mache?
Aktuell tauchen die WMIC.exe unter den einzelnen node.exe Prozessen auf und verschwinden nach ca. 1-2s wieder. -
Ja, die Properties meine ich. Da steht der Aufruf mit de Abfrage im ersten Fenster.
Das mit dem kurzen Auftauchen ist das normale Verhalten. Js-Controller und Adapter rufen WMIC regelmäßig auf. Die Ergebnisse stehen in der Expertenansicht in den Objects ich glaube unter system.adaper...load oder so ähnlich usw.
Die iobroker.exe ist der Dienstwrapper, der die erste Node.exe startet. Die führt die js-Dateien des js-Controllers aus. Darunter m Baum laufen dann die Node.exes der einzelnen Adapter.
Was nicht sein darf ist, dass die WMIC-Prozesse nicht verschwinden. Dann ist irgend etwas in Windows schief gegangen.
-
Ich habe jetzt seit knapp 2 Tagen eine neue ioBroker Instanz mit der Version iobroker-1.5.14.b-windows-installer.exe erstellt und gleich zu Beginn den Info Adapter komplett aus der frischen Software entfernt.
Der Server verhält sich tadellos. Nach knapp 2 Tagen betrieb sind jetzt 2,5 GByte RAM von 8 GByte belegt und die CPU Auslastung lieg bei 10 bis 20%.
Ich werde jetzt im nächsten Schritt einmal wieder den Info Adapter installieren und schauen ob sich etwas großartig verändert. -
@Feuersturm vielen Dank für die Rückmeldung! Freut mich daß das soweit funktioniert. Bin gespannt, wie sich der info Adapter auswirkt und ob er auf eine konservertive Parametrierung reagiert.
-
Wenn man auf der Einstellungsseite der info-Adapterinstanz einen Schieberegler auf 0 stellt, dann ist das entsprechende wmi-Polling abgeschaltet. Nichtsdestotrotz erfolgen weiter wmic-Aufrufe aufgrund des js-controllers und der einzelnen Adapter, jedoch in geringerer Aufruffrequenz.
-
Ich hab im ersten Schritt den info-Adapter installiert und die Instanz aktiviert aber die Funktion "Aktuelle Systemdaten nicht laden" aktiviert. Werde jetzt erstmal 1-2 Tage beobachten wie sich der Server damit verhält.
-
@Feuersturm Prima, so sollte sich das Thema schrittweise eingrenzen lassen.
-
@Feuersturm sagte in Hoher RAM Verbrauch ioBroker unter Windows:
Ich hab im ersten Schritt den info-Adapter installiert und die Instanz aktiviert aber die Funktion "Aktuelle Systemdaten nicht laden" aktiviert. Werde jetzt erstmal 1-2 Tage beobachten wie sich der Server damit verhält.
Das System hat sich nach weiteren knapp 2 Tagen weiterhin unauffällig verhalten (RAM Verbrauch war annähernd konstant und auch die CPU Auslastung lag wieder bei um die 20%)
Ich hab jetzt das einlesen der Systemdaten im Info Adapter aktiviert und den Regler bei allen Werten auf 10 gesetzt. Melde mich dann wieder in knapp 2 Tagen
-
@Feuersturm Vielen Dank für den Zwischenbericht! Sieht gut aus.
-
Und wieder sind 2 Tage rum. Das System verhält sich ruhig. Man sieht, dass es alle 10s einen Peak gibt, der Server gerät aber nicht aus dem Tritt und CPU und RAM Auslastung bleiben konstant.
Mittlerweile habe ich meinen defekten RAM riegel tauschen können. Jetzt läuft der Server wieder mit 16 GByte RAM
-
@Feuersturm Vielen Dank für die Rückmeldung. So haben wir wieder etwas gelernt. Habe mal in github angeregt, die max Updateintervalle des info Adapters zu erhöhen und die Defaultwerte sehr ressourcenschonend einzustellen. Mal sehen.
-
@klassisch Super. Kannst du das Ticket hier bitte verlinken?
-
@Feuersturm Es gab schon so einen issue, der aber mit Verweis auf die Einstellbarkeit hängen geblieben ist. Habe den mal fortgeschrieben https://github.com/iobroker-community-adapters/ioBroker.info/issues/38
closed Adapter uses too much CPU #38
-
@Feuersturm sagte in Hoher RAM Verbrauch ioBroker unter Windows:
Ich hab dann nochmal eine frische ioBroker Konfiguration über den Windows Installer ohne irgendwelche Instanzen für 24h laufen lassen. Hier hat sich jetzt der freie RAM von 10 GByte auf aktuell 4 GByte bei 100% CPU Auslastung verringert.
Ich gehe auch davon aus, dass sich irgendwas relevantes für mich zwischen der Version 1.5.12 und 1.5.14b getan hat, da mein System ja auch mit der Version 1.5.12 und nicht vorhandenem Info Adapter verrückt gespielt hat.
Das Problem scheint sich damit auf meinem Server mit dem aktuellen Installer gelöst zu haben. -
@klassisch sagte in Hoher RAM Verbrauch ioBroker unter Windows:
max Updateintervalle des info Adapters zu erhöhen und die Defaultwerte sehr ressourcenschonend einzustellen. Mal sehen.
Habe vom Entwickler gehört, dass der Info-Adapter auf Windows ggf. zukünftig das Auslesen der Systemwerte defaultmäßig bei Neuinstallationen ausgeschaltet hat.
-
@Stabilostick Sehr gut, vielen Dank! Kleinen Linuxmaschinen tut das aber auch gut. Mein OPi hatte durch die häufigen Systemabfragen auch eine "Reconnect DB" Krankheit entwickelt. Bei großen Maschinen merkt man das nicht. Meiner Meinung nach kann man das generell deaktivieren. Wen es nicht interessiert, belastet das System nicht unbemerkt. Wen es interessiert, der kann es auch einschalten. Ich kann mich auch an dieses Feature bei der Erstinstallation gar nicht erinnern. Entweder habe ich das übersehen oder es ist erst zu einem Update reingekommen.
