NEWS
iobroker Absturz
-
Sollte ich eigentlich meinen Swap vergrößern?
top - 19:12:20 up 23:10, 1 user, load average: 0.22, 0.42, 0.62 Tasks: 192 total, 1 running, 191 sleeping, 0 stopped, 0 zombie %Cpu(s): 8.3 us, 2.2 sy, 0.0 ni, 89.1 id, 0.1 wa, 0.0 hi, 0.2 si, 0.0 st MiB Mem : 3790.9 total, 442.0 free, 2595.2 used, 827.2 buff/cache MiB Swap: 200.0 total, 0.6 free, 199.4 used. 1195.7 avail Mem
-
@pb74 sagte in iobroker Absturz:
Sollte ich eigentlich meinen Swap vergrößern?
ich halte das für Blödsinn bei
@pb74 sagte in iobroker Absturz:
1195.7 avail Mem
@pb74 sagte in iobroker Absturz:
load average: 0.22, 0.42, 0.62
sieht richtig gut aus!
-
Hallo zusammen,
ich war schon euphorisch und wollte sagen "Problem gelöst", aber am Donnerstag 30.01. gegen Abend blieb das System wieder hängen.
Bis dato hatte ich mehrfach auch von Arbeit aus per VPN und SSH die Werte per top kontrolliert, es war alles i.O.
Um 18:54 Uhr wurde das automatische Update des Repositorys gestartet; danach gibt es keine Protokolleinträge mehr.
Am 31.01. finden sich ab ca. 05:30 Uhr wieder Einträge im Protokoll, jede Menge Fehler und Warnmeldungen. Ab ca. 05:35 Uhr gibt es keine Fehler mehr, nur noch zwei Warnungen:
a)
hm-rega.0 (275505) State value to set for "hm-rega.0.10636" has value "10600.135039" greater than max "8800"
(der Max-Wert wurde inzwischen angepasst)
b)
javascript.0 (275428) script.js.common.DWD_Radarbild_holen: Fehler bei https://www.dwd.de/DWD/wetter/sat/satwetter/njob_satrad.png : AxiosError: stream has been aborted
Nun läuft alles wieder als wäre nichts gewesen ....
Hab grade noch das OS und auf Nodejs 20 geupdatet, mal schauen....Habt ihr vielleicht noch einen Ansatzpunkt für mich?
Danke schon mal !
-
Nach dem Neustart werden im Protokoll folgende Fehler + Warnungen angezeigt:
hm-rega.0 2025-02-01 16:30:16.783 warn State value to set for "hm-rega.0.10636" has value "10619.301721" greater than max "8800" hm-rega.0 2025-02-01 16:24:16.470 warn State value to set for "hm-rega.0.10636" has value "10618.885054" greater than max "8800" hm-rega.0 2025-02-01 16:23:41.027 error CCU 192.168.xxx.xxx unreachable hm-rega.0 2025-02-01 16:23:41.027 error post request error: Aborted due to timeout hm-rega.0 2025-02-01 16:23:41.008 warn "!# alarms.fn!#!# Dieses Homematic-Script gibt eine Liste aller Alarm-Datenpunk" timed out after 90 seconds sourceanalytix.0 2025-02-01 16:23:32.193 warn Cannot handle calculations for 1 of 2 enabled states, check error messages sourceanalytix.0 2025-02-01 16:23:32.182 error Initialization of modbus.0.inputRegisters.32332_Energie_EM1 failed, check warn messages ! sourceanalytix.0 2025-02-01 16:23:32.180 error Cannot handle calculations for modbus.0.inputRegisters.32332_Energie_EM1, check log messages and adjust settings! sourceanalytix.0 2025-02-01 16:23:32.180 error No cost type defined for modbus.0.inputRegisters.32332_Energie_EM1, please Select Type of calculation at state setting vis-2.0 2025-02-01 16:23:10.778 error No license found for vis-2. Please get one on https://iobroker.net !
Offensichtlich hat meine "Anpassung" des Objekts hm-reg.0.10636 nichts gebracht, denn nach dem Neustart steht der Max-Wert wieder auf 8800.
Es handelt sich hierbei um den Wert eines Scriptes, das auf meiner CCU3 (IP 192.168.xxx.xxx) läuft und die Betriebsstunden eines Lüfters wiedergibt.
Offensichtlich wird der Max-Wert irgendwie in dem CCU-Script mit "8800" beschrieben...wo das passiert muss ich noch rausfinden.Lässt sich zu den anderen Fehlern eurerseits etwas sagen?
-
@pb74 sagte in iobroker Absturz:
Habt ihr vielleicht noch einen Ansatzpunkt für mich?
Ich habe ein ähnliches Problem, mein System läuft ab und zu mal Amok, mit einer sehr hohen Auslastung im load average, allerdings habe ich keinerlei Fehlermeldungen. Ich hab mir ein kleines Script für die Konsole geschrieben, um das Problem Zeitlich eingrenzen zu können.
#!/bin/bash # Dateiname loadAverage_v2.sh # setze Dateiberechtigung für Benutzer # sudo chmod u+x loadAverage_v2.sh while true; do uptime >> /home/xxxx/bin/load_average.log sleep 60 done
Seit dem ich das Script rund um die Uhr laufen lasse, ist der Amoklauf des Systems nur einmal aufgetreten, wie immer ohne jegliche Fehlermeldung.
-
@binarie, danke für Deinen Tipp.
Da ich nicht so der Programmierer bin, könntest Du mir bitte erläutern, was Dein Script macht?
EDIT: Wie lange läuft dieses Script schon bei Dir?
-
@pb74 sagte in iobroker Absturz:
Da ich nicht so der Programmierer bin, könntest Du mir bitte erläutern, was Dein Script macht?
Das schreibt alle 60 Sekunden die Ausgabe von
uptime
in eine Text-Datei.Mehr macht es nicht.
-
@pb74 sagte in iobroker Absturz:
EDIT: Wie lange läuft dieses Script schon bei Dir?
Es läuft jetzt vier Tage, das Ergebnis bei hoher Auslastung :
16:34:02 up 2 days, 22:50, 2 users, load average: 4,17, 4,87, 4,15 16:35:02 up 2 days, 22:51, 2 users, load average: 4,30, 4,74, 4,14 16:36:02 up 2 days, 22:52, 2 users, load average: 6,52, 5,19, 4,32 16:37:02 up 2 days, 22:53, 2 users, load average: 7,28, 5,52, 4,48 16:38:02 up 2 days, 22:54, 2 users, load average: 7,16, 5,70, 4,60 16:39:02 up 2 days, 22:55, 2 users, load average: 7,31, 5,90, 4,72 16:40:02 up 2 days, 22:56, 2 users, load average: 6,34, 5,79, 4,75 16:41:02 up 2 days, 22:57, 2 users, load average: 6,07, 5,74, 4,80 16:42:02 up 2 days, 22:58, 2 users, load average: 6,05, 5,71, 4,84 16:43:02 up 2 days, 22:59, 2 users, load average: 5,82, 5,65, 4,86
Normale Auslastung:
1:10:04 up 3 days, 3:26, 2 users, load average: 0,21, 0,30, 0,39 21:11:04 up 3 days, 3:27, 2 users, load average: 0,12, 0,26, 0,37 21:12:04 up 3 days, 3:28, 2 users, load average: 0,24, 0,26, 0,36 21:13:04 up 3 days, 3:29, 2 users, load average: 0,09, 0,21, 0,34 21:14:04 up 3 days, 3:30, 2 users, load average: 0,03, 0,17, 0,31 21:15:04 up 3 days, 3:31, 2 users, load average: 0,08, 0,15, 0,29 21:16:04 up 3 days, 3:32, 2 users, load average: 0,03, 0,12, 0,27 21:17:04 up 3 days, 3:33, 2 users, load average: 0,05, 0,11, 0,26 21:18:04 up 3 days, 3:34, 2 users, load average: 0,02, 0,09, 0,24 21:19:04 up 3 days, 3:35, 2 users, load average: 0,00, 0,07, 0,22 21:20:04 up 3 days, 3:36, 2 users, load average: 0,36, 0,14, 0,24 21:21:04 up 3 days, 3:37, 2 users, load average: 0,55, 0,25, 0,27
-
Ich habe mir /home/[mein Benutzername] dieses Script per nano mit dem von Dir angegebenen Dateinamen angelegt und mit
sudo chmod u+x loadAverage_v2.sh
ausführbar gemacht. Im WinSCP konnte ich auch sehen, wie in den Rechten das "x" gesetzt wurde.
Danach habe ich das Script mit
./loadAverage_v2.sh
gestartet. Es hat mir auch die Datei angelegt und die ersten zwei Werte reingeschrieben.
Danach hab ich putty beendet und nun schreibt das Script nicht weiter.... ich hab bestimmt jede Menge falsch gemacht...das Script soll ja ständig laufen.Ich bitte schon mal um Entschuldigung für die ganzen Anfängerfragen, aber das ist "mein erstes Mal", das ich auf diese Art und Weise unter Linux mit Scripten arbeite.
Vielleicht kann mir jemand weiterhelfen, bevor ich mir noch mein System zerlege...
Dankeschön
-
@pb74 sagte in iobroker Absturz:
Danach hab ich putty beendet und nun schreibt das Script nicht weiter
Logisch. Wenn der user abgemeldet wird werden auch dessen Prozesse abgebrochen.
Entweder machst du da einen systemd-Service draus, lässt das Ding im Hintergrund inscreen
laufen oder (was ich für einfacher halte) jubelst es dem user iobroker unter und lässt es dort laufen. Das muss dann nur noch in dessen Startup-Konfig eingetragen werden, wenn das dauerhaft laufen soll.Wobei sich mir offengesagt der Sinn von dem Skript nicht erschließt. Ich würde eher im journal schauen, was da passiert.
-
@thomas-braun sagte in iobroker Absturz:
Ich würde eher im journal schauen, was da passiert.
Wie würde das funktionieren?
-
-
@binarie Wenn Du das Script automatisch starten lässt, hast Du das in /etc/init.d gemacht?
EDIT: Hab den Aufruf des Scripts jetzt in rc.local realisiert; funktioniert...
Mal schauen, ob die Aufzeichnung der
uptime
irgendwelche Schlüsse zulässt, warum der iobroker stehen bleibt. -
Nochmal eine Frage zu
top
:Nach dem Neustart (zwecks Test zum Autostart uptime-Script) werden folgende Werte ausgegeben:
top - 13:40:48 up 50 min, 1 user, load average: 0.83, 0.70, 0.56 Tasks: 197 total, 4 running, 193 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.5 us, 0.7 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st MiB Mem : 3790.9 total, 146.3 free, 2018.9 used, 1698.4 buff/cache MiB Swap: 200.0 total, 197.7 free, 2.2 used. 1772.0 avail Mem
Lt. der Zeile zum Swap-Speicher sind nur 2.2 MB von 200 MB in Benutzung. Mir ist aufgefallen, das an manchmal wenig Speicher benutzt wird und dann wiederum kaum noch Speicher frei ist; siehe z.B. diesen Post:
Wenn von den 200 MB kaum noch etwas frei ist, dann ist das doch auch nicht so günstig, oder? Vielleicht kann mir jemand das bitte mal näher erläutern, eventuell verstehe ich das ja auch falsch...
Danke schon mal...
-
@pb74 Der SWAP sollte eigentlich überhaupt nicht genutzt werden!
Das ist ein Notfallüberlauf falls zuwenig RAM zur Verfügung (available) steht. -
Momentan sieht es so aus:
Linux iobroker001 6.6.74+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) top - 10:27:22 up 21:36, 1 user, load average: 0.27, 0.40, 0.49 Tasks: 193 total, 1 running, 192 sleeping, 0 stopped, 0 zombie %Cpu(s): 10.1 us, 1.6 sy, 0.0 ni, 87.4 id, 0.2 wa, 0.0 hi, 0.7 si, 0.0 st MiB Mem : 3790.9 total, 801.9 free, 2011.1 used, 1051.3 buff/cache MiB Swap: 200.0 total, 4.5 free, 195.5 used. 1779.8 avail Mem
Das würde dann bedeuten, das der Arbeitsspeicher nicht gereicht hat und der Swap benutzt wurde.
Wird der Swap mal wieder geleert? Wenn nicht, kann es dann wenn der Arbeitsspeicher wieder nicht ausreichend ist das Problem geben, das das System wieder nicht reagiert? Klärt mich bitte mal auf....Danke schonmal
-
@pb74 sagte in iobroker Absturz:
Das würde dann bedeuten, das der Arbeitsspeicher nicht gereicht hat und der Swap benutzt wurde.
Wird der Swap mal wieder geleert?Der SWAP dient zur kurzfristigen Auslagerung bei Bedarf und leert sich über die Zeit auch wieder.
Jedenfalls wenn die Ausstattung mit RAM ansonsten ausreichend dimensioniert ist. SWAP soll nicht permanent knallevoll sein. Dann ist generell zu wenig RAM vorhanden/es laufen zu viele Prozesse.