Hoher CPU-Load des Raspberry

[rwaechter]

Hallo liebe iobroker-Gemeinde,

nach einem der letzten Updates vom iobroker admin und verschiedenen Adaptern ist jeweils nach einem Neustart des Raspberrys die CPU-Last normal, steigt jedoch nach einigen Stunden oder Tagen stark an (siehe iobroker CPU-Last.pdf). Es scheint, als ob sich ein Prozess nach und nach "zufrisst". Im Log sind keine Fehlermeldungen zu sehen.

System:

Raspi 2b, Debian Jessie, Node.js 4.4.45, iobroker.js-controller 0.9.0, iobroker admin 1.2.4, javascript 2.2.1, Homematic ReGaHSS 1.2.0, Homematic RPC 1.3.1

Hat jemand einen Tip, wie ich diesem Problem beikomme? :roll:

Gruß Roland
931_iobroker_cpu-last.pdf

[apollon77]

Ich bin gerade einem ähnlichen Problem auf der Spur: Ich habe einen CubieTruck mit iobroker drauf und aktuell ist der Server nach 1-3 tagen plötzlich "weg"= nicht mehr zugreifbar … Er lässt sich noch anpingen, aber schon ein SSH Login kommt nicht durch. Damit ist es auch schwierig rauszufinden was die Kiste hat. Die Logs geben nichts besonderes her.

... vllt ist es ja das gleiche Thema?!

[StefSign]

Hallo,

bei mir lag es an einem veralteten NodeJS. Nach dem Update auf NodeJS 4.x war alles in Butter.

Allerdings handelt es sich um einen Odroid.

[rwaechter]

Guten Abend in die iobroker-Gemeinde,

ich habe auf die letzte Version npm und nodejs upgedated, aber der Fehler besteht weiter. Nach ca. 48 Stunden Laufzeit des Raspi steigt die CPU-Last auf ~100%. Habe mal alle Adapter in Pause gesetzt. Nach Beenden des hm-rega ging die CPU-Nutzung auf ~1-3% zurück. Nach erneutem Start aller Adapter auch wieder alles normal. Das Phänomen wiederholt sich…

Bitte um Hilfe, da unsere Alarmtechnik auch über iobroker läuft.

Gruß

Roland

[rwaechter]

Hallo,

hat denn hier keiner einen Tip? Bluefox?

Ich habe herausgefunden, dass es definitiv der hm-rega Adapter ist, der sich "hochschaukelt". Nache einem Neustart des Adapters ist wieder für 24-48 Stunden alles ok.

Gruß

Roland

[hanisoft]

Hello,

ich schließe mich hier einmal an. Irgendwie ist mein System(e) total zäh.

Wenn ich über vis lampen schalten will reagiert diese einmal gar nicht oder schaltet nach 10-15 Sekunden, manchmal geht es auch sofort. Aber nur für ein paar Minuten oder Sekunden, dann stockt es wieder. Dasselbe spiel beim scenen Adapter.

Irgendwie bremsen der REGA Adapter das ganze System aus (Glaube das er es ist). Das betrifft auch den Zugriff auf Iobroker selber.

Ich habe zwei Systeme am Laufen, eine Windows Installation unter Windows Homeserver 2011 und eine Raspi3 Installation. Bei beiden habe ich die Phänomene.

Schalte ich REGA uns RPC aus, scheint alles in Ordnung.

Der Taskmanager unter Windows zeigt immer wieder Spitzen von 100%, mit TOP unter Linux ebenfalls.

Ich bin aber keinesfalls sicher ob es am REGA Adapter liegt, es ist nur auffällig das das ganze erst seit dem letzten Update passiert…

Gruß

Hannes

[eric2905]

Ich habe ioBroker auf einem Intel NUC (i5) unter VMware ESXi auf einem Debian 8 laufen (mit 4 GB RAM und einer CPU).

Ich habe einiges an Adaptern laufen, SQL aber auf einem ext. mySQL-Server.

Das System läuft seit über einer Woche und nimmt sich ziemlich genau 1GB an RAM. Die CPU pennt quasi vor sich hin (Peaks auf 20%).

Nicht das die Raspis bzgl. RAM mit dem Kopf an der Decke sind?

Gruß,

Eric

[Homoran]

@eric2905:

