RAM-Probleme und Abstürze nach Wechsel auf 64-Bit
-
@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.
-
@robson ja, dein RAM ist knapp, der Swap auch schon benutzt.
was sagt
topzum Bedarf der nicht iobroker Programme? -
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 -
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 -
@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. -
@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
-
@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.
-
Tendenziell sind 64bit-Anwendungen etwas speicherhungriger, weil der adressierbare Adressraum auch viel größer ist.
-
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.
-
@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. -
@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. -
@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.
-
@thomas-braun
Du hast Recht. Ich dachte, die Kernelinformation seien in den RAM geschrieben worden. Wieder was dazu gelernt. -
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.
