ioBroker-Container nutzt CPU der NAS nicht komplett aus

[Marc Berg]

@matze007 sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

Habt ihr eine Idee, wie man den Container dazu bewegen kann die CPU stärker auszulasten?

Docker schränkt den Zugriff auf die CPU nicht ein (es sei denn, man stellt dies explizit ein). Das Problem wirst du auf einer nativen Installation auch haben, weil der Prozess, der die Auslastung erzeugt, wahrscheinlich Single-Threaded ist.

Hier ein Beispiel mit zwei Javascript-Adaptern. Jeder kann eine CPU nutzen. Mit vier solcher Prozesse kann ich meine CPU mit 4 Kernen unter Docker komplett auslasten.

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1829034 docker    20   0 1055096 198500  38124 R 100.0   1.2   0:52.37 io.javascript.0
1829141 docker    20   0 1054908 198412  38084 R  99.7   1.2   0:48.28 io.javascript.1

Wie @Glasfaser schon schrieb, solltest du der Ursache auf den Grund gehen.

[matze007]

@Glasfaser

Die CPU-Auslastung gemäß Portainer ist bei 100%:

meinst du den Container ioBroker .

Genau so ist es gemeint. Der Screenshot den ich gezeigt habe bezieht sich auf den ioBroker-Container.

da wäre die Frage " Wieviel " .. und schon auf redis umgestellt.

Ich habe rund 25.000 Objekte.
"Redis" sagt mir noch nichts... Was ist das? Kann aber gerne auch kurz googlen.

Zeige mal bitte die Full Ausgabe von

Kann ich gerne machen. Reiche ich nach.

Den js-controller musste ich vorhin allerdings wieder downgraden. Sonst hätte ich ein Kompatibilitätsproblem mit einem alten Adapter bekommen.

@Marc-Berg
Hier haben wir die große Parallele zu meinem Problem. Die Vollauslastung mit 100% tritt nur dann auf, wenn ich in Blockly den Objektbaum mit den 25.000 öffne. Das heißt, hier liegt ein solcher "single-threaded"-Prozess vor? Schließlich ist das ja auch der javascript-Adapter.

Gibt es in dem Fall gar keine Lösung für mein Problem? Wenn ich eine zweite javascript-Instanz erstelle, dann würde beim Erstellen eines Blocky-Scripts ja dennoch nur eine Instanz den Objektbaum laden, wodurch ich dasselbe Problem (nur eben auf einer anderen Instanz) hätte. Oder greift dann Instanz ".0" auch auf die Ressourcen von Instanz ".1" zurück?

[Glasfaser]

@matze007 sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

Die Vollauslastung mit 100% tritt nur dann auf, wenn ich in Blockly den Objektbaum mit den 25.000 öffne.

Dann zeige mal bitte

iob diag

das heißt , es ist der gesamte Baum inkl. den Zweigen immer auf .

Zeige mal ein Screenshot davon !

[Glasfaser]

@matze007 sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

wenn ich in Blockly den Objektbaum mit den 25.000 öffne.

hast du diesen ( alten Effekt ) https://github.com/ioBroker/ioBroker.admin/issues/1656

Glasfaser-io created this issue in ioBroker/ioBroker.admin

closed Admin 6 , bei Objekte den Objektbaum begrenzen. #1656

[Marc Berg]

@matze007 sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

Das heißt, hier liegt ein solcher "single-threaded"-Prozess vor? Schließlich ist das ja auch der javascript-Adapter.

Davon würde ich ausgehen. Kannst du auf dem NAS ein "top" laufen lassen? Dann kannst du es ja direkt sehen.

Gibt es in dem Fall gar keine Lösung für mein Problem? Wenn ich eine zweite javascript-Instanz erstelle, dann würde beim Erstellen eines Blocky-Scripts ja dennoch nur eine Instanz den Objektbaum laden, wodurch ich dasselbe Problem (nur eben auf einer anderen Instanz) hätte. Oder greift dann Instanz ".0" auch auf die Ressourcen von Instanz ".1" zurück?

Nein, das bringt nichts. Das würde nur Sinn ergeben, wenn du mehrere Teilaufgaben hast, die du auf die Instanzen verteilen kannst.

[MartinP]

@marc-berg

Mit vier solcher Prozesse kann ich meine CPU mit 4 Kernen unter Docker komplett auslasten.

Javascript ist ja eigentlich nicht auf Nebenläufigkeit in mehreren Prozessen ausgelegt. Muss man da irgendetwas beachten, wenn man zu diesen Tuning-Maßnahmen greift?
Können zwei Javascript-Instanzen frei auf denselben Datenpunkt zugreifen, oder könnte es da Kleinholz geben?

