RAM-Probleme und Abstürze nach Wechsel auf 64-Bit
-
@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. -
@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
Mein Javascript-Adapter belegt relativ viel Speicherplatz (fast 0,5 GB). Ist das im Vergleich normal?
woher hast du diesen Wert?
belegt er das oder ist das nur reserviert?@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
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.
hier ebenfalls: wie hast du das gecheckt?
sind da keinerlei scheduled Javascripte dabei, die "irgendwann" Ressourcen brauchen?gleiches gilt für Instanzen.
-
Das ist der Wert, der hinter den Instanzen steht.
Und die Java-Programme habe ich gestoppt, um sicher zu gehe, dass keines irgendwelche Probleme verursacht, nachdem ich sie vorher aber noch einmal kontrolliert hatte.
-
@kanumouse ein 64-bit System braucht nicht zwangsläufig mehr Ram, allerdings mit neueren Versionen einzelner Adapter kann und wird es dazu führen, mehr Ram zu benötigen. Mehr Qualität, mehr Leistung, andere Bibliotheken, andere Libraries
ein windows 10/11 braucht ja mittlerweile auch mehr an Leistung und Speicher als damals XP@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
Das Stoppen einzelner Java-Programme hat zu keinem wesentlich geringeren Speicherbedarf geführt
war halt das/die entsprechenden Scripte nicht dabei
@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
Und alle Java-Programme hatte ich ja hinsichtlich des Einflusses auf den Speicherbedarf gecheckt.
wie?
-
@crunchip
Alle Programme gestoppt, einzeln wieder in Betrieb genommen und den Einfluß auf den freien Speicher beobachtet. Ich habe auch keine Programme, die in einer Schleife festhängen. -
@kanumouse sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
Alle Programme gestoppt, einzeln wieder in Betrieb genommen und den Einfluß auf den freien Speicher beobachtet.
naja, mache scripte laufen möglicherweise ja mit
@homoran sagte in RAM-Probleme und Abstürze nach Wechsel auf 64-Bit:
scheduled Javascripte dabei, die "irgendwann" Ressourcen brauchen?
