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
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
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
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
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
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
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
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
Hab auch mal auf REDIS umgestellt (total schmerzfrei `
Ja, das geht wirklich nebenbei. Evtl. Der ein oder andere status nicht sofort synchron.
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
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.
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
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
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.