[Marc Berg]

@martinp sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

Javascript ist ja eigentlich nicht auf Nebenläufigkeit in mehreren Prozessen ausgelegt. Muss man da irgendetwas beachten, wenn man zu diesen Tuning-Maßnahmen greift?
Können zwei Javascript-Instanzen frei auf denselben Datenpunkt zugreifen, oder könnte es da Kleinholz geben?

Da könnte ich nur vermuten. Mir ging es nur darum zu zeigen, dass man auch unter Docker die CPU ohne "Kniffe" auslasten kann (wenn es denn die Anwendung hergibt).

Ich glaube, wenn man solche Performance-Probs auftreten, hat mal wohl andere Baustellen, die man schließen sollte.

[OliverIO]

@martinp sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

Javascript ist ja eigentlich nicht auf Nebenläufigkeit in mehreren Prozessen ausgelegt

nicht ganz korrekt.
javascript/node ist single threaded. d.h. ohne irgendwas kann in einem javascript exakt nur eine anweisung gleichzeitig ausgeführt werden.
iobroker besteht aus mehreren prozessen (der js-controller, web, jeder einzelne adapter)
wenn diese prozesse miteinander kommunizieren müssen, dann muss man immer noch was tun.
unter iobroker sind das die datenpunkte.

was du mal machen kannst ist auf die console IM contaier zu gehen und dort mal mit top schauen welcher prozess da so ausgelastet ist.
meist ist das die javascript instanz, die entweder wirklich viel macht oder skriptfehler enthält

[Glasfaser]

Könne wir hier bitte beim Haupt-Thema von @matze007 bleiben

ioBroker-Container nutzt CPU der NAS nicht komplett aus

[OliverIO]

@glasfaser sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

ioBroker-Container nutzt CPU der NAS nicht komplett aus

ja das ist das thema.
er empfindet wahrscheinlich manche dinge als langsam obwohl seine cpu nicht ausgelastet ist.
dennoch werden bestimmte prozesse bei 100 prozent sein, da ein javascript prozess nun mal genau nur einen thread einer cpu (hat meist 2 threads) nutzen kann.

unter docker gibt es im standard keine beschränkung auf die cpu.
ich glaube man kann die aber einstellen.

[Glasfaser]

@oliverio sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

ja das ist das thema.

Richtig .

Das Thema zur "Visuelle Darstellung "hatten wir hier zig mal im Forum durchgekaut .

Die schauen nur auf die Bildchen / Diagramme und nicht mal LIVE .
Deshalb sind diese Anzeigen / Synology nur Momentaufnahmen ( Schätzeisen ) einer Zeit X .

[Glasfaser]

@matze007 sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

Die CPU-Auslastung gemäß Portainer ist bei 100%:

(Die 300% stammen vom Neustart des Containers)

Ist doch alles in Ordnung !

Er hat 4 Kerne also 400 % , also 1 Kern hat einen Verbrauch von 100 %

kann man auch per compose setzen

1 Kern nur

cpus: '1'

[matze007]

Wow, erstmal vielen Dank an alle für euren grandiosen Support. Ich bin gerade auf dem Sprung, wollte euch aber noch kurz die Prozessauslastung über top posten...

Wenn der Objektbaum geladen wird, sieht es wie folgt aus:

Ist der Objektbaum geladen, ist alles wieder im Normalbereich:

Ich bin irrtümlich davon ausgegangen, dass bei 4 Kernen jeder Prozess die CPU voll auslasten kann. Das ist aber durch den single-threaded-Prozess wohl nicht so. Wobei sich das ja auf den javascript-Adapter bezog, der aber gemäß Screenshot gar nicht verantwortlich ist. Kann ich den verantwortlichen Prozess (iobroker.js-con(sole)) dazu bringen, mehr als einen Kern zu verwenden?

Den Objektbaum hatte ich nicht ganz offen. Aber vermutlich hat er jeweils ca. 6.000 Datenpunkte laden müssen. Wenn ich den Objektbaum schließe, ist er natürlich viel schneller. Vielleicht muss ich mit den geöffneten Objekten einfach restriktiver sein, wenn das die Ursache des Übels ist...

[Glasfaser]

@matze007 sagte in ioBroker-Container nutzt CPU der NAS nicht komplett aus:

Den Objektbaum hatte ich nicht ganz offen. Aber vermutlich hat er jeweils ca. 6.000
#Datenpunkte laden müssen. Wenn ich den Objektbaum schließe, ist er natürlich viel schneller.

