Hoher CPU-Load des Raspberry
-
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
-
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.
-
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
-
-
Komisch wie unterschiedlich das Systemverhalten ist.
Ich kann mich nur Steinwedel anschließen. Adapter auf das minimalistischte reduziert, trotzdem hängt das System nach unterschiedlicher Zeit.
Nur ein Restart des Raspberry hilft dann und alles läuft wieder performant.
Ich weiß nur nicht wie ich der sache auf den Grund gehen kann.
Gesendet von meinem SM-N9005 mit Tapatalk
-
Moin!
Genau das verhalten hatte ich auf einem Pi3 auch. Allerdings habe ich eh nur die nötigsten Instanzen laufen (REGA, VIS, 2x HM und Fritzbox).
Allerdings korrelierte es bei mir immer mit extrem hohem Speicherverbrauch.
Daher glaube ich auch es gibt ein Memory-Leak der das System schnell dazu bringt sich selber zu beschäftigen.
Beim PI merkts mann halt besser da der Speicher ja doch sehr schnell gedeckelt ist
Mit REDIS habe ich aktuell ganz gute Erfahrungen.
48h hält das System aktuell durch. Länger konnte ich noch nicht am Stück probieren…
bis denne
Mr.Lee
-
So, jetzt habe ich das zweite System auf der Syno mit 8 GByte am laufen…ohne REDIS...mal schaun wer länger durchhält
Oder weiß einer wie man auf der Syno REDIS verwendet?
bis denne
Mr.Lee
-
So habe nunmehr REDIS installiert. Und, man glaubt es kaum, dass System hängt nicht mehr. Es gibt keine Aussetzer mehr nach 40sec für 10sec. Da REDIS nur die States speichert und sich sonst nichts ändert, heißt das wahrscheinlich, dass auf meinem System das Lesen/Schreiben der States bei ioBroker zu häufig geschieht und das System überfordert ist. Die Anzahl der Adapter und Instanzen dürfte damit primär egal sein. Vielmehr ist interessant, wie häufig sich ein State ändert. Je häufiger dieses der Fall ist, desto eher kommt das System an die Grenzen. IoBroker scheint hier nicht sehr effizient zu sein, da es bei Redis dann doch geht. Das der Raspi schlechter abschneidet ist klar, da das Schreiben auf einer Flash-Karte nicht sehr performant ist. Auch mein System schneidet schlechter ab, als das von ruhr70. Da ich ioBroker in einer virtuellen Maschine laufen lasse und die Lese-/Schreiboperationen dadurch langsamer sind kommt das System schneller an die Grenzen. Hinzukommt, dass auf dem Host ein Raid 6 läuft. Gefühlt ist dieses träger als ein Raid 5 oder einzelnen Festplatte. Daher wird bei mir die Schreib-/Leseperformance weiter eingeschränkt.
Zu den Symptomen, die dieses Problem mitbringt, scheint mir jetzt vieles plausibel. Wenn das System nicht irgendwann die Daten schreiben kann, dann steigt der Speicherbedarf. Je häufiger der Fall eintritt, desto langsamer wird auch VIS. VIS muss ja auch lesen. Insgesamt ist die CPU nicht ausgelastet, da der Lese-/Schreibprozess wohl das aktuelle Programm (ioBroker) an der weiteren Ausführung (zumindest in Teilen) behindert. Die CPU steht aber anderen Programmen zur Verfügung. Geht irgendwann mal der Seicher zur Neige, steigt auch die CPU-Last durch Auslagerung des Speichers. Bezüglich ioBroker werden wohl nicht alle Programmteile gleichermaßen gehemmt. Die Konsole und VIS sind betroffen. Trotzdem werden Events immer noch zum richtigen Zeitpunkt ausgelöst.
Ich hoffe, dass mein Ergebnis von anderen auch bestätigt werden kann und dies zu einer Verbesserung von ioBroker führt. Schön wäre es aus meiner Sicht, wenn die interne Funktionsweise von ioBroker näher dokumentiert werden würde. Dann könnte man auch leichter sich durch den Quellcode arbeiten und eventuell das Problem auch selber angehen.
Bis dahin sollte man, wenn man Performanceprobleme hat Redis zumindest in Erwägung ziehen.
Herzlichen Gruß Gerhard
-
…heißt das wahrscheinlich, dass auf meinem System das Lesen/Schreiben der States bei ioBroker zu häufig geschieht und das System überfordert ist. `
ioBroker schreibt die states in die Datei "states.json" maximal alle 30 s. Ich habe die Zeit auf 10 min hochgesetzt, indem ich die 2 Stellen in der Datei "/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInMemServer.js" von 30000 auf 600000 geändert habe; das zwar nicht, um die Systembelastung zu senken, sondern um die Zahl der Schreiboperationen auf die SD Card zu verringern. -
Nochmal ne Nachträgliche Beobachtung:
Hatte ne zeitlang das Problem das Adapter dauernd neugestartet wurden…dieses hat den load des RasPi in die Dekce getrieben...also:
-
log prüfen
-
redis nutzen.
Momentan ideln meine RasPis so bei load 0.2
bis denne
Mr.Lee
-
-
Hallo,
ich hänge mich hier dran, weil ich denke mein Problem passt ganz gut in diesen Thread.
Habe hier http://forum.iobroker.net/viewtopic.php?f=8&t=10145 mit hormorans Hilfe mein multihostproblem in den Griff bekommen (zumindest läuft der Slave stabil, wenn er auch noch nix zu tun hat)
Dabei fiel mir auf dass ich zur Zeit wieder verstärkt CPULoad-Spitzen habe. Ich hatte das erst mit dem Javascript-Adapter in Verbindung gebracht, hat sich aber nicht bestätigt.
Nun dass was ich beobachte: Sobald ich vis öffne und an meinen Seiten rumschraube kann ich beobachten, wie der Load Wert durch die Decke geht:
Dann wird das System komplett unbedienbar, und nach ca. 20min hat sich der Load Wert wieder auf ein erträgliches Mass eingepegelt (unter 1,0)Einzig der ping geht noch.
Gruß
crepp
Hier mal noch eine grössere Version: (aktuell geht gar nix mehr…)
-
Vis (und insbesondere iframes mit flot-charts) zehren schon an der Leistung des Pi.
wenn es bei dir aber eben diese flot Chrts sind, wird es weniger die CPU-Auslastung sein (was zu prüfen wäre), sondern die Schreib- und Lesezugriffe auf die Daten.
Was für eine SD-Karte hast du denn?
Gruß
Rainer
-
Sandisk,
Ich setzt die flotcharts aber seit mehr als einem Jahr ein von daher hat sich auf der Schiene nichts geändert. Und wenn man sich im moni die Historie anschaut, sieht man dass sich das Problem in den letzten Tagen (wieder) verstärkt hat.
Im logfile sind keine Fehler zu sehen, ausser dass ich sehe dass ab und zu sämtliche adapter neu gestartet werden (ohne Reboot)
-
Naja, um nicht raten zu müssen was da passiert schlage ich vor du machst eine SSH Shell auf und lässt dort "top" laufen. Dann provozierst Du den Fehler.
Was siehst Du in Top? geht die CPU Last eines prozesses hoch? Bei solch hohen CPU werten tippe ich eher darauf das der Raspi ins Swap geht weil ein Prozess mehr speicher braucht als Du hast … Aber das siehst Du damit.
Danach weisst Du aber auch welcher prozess es ist und man kann weiter überlegen
-
Naja den Fehler provozieren brauche ich nicht, habe jetzt beim pi den Stecker gezogen und nach dem reboot ca. 10min htop laufen gehabt.
Die Load Werte gehen nicht unter 8. D.h. über admin brauch ichs gar nicht zu versuchen. Bei solch hohem Load Werten läuft selbst htop nicht all zu lange.
-
Ändert sich der "Swap used" wert? Weil die CPU hat noch >30% idle, also ist es (ist Dual-Core Prozessor, oder ?!) eher ein Speicherproblem …
Sortiere die Prozessliste mal nach Speicherverbrauch
-
Wie vermutet hat die CPU noch reserve.
Das System swapped, wie apollon vermutet hat, und ide ganzen node - Prozesse deuten darauf hin, dass das System gar nicht erst in die Hufe kommt. Bei einem load von über 20 auch kein Wunder.
Vielleicht solltest du mal die Karte tauschen.
@crepp:habe jetzt beim pi den Stecker gezogen `
Das tötet Karten!
@crepp:und nach dem reboot `
Stecker ziehen ist kein reboot.Gruß
Rainer
-
Ja ich weiss schon, aber wenn ich fast ne viertelstunde nicht das System rankomme ?
Hab noch ne 2. Karte aber die ist ein paar bytes kleiner als diese hier, da muss ich erst mal ein kpl. Backup machen. Dann werde ich sie tauschen und wieder berichten. Swap used werde ich auch mal im Auge behalten. Momentan hat sich das System wieder beruhigt (wie auch immer ?!) Kann sogar wieder im vis arbeiten…
Vielen Dank vorläufig für Eure schnelle Hilfe !
-
Dann sieh dir mal die logs zu den Zeiten an, wenn es hakt.
ggf. läuft da ein Skript amok.
Gruß
Rainer
-
Wenn es wirklich ein Swap-Problem ist dann gibt es meistens einen OPunkt wo das OS den verursachenden Prozess killt.
Schau mal ob du sowas im "/var/log/syslog" findest. Ich galueb der Begriff ist "OOMKiller" oder so
-
Also wenn ich mir den top-screen anschaue fallen mir folgende Diege ein:
-
CPUs sind mit <50% beschäftigt, das ist nicht das Problem, Raspi's mit 1GB mem haben 4 CPU's also ist da Luft nach oben.
-
Wenn das nach einem re-boot war sind noch immer nicht alle Adapter voll geladen ('node'-Zeilen werden in Adapter-Instanzen umgewandelt wenn sie fertig sind mit dem Start)
-
Es sollte kein Swap nach dem re-boot verwendet werden, hatte ich noch NIE, nur nachdem ich eventuell neue Adapter installiere oder sonstige updates durchführe!
Ich würde ein
sudo iobroker stop sudo iobroker upgrade self sudo iobroker startdurchführen, nach dem Stop alle node-Prozesse entfernen wenn noch welche da sind.
-
