Monatsrückblick Januar/Februar 2026 ist online!

[robson]

@wildbill sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:

@robson Dann würde ich es jetzt einmal komplett neu installieren (wer weiss, was das wiederholte Steckerziehen bereits angercihtet hat), iobroker neu drauf aus dem Backup und erst einmal ohne influx beobachten, wie es sich verhält. Wenn Du das eh noch nicht nutzst, dann lass es mal weg. Wenn der RAM dann reicht, hast Du den Übeltäter, wenn nicht, dann kannst Du das zumindest ausschließen.

Gruss, Jürgen

Danke dir. Ich habe jetzt erst mal Influx und Grafana stillgelegt. Mal schauen, ob das System jetzt wieder stabil rennt.

Ich hatte Grafana und Influx 1 ja auch auf meinem 32-Bit System stabil laufen. Ich konnte/kann mir irgendwie einfach nicht vorstellen, dass die 64-Bit Varianten solch einen Speicherhunger haben und - obwohl nicht aktiv genutzt - RAM von 300-500 MB zusätzlich allokieren.

[Thomas Braun]

@robson

Tendenziell sind 64bit-Anwendungen etwas speicherhungriger, weil der adressierbare Adressraum auch viel größer ist.

[robson]

Mir ist mein System letzte Nacht trotz deaktivierter InfluxDB-Instanz und einer minimalen Anzahl an laufenden Adaptern wieder abgestürzt.

Ich würde nun vorerst wieder auf 32 Bit wechseln wollen - damit lief alles stabil. Sogar mit InfluxDB v1 im Hintergrund.

Weiß jemand, ob es ein Problem darstellt, wenn der Kernel auf 64-Bit, das OS aber nun auf 32-Bit läuft? Ein Downgrade des Kernels scheint nicht leicht zu sein habe ich gelesen.

[Thomas Braun]

@robson sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:

wenn der Kernel auf 64-Bit, das OS aber nun auf 32-Bit läuft?

Wie willst du da hinfummeln?
Installier es neu. Allerdings wird es kein ursächliches Problem mit der 64bit-Version sein.

[robson]

@thomas-braun
Ich installiere es auch gerade neu. Aber der Kernel bleibt doch auf 64-Bit auch wenn ich ein neues OS auf die SD-Karte aufspiele oder nicht?
Sobald es läuft, frage ich die Kernelversion mal ab.

[Thomas Braun]

@robson sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:

Aber der Kernel bleibt doch auf 64-Bit auch wenn ich ein neues OS auf die SD-Karte aufspiele oder nicht?

Warum sollte der Kernel stehen bleiben? Wenn das komplett neuinstalliert wird, dann kommt auch der Kernel aus dem Installationsmedium mit.

[robson]

@thomas-braun
Du hast Recht. Ich dachte, die Kernelinformation seien in den RAM geschrieben worden. Wieder was dazu gelernt.

[robson]

Hallo zusammen,

leider ist mein Raspi wieder ohne ersichtlichen Grund abgestürzt. Ich hatte meine SSD vergangenen Montag komplett neu formatiert und das 32-Bit OS installiert. Danach ioBroker. Nach Einspielen des Backups (1-2 Std Wartezeit) waren noch knapp 900 MB frei und alles lief reibungslos.
Nachmittags sind wir bis eben in den Urlaub gefahren. Bereits am Abend konnte ich nicht mehr auf ioBroker (weder Web UI noch SSH) zugreifen. InfluxDB und Grafana waren nicht installiert - lediglich ioBroker mit meinem Backup.

Ich kann es mir dieses Mal nicht mit einem Speicherengpass erklären.
Hat jemand eine Idee, was ich noch prüfen kann?
Es ist bereits der zweite Pi 4B mit 2GB, den ich angeschlossen habe.

Alternativ würde ich ioBroker auf einer Synology NAS per Docker installieren. Das ist aber Neuland für mich. Mit dem Raspi war ich bisher immer gut zufrieden.

Für Hinweise bin ich dankbar.

[Thomas Braun]

@robson sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:

Es ist bereits der zweite Pi 4B mit 2GB, den ich angeschlossen habe.

2GB ist meiner Meinung nach die unterste Grenze, da muss man aber schon was genauer schauen. Ich würde mindestens 4GB vorsehen.

[Ro75]

@robson liegt dein Raspi einfach so rum oder ist er "eingebaut"?

[robson]

@ro75
Er ist in einem Passiven-Kühlkörper-Gehäuse eingebaut. Überhitzung war bisher auch im Sommer nie ein Problem.

[Ro75]

@robson hast du bitte mal ein Bild davon?

[robson]

@ro75
Es ist zwar nicht meiner, jedoch nutze ich exakt dieses Gehäuse

