Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[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.