Hallo
Ich habe seit einigen Monaten folgendes Problem.
Ein FHEM backup reduziert den RAM free von 2600Mbit auf 177Mbit.
Mit 'free' auf der SSH sieht man die Reduzierung am angestiegenen 'buff/cache' von 688Mbit auf 2590Mbit.
Das passiert auch wenn ich eine backup Datei ...tag.gz (305Mbit) mit z.B. FileZilla vom Rpi 4 auf meine NAS kopiere.
Hier ist die Reduzierung des RAM free von 2760Mbt auf 2405Mbit man sieht den anstieg am 'buff/cache' 171Mbit auf 490Mbit.
Das belibt so bis ich FHEM neu starte.
Was kann das sein?
Das FHEM und Rasperry - Buster Update ist von heute.
Grüße, Heinz
Free bezeichnet die Menge des Speichers, was unnuetz herumliegt.
Linux versucht den Speicher sinnvoll zu belegen, z.Bsp. mit dem gelesenen/geschriebenen Daten (buff/cache), damit diese nicht nochmal von der Platte gelesen muessen, falls sie wieder nachgefragt werden.
In einem sinnvoll verwendeten Linux wird free nach eine Weile sehr klein, das bedeutet aber lange keine Speicherknappheit, da der Platz mit gecacheten Daten jederzeit genutzt werden kann. Siehe auch "available" in neueren free Varianten, oder +-buffers/cache bei den Aelteren.
Mal zum durchlesen:
https://www.pc-erfahrung.de/linux/administration/linux-systemauslastung-analysieren.html (https://www.pc-erfahrung.de/linux/administration/linux-systemauslastung-analysieren.html)
Hallo Wernieman
Danke für den link zu diesem sehr informativen Beitrag!
Ich habe mit top und free mein System angesehen und kann nichts ungewöhnliches entdecken.
Ich dache erst, das der Logfile eintrag 'Out of memory!' daher kommen könnte.
Der Eintrag kommt zu unterschiedlichen Zeiten und korreliert auch nicht mit einer bestimmten FHEM Aktion, so lese ich das zu mindest aus dem Logfile, FHEM bleibt dann stehen und ich muss es manuel neu starten.
Ich habe jetzt alle möglichen Module die auf das Internet zugreifen disabled auch FRITZBOX das hilft aber nicht.
Bin ratlos was ich noch tun kann.
Grüße
Heinz
Was sagt das kern.log und syslog zu der Zeit, wenn FHEM stehenbleibt?
ZU finden unter "/var/log" (bei normalen Unix-Systemen)
In den files 'kern.log - kern.log.4' gibt es leider keine Einträge zur entsprechenden Uhrzeit. :-|
Im September ist es sechs mal vorgekommen, kein Eintrag passt zu den kern.log files.
Kannst Du uns mal die komplette "free" Ausgabe zum Fehlerzeitpunkt geben?
Ich melde mich wenn der Fehler wieder vorhanden ist.
Danke
Gerade ist es passiert!
Zum ersten mal sehe ich 'Out of memory!' kurz hintereinander.
fhem.log
2020.10.03 11:43:33 1: FHEMWEB SSL/HTTPS error: SSL accept attempt failed (peer: 192.168.178.36)
2020.10.03 12:48:58 3: CUL_HM set KellerVierKanalSchalter_Sw_01 on-for-timer 3
2020.10.03 12:49:38 3: CUL_HM set KellerVierKanalSchalter_Sw_02 on-for-timer 0.5
Out of memory!
2020.10.03 12:50:13 1: FRITZBOX FB7590: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
Out of memory!
free
Sa 3. Okt 13:09:54 CEST 2020
total used free shared buff/cache available
Mem: 3919812 199532 3484700 6472 235580 3584308
Swap: 102396 21768 80628
Kann es an der Kernel version liegen ?
Sa 3. Okt 13:13:24 CEST 2020
Linux raspberrypi3fhem 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux
free im Fehlerzusatnd, FHEM not running
Sa 3. Okt 13:35:29 CEST 2020
total used free shared buff/cache available
Mem: 3919812 197536 3486488 6468 235788 3586320
Swap: 102396 21768 80628
free nach dem starten von FHEM
pi@raspberrypi3fhem:/opt/fhem/backup $ sudo /etc/init.d/fhem start
Starting fhem...
pi@raspberrypi3fhem:/opt/fhem/backup $ date; free
Sa 3. Okt 13:40:26 CEST 2020
total used free shared buff/cache available
Mem: 3919812 350324 3290908 6476 278580 3433364
Swap: 102396 21768 80628
Im Anhang die Chart von ran used und free von SYSMON
Grüße, Heinz
Und es steht nichts im syslog oder kern.log?
Und .. wie machst Du backup?
Hallo
Keine Einträge zum Zeitpunkt von 'Out of memory!' in beiden Dateien, auch nicht annähernd um diese Urzeit.
Backup mache ich über die FHEMWEB Oberfläche, siehe Anhang.
Grüße, Heinz
Auch keine "OOM" Eintrage?
Die free-Einträge sehen jedenfalls nicht schlecht aus.
Btw:
Hast Du IO-Probleme?
grep -i i/o /var/log/kern.log
Nichts von beiden :-|
kein oom oder i/o in den logs
Backup ins gleiche Dateisystem? SDCard oder per USB?
Kannst Du mir ein Log-Abzug der Zeit vom kern.log mir geben? Kann es mir aktuell wirklich nicht vorstellen ....
In das gleiche Dateisystem, aber eine HDD am USB des Rpi als SD Ersatz, booten über die SD Card.
Kann das kern.log gerne hier posten, bin aber unsicher ob die Inhalte sicherheitsrelevant sind?
Nur c.a. 1 Minute vor/nachher ....
Gerne kern.log per PM, aber eigentlich sollte es nicht sicherheitsrelevantes enthalten
Btw. Bitte auch fhem log
fhem.log
2020.10.03 11:43:33 1: FHEMWEB SSL/HTTPS error: SSL accept attempt failed (peer: 192.168.178.36)
2020.10.03 12:48:58 3: CUL_HM set KellerVierKanalSchalter_Sw_01 on-for-timer 3
2020.10.03 12:49:38 3: CUL_HM set KellerVierKanalSchalter_Sw_02 on-for-timer 0.5
Out of memory!
2020.10.03 12:50:13 1: FRITZBOX FB7590: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
Out of memory!
2020.10.03 13:36:12 1: PERL WARNING: Subroutine trim redefined at ./FHEM/99_myUtils.pm line 261.
2020.10.03 13:36:12 1: PERL WARNING: Subroutine ltrim redefined at ./FHEM/99_myUtils.pm line 269.
2020.10.03 13:36:12 1: PERL WARNING: Subroutine rtrim redefined at ./FHEM/99_myUtils.pm line 276.
2020.10.03 13:36:12 1: Including fhem.cfg
kern.log
Oct 1 21:27:54 raspberrypi3fhem kernel: [134333.656426] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Oct 3 21:45:44 raspberrypi3fhem kernel: [ 0.000000] Booting Linux on physical CPU 0x0
syslog
Oct 3 11:17:01 raspberrypi3fhem CRON[21692]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 3 11:50:14 raspberrypi3fhem systemd[1]: Started Session c4 of user pi.
Oct 3 12:06:09 raspberrypi3fhem systemd[1]: session-c4.scope: Succeeded.
Oct 3 12:17:01 raspberrypi3fhem CRON[25343]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 3 13:07:01 raspberrypi3fhem systemd[1]: Started Session c5 of user pi.
Oct 3 13:07:26 raspberrypi3fhem systemd[1]: Started Session c6 of user pi.
Oct 3 13:07:51 raspberrypi3fhem systemd[1]: Started Session c7 of user pi.
Oct 3 13:17:02 raspberrypi3fhem CRON[27883]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 3 13:23:59 raspberrypi3fhem systemd[1]: session-c7.scope: Succeeded.
Zwischen den 1. und 3. Oktober hast Du keine anderen Einträge im kern.log???????
Wie groß ist eigentlich Dein Backup ....
Nein, dazwischen sind keine Einträge!
Das backup tar.gz hat 314MB, sind halt die ganzen logfiles drin, die ich gerne rausnehmen bzw. separat sichern würde.
Grüße, Heinz
Was passiert, wenn Du die Kommandos des Backups direkt ausführst?
Btw: Wie voll ist Dein speicherträger?
df -h
df -i
Immer wenn der value von free klein (500MB) und used groß (3200MB) ist, ist FHEM stehen geblieben 'out of memory!', so nach 6Std. free klein.
Ich habe gleich nach dem Neustart von FHEM ein backup gemacht um den RAM free klein zu bekommen (500MB).
Jetzt läuft es schon 23Std.
RAM used steigt weiterhin mit ca. 80MB/Std, mal sehen was passiert wenn used wieder bei 3200MB angekommen ist.
-rw-r--r-- 1 fhem dialout 301M Okt 3 22:24 FHEM-20201003_221922.tar.gz
pi@raspberrypi3fhem:/opt/fhem/backup $ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 30G 14G 15G 50% /
devtmpfs 1,8G 0 1,8G 0% /dev
tmpfs 2,0G 0 2,0G 0% /dev/shm
tmpfs 2,0G 18M 1,9G 1% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 2,0G 0 2,0G 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 52M 201M 21% /boot
tmpfs 391M 8,0K 391M 1% /run/user/1000
/dev/sda1 60M 21M 40M 35% /media/pi/boot
pi@raspberrypi3fhem:/opt/fhem/backup $ df -i
Dateisystem Inodes IBenutzt IFrei IUse% Eingehängt auf
/dev/root 1938272 415990 1522282 22% /
devtmpfs 117760 476 117284 1% /dev
tmpfs 183808 1 183807 1% /dev/shm
tmpfs 183808 729 183079 1% /run
tmpfs 183808 4 183804 1% /run/lock
tmpfs 183808 14 183794 1% /sys/fs/cgroup
/dev/mmcblk0p1 0 0 0 - /boot
tmpfs 183808 21 183787 1% /run/user/1000
/dev/sda1 0 0 0 - /media/pi/boot
Meinst Du mit backup direkt, das commando backup in den text input von FHEMWEB eingeben?
Läuft eigentlich irgendetwas anderes außer FHEM auf dem PI?
Mit oder Ohne Desktop?
Mich erstaunt, das FHEM 4G so schnell "voll" bekommen soll ..... bzw. warum eigentlich "nur" 3,2G????
Bei RAM used 3.2G ist noch Luft nach oben, max 3.9G
Ja, mit Desktop, sonnst läuft nichts.
Wenn ich den Desktop nicht mehr brauche, gehe ich auf 'Shutdown > Abmelden', ob das den Desktop beendet weiß ich nicht.
Die Meldung 'out of memory!' finde ich seit Juli 2020 im FHEM logfile.
Chart im Anhang.
1. FHEM neu gestartet
2. Start backup
3. backup beendet
Auch wenn Du abgemeldet bist, verbraucht der Desktop RAM (vereinfacht gesagt). Auch von der Sicherheit, Updateschwierigkeit etc. ist vom Desktop dringend abzuraten. Brauchst Du den wirklich?
Da FHEM auf 1G PIs läuft, hast Du auf Deiner Kiste ein Problem und ich komme nicht drauf ....
Hat noch jemand eine Idee?
ZitatHat noch jemand eine Idee?
Da ich die Diskussion nicht genau verfolgt habe, weiss ich nicht genau, um welchen free es sich handelt, ich vermute, es geht um das "Sinnlose" (nicht buffer/cache bereinigte), was insb. Linux-Unkundige ignorieren sollten.
Wenn ja, das waere einfach zu erklaeren: wenn das Backup 300MB ist, und bei Textdateien gzip einen Komprimierungsfaktor von 5-10 schafft, musste der Linux-Kernel fuers Backup 1.5 bis 3GB von der Festplatte lesen. Das verbleibt im RAM (Cache), fuer den Fall, dass der Benutzer nochmal auf die Idee kommt, ein Backup zu machen.
Da kann man sich abmelden, soviel man will, das hilft nicht. Uebrigens gilt das auch fuer alle anderen Dateien, z.Bsp. die fuers Desktop notwendige Programme und Bilder, etc. Eine Ursachenforschung, was alles im Cache ist, ist muehselig, und mAn sinnlos.
Aber FHEM sollte dann nicht mit "Out of Memory" Kollabieren ....
Stimmt, ich meine aber, dass die gezeigten Grafiken nichts damit zu tun haben: die sind fuer mich damit erklaerbar, dass Programme Dateien schreiben und/oder lesen. "available" in der free Ausgabe nach dem "Out of memory!" (und bei hoffentlich noch nicht abgeschossenen FHEM) spricht auch fuer diese Hypothese. Und ist ein Gegenargument fuer die Hypothese, dass einer der FHEM-Module ein Speicherloch hat.
Evtl. ist die Speichergroesse per limit beschraenkt, siehe "ulimit -a".
im chart von beitrag #24 macht "ram total" bei fhem restart einen sprung.
wie kann so etwas passieren?
habe ich noch nie gesehen.
war das wirklich ein fhem restart, oder eher ein reboot vom pi?
ist die HW ein pi4 mit 4GB ram?
der prompt "pi@raspberrypi3fhem" iritiert mich ein wenig.