Monatsrückblick Januar/Februar 2026 ist online!

[domvo]

Ich habe mal spaßeshalber Grafana (in Verbindung mit InfluxDB und Telegraf) auf meinem RPi installiert. Der Pi ist für nichts anderes zuständig außer ioBroker und macht hier im großen und ganzen folgendes:

• Anwesenheitserkennung zweier Haushaltsmitglieder via Radar2.0 und TR-064.
• Philips Hue Integration mit Yahka ("Hey Siri, Licht an im Wohnzimmer").
• Heizungssteuerung via FritzDect (gekoppelt an Anwesenheit und Zeit).
• Paar Spielereien, wie blinkende Hue lights bei eingehendem Anruf.
• In Summe 7 Javascript Scripts.

Hier ein paar Grafana Screenshots, die vertikale Linie ("Annotation") zeigt einen Reboot. Die Screenshots stellen allesamt ein Zeitfenster von 10 Tagen dar.

CPU Load 1m und 15m avg:

Man sieht, dass nach 4-5 Tagen ziemlich wilde (und wilder werdende) Peaks entstehen.

CPU Load 15m avg nochmal isoliert:

Und hier nochmal Memory Usage über 10 Tage:

Auch hier sieht man eine stetige Steigerung.

Wenn ich mir Youtube Videos ansehe oder auch hier im Forum Beispielinstanzen anschaue, dann würde ich eigentlich sagen, ich unterfordere den Pi mit meinem paar läppischen Anwendungsfällen eigentlich. Und tatsächlich scheint das in den ersten Tagen auch gut zu sein, aber ich finde es sehr schade, dass das so instabil läuft.

Wie schon in der Überschrift erwähnt läuft der ioBroker auf einem Raspberry Pi 4 4GB Model B.

Hier noch der iobroker info Output:

Platform       : linux
os             : linux
Architecture   : arm
CPUs           : 4
Speed          : 1500 MHz
Model          : ARMv7 Processor rev 3 (v7l)
RAM            : 3.7 GB
System uptime  : 7d. 13:35:48
Node.js        : v12.19.0
Disk size      : 58.3 GiB
Disk free      : 53.1 GiB
adapters count : 326
NPM            : v6.14.

iobroker list adapters

system.adapter.admin                   : admin          - v4.2.1
system.adapter.chromecast              : chromecast     - v2.3.1
system.adapter.cloud                   : cloud          - v4.0.4
system.adapter.discovery               : discovery      - v2.5.0
system.adapter.fb-checkpresence        : fb-checkpresence - v1.1.0
system.adapter.fritzdect               : fritzdect      - v0.2.4
system.adapter.history                 : history        - v1.9.10
system.adapter.hue                     : hue            - v3.3.8
system.adapter.hue-extended            : hue-extended   - v2.0.0
system.adapter.influxdb                : influxdb       - v1.9.3
system.adapter.info                    : info           - v1.7.14
system.adapter.javascript              : javascript     - v4.8.4
system.adapter.lgtv                    : lgtv           - v1.1.10
system.adapter.mobile                  : mobile         - v1.0.1
system.adapter.openweathermap          : openweathermap - v0.1.0
system.adapter.ping                    : ping           - v1.4.12
system.adapter.pushover                : pushover       - v2.0.3
system.adapter.radar2                  : radar2         - v2.0.1
system.adapter.rpi2                    : rpi2           - v1.2.0
system.adapter.simple-api              : simple-api     - v2.5.2
system.adapter.socketio                : socketio       - v3.1.4
system.adapter.sonos                   : sonos          - v2.1.1
system.adapter.tr-064                  : tr-064         - v4.2.2
system.adapter.vis                     : vis            - v1.3.4
system.adapter.vis-hqwidgets           : vis-hqwidgets  - v1.1.7
system.adapter.web                     : web            - v3.2.3
system.adapter.yahka                   : yahka          - v0.12.

Der Adapters Count scheint mir recht hoch zu sein, aber da habe ich keine Vergleichswerte.

Habt ihr ähnliche Beobachtungen gemacht? Braucht ihr weitere Infos zur Diagnose?

[Thomas Braun]

@domvo Und wo genau besteht jetzt ein Problem?
Stürzt irgendwas ab?

[domvo]

@thomas-braun ich bilde mir ein, dass er nach und nach etwas langsamer wird. Außerdem habe ich einen Lüfter am Pi dran, der anspringt, wenn die CPU Temp über 60° geht und das passiert nach 4-5 Tagen merklich häufiger als in den ersten Tagen nach einem Reboot.

Ich habe aber nicht direkt Ausfälle oder gar Abstürze zu vermelden. Viel mehr macht mich das stutzig und gewissermaßen sind das ja auch irgendwie "red flags".

[Thomas Braun]

@domvo Ich sehr da nix ungewöhnliches.

[David G.]

Bei mir sieht es ganz ähnlich aus.
Mit der Zeit gehen CPU und RAM etwas hoch.
Nur ist meine Grundausstattung noch was höher.
Nach ein paar Tagen hat er sich dann eingependelt.

Finde ich aber auch plausibel.

[Dr. Bakterius]

@domvo Vielleicht liegt es an einem Skript? Wäre nicht das erste Mal, dass jemand vergessen hat einen Timer zu stoppen und so immer mehr Code läuft und CPU und Speicher belastet. Allerdings bemerkt man die Auswirkungen meist nach kürzerer Zeit als bei dir.

[domvo]

Also ich muss mich hier nochmal zu Wort melden. Wenn ich den Pi nicht alle paar Tage reboote, dann habe ich inzwischen Load Spitzen von 36!

Also irgendwo gibt es massive "leaks", denn das bin ich sonst von Unixoiden Systemen nicht gewöhnt. Hat vielleicht noch jemand Anregungen, woran das liegen könnte? :-/

[hans_999]

@domvo

Wie hat sich denn die Speicherauslastung weiter entwickelt? Im Eingangströöt hast du gezeigt, dass innerhalb einer Woche die Auslastung von ca. 1GB auf 1,6 GB gestiegen ist.

Das jetzige Bild zeigt nur einen kurzen Zeitausschnitt mit kurzen (nicht periodischen und nicht gleichmäßigen) Peaks. Diese können durch alles Mögliche kommen (z.B. Visualisierung, Grafana, Datenspeicherung, ....). Auf ein Memory-Leak würde ich nicht unbedingt tippen. Warum sollte das die CPU strapazieren?
Wie hat sich denn die CPU-Auslastung seit 7.2. entwickelt?

Was sagen denn die typischen Diagnosen wie "top"?

[domvo]

Ich wollte mich nochmal melden, weil das ich Problem endlich in den Griff bekommen habe. Evtl. hilft das ja auch anderen mit einem ähnlichen Problem.

Der Übeltäter scheint tatsächlich der Radar 2.0 Adapter zu sein. Der Adapter startet extrem viele Instanzen des hcitools. Genau genommen handelt es sich um dieses Kommando hier, festgestellt via ps aux.

/usr/bin/hcitool -i hci0 lescan --duplicates

Die Einstellungen im Radar 2.0 sind eigentlich alle auf default, daher weiß ich nicht genau, woran es liegt, aber es wurden Berge an "Prozessleichen" produziert, die nach und nach die Ressourcen auffressen. Ich habe in meinem root crontab zwei Einträge, die ein mal am Tag (nachts um 1) alle hcitool Prozesse killen:

0 1 * * * pkill hcitool

Das habe ich vor ca. 10 Tagen so implementiert und es hatte einen positiven Einfluss auf sämtliche Metriken, hier ein paar Beispiele, wir betrachten die letzten 30 Tage.