Hoher RAM Verbrauch ioBroker unter Windows
-
@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.
-
@ldittmar (LDittmar) hat blitzschnell gehandelt und eine perfekte Lösung vorgelegt:
Now you can choose 240s.
I set "Don't load current system data" as default true.
Default values are now higher.
I wrote a warning on the setup site: "Calling up current system data at too short intervals can lead to very high CPU consumption, especially under Windows. To switch off individual queries, set the slider to 0."Die neue Version kann man direkt von Github runterladen. Ist noch eine Entwicklerversion, könnte also noch ein paar Themen haben.
Bei mir läuft sie seit einigen Minuten stabil. Bei der Installation gabs einen Satz Fehlermeldung wegen vis und DB, aber jetzt ist es wieder ruhig. -
@klassisch Tja... Windows-Systeme machen da leider echt Ärger. Ich hoffe dass das eine Lösung ist, mit dem alle leben können. Ich lasse das ganze mal ein paar Tage laufen und wenn keiner was dagegen spricht, stelle ich die aktuelle Version auf Stable.
-
@ldittmar herzlichen Dank für die schnelle Reaktion und super Lösung.
Bei mir scheint der info Adapter 1.4 gut zu laufen.
Hatte heute morgen leider meine Fritte aktualisiert, was zu etlichen Logeinträgen bei verschiedenen Adaptern geführt hat, nicht aber beim info.Denke, die neuen Einstellmöglichkeiten und Defaultwerte werden sehr vielen mit schwächeren Prozessoren helfen. auch den Linux SBCs.