Die Wäremeleitpads wurden erst vor ein paar Wochen von mir erneuert.

[Ro75]

@robson OK, ich frage darum. Ich hatte mir für meine Raspi bei Geekworm ein Gehäuse gekauft gehabt. Schick verbaut inkl. SSD. Dann fingen die Probleme bei mir an. So wie bei dir beschrieben. Zuerst dachte ich, Speicherfehler - getstet - OK. Dann einen anderen Raspi dort eingebaut (der lief bisher ohne Probleme). Und der zeigte plötzlich die selben Fehler.

Kurz und knapp. Raspi's raus aus dem Gehäuse - also nackig - und siehe da die liefen wieder völlig problemlos.

Ro75.

[robson]

@ro75
Danke dir. In meinem Fall würde ich das Gehäuse ausnehmen. Meine Installation lief seit 2019-2020 sehr stabil - auch in den heißen Sommertagen. Mein Raspi steht leider im Dachgeschoss - hohe Temperaturen.

Ich habe gerade das Log vom Tag des letzten Absturzes exportiert. Die Vis-Instanz taucht hier relativ häufig auf (ist aber aktuell deaktiviert). Zudem auch andere Fehler. Kann dies eine Ursache sein?

2023-04-04 04:17:16.003 - error: admin.0 (665) admin.0 already running
2023-04-04 04:17:16.007 - warn: admin.0 (665) Terminated (ADAPTER_ALREADY_RUNNING): Without reason
2023-04-04 04:17:16.659 - info: host.iobroker-raspi4 instance system.adapter.javascript.0 started with pid 749
2023-04-04 04:17:16.882 - error: host.iobroker-raspi4 instance system.adapter.admin.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING)
2023-04-04 04:17:16.883 - info: host.iobroker-raspi4 Restart adapter system.adapter.admin.0 because enabled
2023-04-04 04:17:17.433 - info: host.iobroker-raspi4 iobroker npm-install: NPM version: 8.19.3
2023-04-04 04:17:17.434 - info: host.iobroker-raspi4 iobroker npm-install: Installing iobroker.vis@1.4.15... (System call)
2023-04-04 04:17:20.783 - info: host.iobroker-raspi4 instance system.adapter.telegram.0 started with pid 780
2023-04-04 04:17:21.055 - error: javascript.0 (749) javascript.0 already running
2023-04-04 04:17:21.060 - warn: javascript.0 (749) Terminated (ADAPTER_ALREADY_RUNNING): Without reason
2023-04-04 04:17:21.821 - error: host.iobroker-raspi4 instance system.adapter.javascript.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING)
2023-04-04 04:17:21.822 - info: host.iobroker-raspi4 Restart adapter system.adapter.javascript.0 because enabled
2023-04-04 04:17:24.703 - error: telegram.0 (780) telegram.0 already running
2023-04-04 04:17:24.709 - warn: telegram.0 (780) Terminated (ADAPTER_ALREADY_RUNNING): Without reason
2023-04-04 04:17:24.743 - info: host.iobroker-raspi4 instance system.adapter.alexa2.0 started with pid 852
2023-04-04 04:17:25.450 - error: host.iobroker-raspi4 instance system.adapter.telegram.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING)
2023-04-04 04:17:25.452 - info: host.iobroker-raspi4 Restart adapter system.adapter.telegram.0 because enabled
2023-04-04 04:17:27.342 - error: alexa2.0 (852) alexa2.0 already running
2023-04-04 04:17:27.347 - warn: alexa2.0 (852) Terminated (ADAPTER_ALREADY_RUNNING): Without reason
2023-04-04 04:17:28.081 - error: host.iobroker-raspi4 instance system.adapter.alexa2.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING)
2023-04-04 04:17:28.083 - info: host.iobroker-raspi4 Restart adapter system.adapter.alexa2.0 because enabled
2023-04-04 04:17:28.689 - info: host.iobroker-raspi4 instance system.adapter.hm-rega.0 started with pid 875
2023-04-04 04:17:29.186 - info: vis.0 (860) starting. Version 1.4.15 in /opt/iobroker/node_modules/iobroker.vis, node: v16.19.1, js-controller: 4.0.24
2023-04-04 04:17:29.676 - error: vis.0 (860) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2023-04-04 04:17:29.678 - error: vis.0 (860) unhandled promise rejection: Not exists
2023-04-04 04:17:29.680 - error: vis.0 (860) Error: Not exists
at Object.maybeCallbackWithError (/opt/iobroker/node_modules/@iobroker/js-controller-common/lib/common/tools.js:2983:17)
at ObjectsInRedisClient._readFile (/opt/iobroker/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:1043:26)
at Immediate. (/opt/iobroker/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:1092:29)
at processImmediate (node:internal/timers:468:21)
2023-04-04 04:17:29.681 - error: vis.0 (860) Not exists
2023-04-04 04:17:30.187 - info: vis.0 (860) terminating
2023-04-04 04:17:30.189 - warn: vis.0 (860) Terminated (UNCAUGHT_EXCEPTION): Without reason
2023-04-04 04:17:31.002 - error: host.iobroker-raspi4 iobroker npm-install: host.iobroker-raspi4 Cannot install iobroker.vis@1.4.15: 6
2023-04-04 04:17:31.351 - error: hm-rega.0 (875) hm-rega.0 already running
2023-04-04 04:17:31.355 - warn: hm-rega.0 (875) Terminated (ADAPTER_ALREADY_RUNNING): Without reason
2023-04-04 04:17:32.023 - error: host.iobroker-raspi4 instance system.adapter.hm-rega.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING)
2023-04-04 04:17:32.024 - info: host.iobroker-raspi4 Restart adapter system.adapter.hm-rega.0 because enabled
2023-04-04 04:17:32.116 - info: host.iobroker-raspi4 iobroker npm-install: exit 25
2023-04-04 04:17:32.650 - info: host.iobroker-raspi4 instance system.adapter.hm-rpc.0 started with pid 886
2023-04-04 04:17:33.117 - warn: host.iobroker-raspi4 startInstance cannot find adapter "vis@1.4.15". Try to install it... 2 attempt
2023-04-04 04:17:33.118 - info: host.iobroker-raspi4 iobroker install vis@1.4.15 using installedFrom
2023-04-04 04:17:34.943 - error: hm-rpc.0 (886) hm-rpc.0 already running
2023-04-04 04:17:34.948 - warn: hm-rpc.0 (886) Terminated (ADAPTER_ALREADY_RUNNING): Without reason