Nicht das die Raspis bzgl. RAM mit dem Kopf an der Decke sind? `
Das nehme ich auch an, aber warum.

Die ständige hohe Load von bis zu 4in Einzelfällen aber 2 wird mehrfach pro Stunde erreicht. Der 5minuten Durchschnitt liegt meist bei 35-60 oft über 1.

Aber auch hier ist die CPU zu gut 99-70% Idle.

Also klemmt es woanders. Und das auf einmal.

Der echte freie RAM wird oft mit unter 50MB angegeben. Aber auch nach iobroker restart, als der freie RAM mit 200MB reichlich bemessen war kam es zum Abarbeitungsstau.

Ich bin momentan echt ratlos.

Gruß

Rainer

[hanisoft]

Hello,

das zeigen die Instanzen an:

RAM verbraucht: 1548 MB 1962 (38%) [Host: ….

Der Server hat 5GB

Ich hab auch einiges an Adapter laufen, aber bisher gings ja...

Gibts irgendwo ein Log, der etwas aussagen kann?

Ich glaub ich muss jetzt aufgeben...

Gruß

Hannes

[MrLee]

Moin!

Ich weiß das Thema ist schon nen Monat alt.

Habe aber gerade alles neu bei mir aufgestezt und daher tier das System beobachtet:

Auch bei mir steigt nach ca,. 24h die CPU-Last stark an (ca. 2). Dieses geht einher mit vollständigem Speicheraufbrauch (rest 30-50MByte), Cache bereits abgezogen…

Nach Neustart IOBroker idelt die Kiste wieder bei 0,10....freier Speicher bei 500 (cache abgezogen).

Gibt es schon Infos zu diesem Problem?

bis denne

Mr.Lee

P.S.: iobroker alles auf aktuell (0.11.2 js.controller), node ist 4.4.7

[Homoran]

Die Speicherverwaltung von Linux mutet für Windows user fast wie Harakiri an.

Linux mag keinen freien Speicher. Aller wirklich freier Speicher wird bis auf einen kleinen Rest den laufenden Prozessen zugeschoben, damit diese schneller reagieren können.

Erst wenn alles nicht klappt wird das Swapping aktiviert. Erst dies ist ein alarmzeichen.

Vorher würde ich mich auch von 30MB freiem Speicher nicht schrecken lassen. Dafür sind bestimmt noch einige Reserven im total Cache im Vergleich zu used cache.

Die Load von 2.0 gefällt mir weitaus weniger, bedeutet aber nicht, dass die CPU zu 200% ausgelastet ist, sondern dass so viele Prozesse an f Abarbeitung warten, wie die CPU mit 50% Leistung (Raspi2/3 hat 4 Kerne) schaffen würde, wenn alle diese noch nicht ab gearbeiteten Aufgaben auf einmal anstehen würden.

Ich habe mit der Umstellung auf redis einige Ressourcen einsparen können.

Gruß

Rainer

[MrLee]

MoiN!

Also bei meiner obigen Betrachtung habe ich jeden Cache abgezogen.

Das "Speicherleck" leigt direlt an iobroker, da der allokierte Speicher direkt nach einem Restart frei ist.

Alle anderen Prozesse auf dem System verhalten sich freidlich.

Spannend ist:

solange freier speicher da ist läuft der PI bei 5min load von 0,2….

Erst wenn der Speicher zur neige geht lastet iobroker den PI aus und der Load steigt auf über 1 und verbleibt im Bereich bei 2.

Daher vermute ich nicht das Problem im System, sondern das sich iobroker "vollsaugt" und daher auch wahnsinnig Last produziert.

Aktuell stellt das eigentlich mein größtes Problem dar:

• der PI wird warm,

• iobroker träge

Eigentlich schade drum, denn die ersten 24h Stunden ist es ein Engelssystem...gerade seit dem Umzug der CCU auf einen weiteren PI

bis denne

Mr.Lee

[MrLee]

Soooo….

Hab auch mal auf REDIS umgestellt (total schmerzfrei) und werde mal beobachten.

Weiß zufällig jemand wie man mit History den system.host.... loggt? Sprich den Speicher und die CPU-Last des Hosts?

bis denne

Mr.Lee

[Homoran]

@MrLee:

Hab auch mal auf REDIS umgestellt (total schmerzfrei `
Ja, das geht wirklich nebenbei. Evtl. Der ein oder andere status nicht sofort synchron.

