Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[robson]

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

Kann es nicht eher sein, dass influx2 mehr braucht?

Ja, das habe ich auch schon gedacht. Bisher speichere ich aber keine Daten zwischen und nutze es faktisch nicht. Ich möchte erst das System wieder stabilisieren.

[Homoran]

@robson ja, dein RAM ist knapp, der Swap auch schon benutzt.

was sagt top zum Bedarf der nicht iobroker Programme?

[robson]

@homoran

Wenn ich das korrekt interpretiere, dann belegt der influxdb-Prozess ca. 5% des Speichers.
Da der JS-Controller eine Menge Speicher benötigt, habe ich auch hier schon einige Skripte gestoppt. Aktuell laufen 17 Stück.

top - 18:18:51 up  2:42,  1 user,  load average: 0.20, 0.30, 0.30
Tasks: 160 total,   1 running, 159 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.8 us,  0.4 sy,  0.0 ni, 97.5 id,  0.1 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :   1848.2 total,    289.4 free,   1158.0 used,    400.8 buff/cache
MiB Swap:    100.0 total,      0.1 free,     99.9 used.    622.2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    701 iobroker  20   0  989596 172688  36796 S   4.6   9.1  12:36.64 iobroker.js-con
    929 iobroker  20   0  953024 173988  36316 S   1.7   9.2   4:14.31 io.javascript.0
    945 iobroker  20   0  871300  81812  32044 S   1.0   4.3   0:34.93 io.telegram.0
   1027 iobroker  20   0  651552  72176  31536 S   0.7   3.8   0:23.48 io.hm-rpc.0
   3490 iobroker  20   0  781508  78020  37660 S   0.7   4.1   0:07.48 io.tankerkoenig
   3525 pi        20   0   10012   3252   2668 R   0.7   0.2   0:00.11 top
     99 root     -51   0       0      0      0 S   0.3   0.0   0:22.75 irq/37-mmc0
    631 influxdb  20   0 1418004 101124  16940 S   0.3   5.3   1:30.87 influxd
    993 iobroker  20   0  661108  79808  31612 S   0.3   4.2   0:40.87 io.hm-rega.0
   1143 iobroker  20   0  658480  78852  31692 S   0.3   4.2   1:15.09 io.tr-064.0
   2217 pi        20   0   16072   4968   3724 S   0.3   0.3   0:00.06 sshd
   3478 root      20   0       0      0      0 I   0.3   0.0   0:01.57 kworker/1:2-events_freezable
      1 root      20   0  165224   7696   5192 S   0.0   0.4   0:02.62 systemd
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.03 kthreadd
      3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp
      4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp
      5 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 slub_flushwq
      6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 netns
      8 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/0:0H-kblockd
     10 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 mm_percpu_wq
     11 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tasks_kthread
     12 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tasks_rude_kthread
     13 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tasks_trace_kthread
     14 root      20   0       0      0      0 S   0.0   0.0   0:00.49 ksoftirqd/0
     15 root      20   0       0      0      0 I   0.0   0.0   0:04.21 rcu_preempt
     16 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 migration/0
     17 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/0
     18 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/1
     19 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 migration/1
     20 root      20   0       0      0      0 S   0.0   0.0   0:00.18 ksoftirqd/1
     22 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/1:0H-kblockd
     23 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/2
     24 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 migration/2
     25 root      20   0       0      0      0 S   0.0   0.0   0:00.18 ksoftirqd/2
     27 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/2:0H-kblockd
     28 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/3
     29 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 migration/3
     30 root      20   0       0      0      0 S   0.0   0.0   0:00.16 ksoftirqd/3
     32 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/3:0H-events_highpri
     33 root      20   0       0      0      0 S   0.0   0.0   0:00.01 kdevtmpfs
     34 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 inet_frag_wq
     36 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kauditd
     38 root      20   0       0      0      0 S   0.0   0.0   0:00.00 khungtaskd
     40 root      20   0       0      0      0 S   0.0   0.0   0:00.00 oom_reaper
     41 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 writeback
     42 root      20   0       0      0      0 S   0.0   0.0   0:02.59 kcompactd0
     43 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kintegrityd
     44 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kblockd
     45 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 blkcg_punt_bio
     46 root     -51   0       0      0      0 S   0.0   0.0   0:00.00 watchdogd
     49 root       0 -20       0      0      0 I   0.0   0.0   0:00.23 kworker/3:1H-kblockd
     50 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rpciod
     51 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 xprtiod
     55 root      20   0       0      0      0 S   0.0   0.0   0:02.39 kswapd0
     56 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 nfsiod
     57 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kthrotld
     65 root      20   0       0      0      0 S   0.0   0.0   0:00.00 hwrng
     66 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 iscsi_conn_clea
     67 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 nvme-wq
     68 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 nvme-reset-wq
     69 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 nvme-delete-wq
     71 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 DWC Notificatio
     72 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 uas
     73 root       1 -19       0      0      0 S   0.0   0.0   0:00.00 vchiq-slot/0
     74 root       1 -19       0      0      0 S   0.0   0.0   0:00.00 vchiq-recy/0
     75 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 vchiq-sync/0
     76 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 zswap-shrink
     77 root       0 -20       0      0      0 I   0.0   0.0   0:00.03 kworker/u9:0-hci0
     98 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 sdhci
    100 root      20   0       0      0      0 S   0.0   0.0   0:00.00 scsi_eh_0
    101 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 scsi_tmf_0
    102 root       0 -20       0      0      0 I   0.0   0.0   0:00.22 kworker/1:1H-kblockd
    103 root       0 -20       0      0      0 I   0.0   0.0   0:00.22 kworker/0:1H-kblockd
    104 root       0 -20       0      0      0 I   0.0   0.0   0:00.38 kworker/2:1H-kblockd
    105 root      20   0       0      0      0 S   0.0   0.0   0:00.88 jbd2/sda2-8
    106 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 ext4-rsv-conver
    107 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 mld
    108 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 ipv6_addrconf

[Thomas Braun]

@robson

Fahr die Kiste IMMER sauber herunter.
Dann schredderst du dir auch nicht das Dateisystem wie hier:

[Sun Mar 26 15:35:57 2023] EXT4-fs (sda2): orphan cleanup on readonly fs
[Sun Mar 26 15:35:57 2023] EXT4-fs (sda2): 2 orphan inodes deleted

[robson]

@thomas-braun
Mache ich auch normalerweise.
Jedoch scheint das System bei extremen Speichermangel abzustürzen und nicht mehr ansprechbar zu sein. Per SSH konnte ich das System nicht erreichen. Bisher hat immer nur Steckerziehen geholfen.

[Wildbill]

@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

[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.