Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[WolfgangFB]

@homoran sagte in Load average IO-Broker auf Raspberry 4 (8GB):

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

nichts spektakuläres:

sagt mir nichts

Ich meine damit, dass keine Fehlermledung aufgeführt ist.

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

|-/run/user/1000/doc portal fuse.portal rw,nosuid,nodev,relatime,user_id=1000,group_id=

ist aber unter mounts aufgeführt.

Verstehe nicht, was Du meinst. Bitte ausführlichcer.

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

Pending Updates: 4

und wieso

Keine Ahnung, die Installation stammt von gestern, da sollte man eigentlich davon ausgehen können, dass die aktuellen Versionen dabei sind. Aber nichts desto trotz, das kann ja wohl nicht der Grund für die hohe Load average sein.

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

                           1951 iobroker  20   0  729964 157948  37024 S  20,1   2,0   1:04.80 io.shelly.0

braucht shelly so viele Ressourcen?

Ist das viel? JS braucht wenn ich das richtig sehe genauso viel.

ausserdem spammt dir esphome.0 im Sekundentakt das log voll.

Wenn ich shelly und esphome deaktiviere sinkt load nicht signifikant.

Diese IO-Broker Instllation ist meiner Meinung nach noch sehr klein, macht so gut wie nichts und bringt den Rechner an seine Grenzen. Ich frage mich wirklich wie es Leute schaffen, eine load average unter 1 hinzubekommen und IO-Broker macht tatsächlich etwas anderes außer nur da zu sein.

[Thomas Braun]

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

Ich frage mich wirklich wie es Leute schaffen, eine load average unter 1 hinzubekommen und IO-Broker macht tatsächlich etwas anderes außer nur da zu sein.

Kein Problem:

Systemuptime and Load:
 18:39:27 up  4:24,  2 users,  load average: 0.65, 0.52, 0.56
CPU threads: 4

[Meister Mopper]

@wolfgangfb

Hier ein Slave mit 15 Instanzen:

top - 18:45:33 up  7:18,  1 user,  load average: 0,17, 0,20, 0,25
Tasks: 157 total,   2 running, 155 sleeping,   0 stopped,   0 zombie
%CPU(s):  0,7 us,  0,3 sy,  0,0 ni, 98,9 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st

Und der Master mit 40 Instanzen:

top - 18:47:49 up 11 days,  2:45,  2 users,  load average: 0,68, 0,96, 0,99
Tasks:  61 total,   2 running,  59 sleeping,   0 stopped,   0 zombie

[Homoran]

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

JS braucht wenn ich das richtig sehe genauso viel.

wenn es so wäre, würde js wegen komplexer Skripte eigentlich mehr verbrauchen dürfen.
Aber es ist der Controller, der als Schaltzentrale natürlich einiges brauchen darf, aber bei dir deutlich weniger als ein kleiner Schaltersteuernder Adapter.

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

Bitte ausführlichcer.

???

wie denn, wenn mir das nichts sagt.
Was ist das denn für ein mount?

Wenn du erhöhte I/O Aktivitäten hast, sollte man mounts immer besonders im Auge haben.

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

Wenn ich shelly und esphome deaktiviere sinkt load nicht signifikant.

dann qualifiziert sich dieser mount noch mehr für nähere Beobachtung.

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

e Grenzen. Ich frage mich wirklich wie es Leute schaffen, eine load average unter 1 hinzubekommen

Genau umgekehrt solltestcdu denken.
Wenn andere das schaffen, dann hast du irgendwo massiv den Wurm dtin.

[Thomas Braun]

@homoran sagte in Load average IO-Broker auf Raspberry 4 (8GB):

Was ist das denn für ein mount?

Das ist harmlos, das ist der Ersatz für /tmp

[Homoran]

@thomas-braun DANKE!
also nicht viel gelähmter Traffic.

[Homoran]

Also wieder nichts mit I/O.

Allerdings stört mich auch die CPU Auslastung etwas.
in der Liste werden die Prozente auf einen Kern bezogen, oben im Header auf alle 4.
Dort sind 50% used, wären mit dem dicken Daumen zwei komplette Kerne, das würde dann die Load erklären können.
Aber die sehe ich in der Liste nicht.

Gut gerechnet wären es bei gleichmäßiger Verteilung 4 Kerne zu 25%.
Dann wäre eindeutig eine Engstelle heim I/O zu suchen.

[WolfgangFB]

@homoran sagte in Load average IO-Broker auf Raspberry 4 (8GB):

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

e Grenzen. Ich frage mich wirklich wie es Leute schaffen, eine load average unter 1 hinzubekommen

Genau umgekehrt solltestcdu denken.
Wenn andere das schaffen, dann hast du irgendwo massiv den Wurm dtin.