@MrLee:

Weiß zufällig jemand wie man mit History den system.host…. loggt? `
Ich hab es mit dem rpi Adapter gemacht, geht aber nur bei raspi

Gruß

Rainer

[paul53]

@MrLee:

Weiß zufällig jemand wie man mit History den system.host…. loggt? Sprich den Speicher und die CPU-Last des Hosts? `
Das sollte funtionieren wie mit anderen Datenpunkten auch: Im Reiter "Objekte", Expertenmodus unter "system.host.Dein_Hostname" das Loggen für die Datenpunkte "freemem" oder "mem" und "load" aktivieren.

[MrLee]

Also seit 2 Tagen laufe ich auf Redis…. Genial. Speicher ca 1/3 weniger und seit 2 Tagen kein volllaufen...

In Kombination mit yahm macht das wieder richtig Spaß... Vor allem wenn man jetzt das rega polling wieder auf echt kleine intervalle setzen kann...

Nur mal so als Zwischenstand

Bis denne

MrLee

[Schnutexxl]

Hi MrLee.

Kannst du ein kurzes how to wie du auf REDIS geschwenkt hast?

Ist das unkritisch?

Danke und Gruß

Gesendet von meinem SM-N9005 mit Tapatalk

[MrLee]

War ne sache von 2 Minuten. Fünfte auf Anhieb!

Vorgehen:

http://forum.iobroker.net/viewtopic.php?t=3181

Bis denne und viel Erfolg

MrLee

[steinwedel]

Leider gehören Performance Probleme wohl etwas zu ioBroker. Mein VIS wurde immer langsamer. Zuletzt stürzte das System immer häufiger ab (komplette virtuelle Maschine) und der Neustart von ioBroker war grenzwertig, da viele Adapter nicht von alleine starten wollten. Zunächst habe ich vermutet, dass sich irgendwie die Konfiguration des Systems zerlegt hat. Da bei dem neuen System dieselben Probleme aufgetreten sind, habe ich die Zahl Instanzen der Adapter deutlich reduziert (von 25 auf 12). Siehe da, das System lässt sich wieder Problemlos starten. Und das Beste: VIS ist wieder richtig schnell. Merkwürdig ist, dass es nicht an dem Systemressource gelegen hat (CPU.Load war bei 0,5; 4GB freier Speicher). Ich hege den Verdacht, das ioBroker nicht gut mit der Menge der Instanzen zurechtkam. Das Problem hatte ich schon mal früher, als ich 10 Instanzen von Javascript erzeugt hatte. Auch hier wurde das System unbrauchbar. Damals hatte ich die Systemressourcen nicht so genau im Blick. Wenn System so langsam wird, dann starten die Adapter mit Schwierigkeiten. Häufig muss ich dann den Adapter von Hand neu starten. Dabei habe ich gesehen, dass die Adapter teilweise auch abschmieren und wieder gestartet werden. Ich tippe darauf, dass die Überwachung der Instanzen fälschlicherweise vermutet, dass die Instanzen abgestürzt sind und diese dann wieder neu starten. Das System bremst sich dann gemütlich selbst aus. Da es mit REDIS besser sein soll, stelle ich mir die Frage, ob durch dir Anzahl der Instanzen schlicht die Menge der States die geschrieben/gelesen werden müssen so hoch sind, dass das System es ohne REDIS nicht mehr schafft? Einen spezifischen Adapter, der der Übeltäter ist habe ich bislang jedenfalls nicht gefunden. Leider hat sich mein Problem, dass alle 40 Sekunden das System für 10 Sekunden hängt bislang nich nicht gelöst. Tritt auch bei neuer Maschine auf. Werde hieran auch wieder forschen.

[ruhr70]

@steinwedel:

Leider gehören Performance Probleme wohl etwas zu ioBroker. `

ich habe ioBroker zwar nicht auf einen Pi (nur den 2, Host für den BLE Scanner), aber ein generelles Performance Problem habe ich nicht.

• 58 Adapterinstanzen installiert

• 34 Prozesse aktiv (ca. 1750 MB RAM)

• 5 von den 58 Adaptern deaktiviert