[Homoran]

@robson sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:

Meine Installation lief seit 2019-2020 sehr stabil

ist kein Grund die Temperatur grundsätzlich nicht als Grund zu sehen.

[DJMarc75]

@robson wenn der Kühlkörper nicht zu 100% auf dem zu kühlenden Bauteil aufliegt dann gibts da auch keine effektive Kühlung mehr. Das würde ich mal prüfen.

[Kanumouse]

Hi,
ich muss mich hier an dieser Stelle hinsichtlich der RAM-Auslastung auch einmal einklinken. Ich hatte mein System (lief 2 Jahre stabil) von der 32-Bit Buster-Version auf eine 64-Bit Bullseye-Version umgestellt (Neuinstallation mit Backup-Einspielung). Seidem habe ich eine hohe Speicherauslatung (nur noch 8-10% frei). Ich habe ca. 47 Instanzen und 38 Javaprogramme zu laufen. Sowohl die Instanzen auch als die Java-Programme habe ich hinsichtlich des Einflusses auf den Speicherbedarf schon gecheckt. Top und htop zeigen auch keine Auffälligkeiten hinsichtlich des Speicherbedarfs aus meiner Sicht.
Die hohe Speicherauslastung bei meinem Pi 4 mit 4GB Ram führt insbesondere beim iobroker-Backup mit Backuitup zum Systemabsturz. Iobroker wird dann neu gestartet und im im Logfile finde ich dann Einträge das beim Wiederstart der Instanzen diese schon laufen.
Die freie RAM-Kapazität von ca. 8% erscheint mir sehr wenig bei meiner Installation und scheint beim Backup zum Systemabsturz zu führen.
Gibt es eventuell noch hilfreiche Tipps, wo ich noch Fehler suchen kann?
Wie ist die „normale“ RAM-Auslastung bei vergleichbaren Installationen?

[Ro75]

@kanumouse Was für ein System hast du denn? Grundsätzlich benötigt die 64Bit-Variante etwas meht Speicher. Bei meinem 4GB Raspi war dann bei der Anzahl der Adapter auch irgendwann das Limit erreicht.

Ich hatte 3 Varianten für mich zur Lösung.

1. Richte SWAP ein bzw. wenn bereits vorhanden - vergrößern.
2. Adapter "ausmisten" und ggfs. durch JS ersetzen (SNMP, Ping, ODL , Luftdaten, WOL) geht ohne Probleme.
3. Adapter mit geleichen Funktionen (mit enthalten) nutzen.

EDIT: Bei 38 JS würde ich schauen ob das noch was optimiert werden kann.

[DJMarc75]

@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:

Ich habe ca. 47 Instanzen

@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:

Pi 4 mit 4GB Ram

das ist zu wenig RAM für 47 Instanzen... oder andersrum - zu viele Instanzen für 4 GB RAM

zeig doch mal

iob diag