Wo könnte ich denn den Wurm haben? Ich habe eine neue schnelle SD Karte genommen, ein neues Image, eine Neuinstallation from scratch und dann eine Handvoll Adapter istalliert. Außer eine feste IP Adresse anstelle von DHCP habe ich am Raspberry nichts geändert.

[Homoran]

@wolfgangfb sagte in Load average IO-Broker auf Raspberry 4 (8GB):

Außer eine feste IP Adresse anstelle von DHCP

hoffentlich außerhalb der DHCP Range

[WolfgangFB]

Ja, ich habe die IP Adresse außerhalb des DHCP Bereiches eingestellt. Das klappt auch alles.
Ich glaube ich bin dem Problem jetzt ein wenig näher gekommen. Ich bin immer noch der Meinung dass echarts schuld ist.
Mir ist aufgefallen, dass wenn ich morgens den PC neu gestartet habe (er war "nur" im Hybernate Schlafmodus, nicht richtig runtergefahren) die Load average unter 1 war. Innerhalb weniger Minuten ist die dann wieder auf 8 und mehr gestiegen. Dann die Überraschung als ich einmal Firefox (in dem immer ein echarts Fenster offen war) neu gestartet habe. Die Load Average ist schnell auf einen WErt unter 1 gesunken. Sie sieht jetzt z.B. aktuell mit einem geöffnetem echarts Fenster und VIS wie folgt aus:

top - 15:01:00 up 13 min,  3 users,  load average: 0,23, 0,52, 0,51
Tasks: 198 total,   1 running, 197 sleeping,   0 stopped,   0 zombie
%CPU(s):  4,3 us,  1,5 sy,  0,0 ni, 93,9 id,  0,0 wa,  0,0 hi,  0,3 si,  0,0 st
MiB Spch:   7811,2 total,   5853,6 free,   1260,2 used,    855,0 buff/cache
MiB Swap:    100,0 total,    100,0 free,      0,0 used.   6551,0 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
    781 iobroker  20   0 5239524 191088  38264 S   8,9   2,4   2:09.11 iobroker.js-con
   2100 iobroker  20   0  726756 134168  37024 S   3,0   1,7   1:35.93 io.shelly.0
   2178 iobroker  20   0 5152016  96208  39448 S   3,0   1,2   0:32.55 io.esphome.0
   2125 iobroker  20   0  679192  71096  36900 S   2,0   0,9   0:04.57 io.discovery.0
   1892 iobroker  20   0  758916  81892  36676 S   1,7   1,0   0:30.62 io.history.0
   2022 iobroker  20   0  941512 138680  36900 S   1,7   1,7   0:43.85 io.javascript.0
   2232 iobroker  20   0  346032  36804  13888 S   1,7   0,5   0:20.13 esphome
    567 avahi     20   0    7588   3404   2864 S   1,0   0,0   0:08.53 avahi-daemon
   2189 iobroker  20   0  676736  71536  36828 S   1,0   0,9   0:04.48 io.echarts.0
   1992 iobroker  20   0 1017312 141492  43448 S   0,7   1,8   0:18.37 io.admin.0
     15 root      20   0       0      0      0 I   0,3   0,0   0:02.09 rcu_preempt
   2112 pi        20   0    9488   5084   2920 R   0,3   0,1   0:04.76 top
   2242 iobroker  20   0  676492  68528  37056 S   0,3   0,9   0:04.32 io.vis-inventwo
      1 root      20   0  168644  11960   8588 S   0,0   0,1   0:03.23 systemd
      2 root      20   0       0      0      0 S   0,0   0,0   0:00.02 kthreadd

Das ist absolut OK. Was man aber auch sieht ist die Uptime von 13 Minuten. Ich musste den Raspberry hart resetten nachdem ich probeweise ein neues echarts Diagramm (mit 6 Datenquellen) erstellt habe die load auf über 30 gestiegen ist und dann der Raspberry nicht mehr ansprechbar war.
Für mich sieht es so aus, dass ein geöffnetes Firefox echarts Fenster in Zusammenhang mit einem neuen Diagramm den IO-Boroker und/oder den Raspberry extram stark belasten.
Wenn ich alternativ nach jeder neuen Datenquelle das echarts Diagramm speichere, den Firefox beende und neu startet klappt das ganze und die Diagramme lassen sich auch flüssig anschauen.
Das ist zwar nicht sonderlich befriedigend und richtig verstehen tue ich es auch nicht, aber ich habe jetzt wenigstens einen Weg gefunden, wie ich durch stoppen und Neustart des Firefox (der übrigens nicht auf dem Raspberry sondern einem Windows PC läuft) den Raspberry und damit den IO-Broker flüssig laufen lassen kann.
Falls jemand dieses Verhalten erklären kann wäre ich für eine Erklärung dankbar.