RAM-Probleme und Abstürze nach Wechsel auf 64-Bit
-
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.
-
@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.
-
@robson liegt dein Raspi einfach so rum oder ist er "eingebaut"?
-
@ro75
Er ist in einem Passiven-Kühlkörper-Gehäuse eingebaut. Überhitzung war bisher auch im Sommer nie ein Problem. -
@robson hast du bitte mal ein Bild davon?
-
@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. -
@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.
-
@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 -
@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.
-
@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.
-
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? -
@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.
- Richte SWAP ein bzw. wenn bereits vorhanden - vergrößern.
- Adapter "ausmisten" und ggfs. durch JS ersetzen (SNMP, Ping, ODL , Luftdaten, WOL) geht ohne Probleme.
- Adapter mit geleichen Funktionen (mit enthalten) nutzen.
EDIT: Bei 38 JS würde ich schauen ob das noch was optimiert werden kann.
-
@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 -
-
@kanumouse Wie schon erwähnt geht Dir der RAM aus.
Wenn das Backup startet braucht es zusätzlich RAM und friert Dir dann Dein System ein.
Nicht benötigte Instanzen deaktivieren könnte helfen aber auf Dauer für Dich vll eher keine Lösung. -
@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
Hier mal das Ergebnis von iob diag.
wird schon knapp mit dem RAM.
Aber mich wundert mehr
@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
Active repo(s): Stable (default)
gut so, und dann
@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
Adapters from github: 15
warum?
-
@homoran
Einige Adapter sind auf „Stable“ nicht zu bekommen. -
@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
@homoran
Einige Adapter sind auf „Stable“ nicht zu bekommen.auch nicht auf beta?
github ist immer die allerletzte Wahl
-
@homoran und dann vorallem 15 an der Zahl, sind dann schon viele seltene/neue Adapter
-
@crunchip
Von den „Github“-Adaptern macht aber keiner Probleme,soweit ich das hinsichtlich der Speicherauslastung beurteilen kann.
Im Übrigen liefen die auch alle problemlos unter meinem vorhergehenden 32-Bit Buster (keine Lite-Version, sogar mit Desktop) und es war immer noch genügend freier Speicher verfügbar.
Eine Frage zum Vergleich hätte ich zu dieser Thematik aber noch.
Mein Javascript-Adapter belegt relativ viel Speicherplatz (fast 0,5 GB). Ist das im Vergleich normal? Das Stoppen einzelner Java-Programme hat zu keinem wesentlich geringeren Speicherbedarf geführt. Und alle Java-Programme hatte ich ja hinsichtlich des Einflusses auf den Speicherbedarf gecheckt.