Deshalb mein Hinweis dazu !

[Codierknecht]

@matze007
Just for Info

Kann ich den verantwortlichen Prozess (iobroker.js-con(sole))

… nix „Console“ … „Controller“

Das ist quasi der „Kernel“ des ioBroker

Und wie @Glasfaser schon schrieb: Ein „offener“ Objektbaum braucht beim Laden. Auch auf meinem Core i7. Darum öffne ich immer nur das was ich gerade brauche. Macht es auch übersichtlicher.

[OliverIO]

@matze007

Also, es ist so wie vermutet. Ein Prozess, ausgerechnet der js-controller ist zeitweise bei 100 %
Leider kann man das nicht auf mehrere CPUs erweitern
Man könnte jetzt noch schauen, warum das Laden des Objektbaumes so lange dauert
Wie speicherst du die Daten Punkte? Jsonl, Redis?
Hast du eine Festplatte oder eine SSD oder gar nur eine SD?
Wie ist die Performance des Datenträgers?
Wenn der Prozess im Normalzustand nur 3 % benötigt, dann ist das Betriebssystem mit IO beschäftigt.
Das wäre der Punkt, an dem man ansetzen könnte zur Optimierung.

Da du genügend freien Raum hast, ist auch der Swap nicht das Problem

[matze007]

Heute habe ich etwas intensiver mit dem System gearbeitet, um das Verhalten mit reduziertem Objektbaum zu prüfen. Gerne möchte ich euch hier kurz ein Update geben - auch, damit andere Nutzer die über das Problem stolpern den finalen Stand haben.

@glasfaser

hast du diesen ( alten Effekt ) https://github.com/ioBroker/ioBroker.admin/issues/1656

Das Issue habe ich mir durchgelesen. Dort wird auch auf https://forum.iobroker.net/topic/31020/javascript-blockly-wird-oft-nicht-gespeichert/332 verwiesen. Dort ist ein Problem beschrieben, bei dem Blockly auch beim Laden der Datenpunkte überlastet ist und das Speichern träge abläuft oder Änderungen sogar verworfen werden. Das Problem habe ich bei mir auch schon beobachtet. Die Parallele zum Verweis von @glasfaser ist also da.

@codierknecht:

… nix „Console“ … „Controller“

Sorry

@oliverio:

Ein Prozess, ausgerechnet der js-controller ist zeitweise bei 100 %
Leider kann man das nicht auf mehrere CPUs erweitern

Schade, dass sich der Prozess nicht aufteilen lässt. Das wäre jetzt natürlich super gewesen.

@oliverio:

Wie speicherst du die Daten Punkte? Jsonl, Redis?

Puh, jetzt bin ich überfragt. Ich meine hier nichts angepasst zu haben. Wie kann ich das nachvollziehen? Und welchen Methode hat welchen Vorteil?

@oliverio:

Hast du eine Festplatte oder eine SSD oder gar nur eine SD?
Wie ist die Performance des Datenträgers?

Im NAS werkelt eine Seagate IronWolf-Platte. Abgesehen von diversen Containern wird das System momentan für nichts verwendet. Die Platte wird also nicht der Engpass sein.

@oliverio:

Wenn der Prozess im Normalzustand nur 3 % benötigt, dann ist das Betriebssystem mit IO beschäftigt.
Das wäre der Punkt, an dem man ansetzen könnte zur Optimierung.

Interpretiere ich das richtig, dass die 3% im Ruhezustand (= also ohne Objektbaum, der geladen werden muss) deiner Erfahrung nach zu viel sind? Vielleicht muss ich dazu sagen, dass ich ein KNX-System im Einsatz habe. Auch habe ich 2 IR-Leseköpfe an meinen Stromzählern. Somit kommen ständig irgendwelche Daten rein, die verarbeitet werden wollen. Erklärt das die 3%?

Ansonsten läuft das System mit zugeklapptem Objektbaum in Blockly deutlich schneller. Klar, ich komme beim Aufklappen eines Ordners im Objektbaum wieder auf 100%, aber die Daten sind dann schneller geladen und das System kehrt zügig in eine normale Auslastung zurück.

Eine Frage noch, die das Problem vielleicht auch lösen würde: Beim Öffnen des Objektbaums in Blockly werden ja immer die aktuellen Werte angezeigt. Kann es sein, dass diese aktiv nachgeladen/aktualisiert werden? Das müsste nicht sein. Es würde ausreichen, wenn a.) der letzte Wert angezeigt wird (ohne nachgeladen zu werden) oder b.) die Werte gar nicht angezeigt werden. Ließe sich das einstellen?

Danke euch.