backup reduziert ram free sehr stark und dauerhaft

Begonnen von heinzfo, 26 September 2020, 20:01:30

Vorheriges Thema - Nächstes Thema

heinzfo

Kann das kern.log gerne hier posten, bin aber unsicher ob die Inhalte sicherheitsrelevant sind?

Wernieman

Nur c.a. 1 Minute vor/nachher ....

Gerne kern.log per PM, aber eigentlich sollte es nicht sicherheitsrelevantes enthalten

Btw. Bitte auch fhem log
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

heinzfo

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.

Wernieman

Zwischen den 1. und 3. Oktober hast Du keine anderen Einträge im kern.log???????

Wie groß ist eigentlich Dein Backup ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

heinzfo

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

Wernieman

Was passiert, wenn Du die Kommandos des Backups direkt ausführst?

Btw: Wie voll ist Dein speicherträger?
df -h
df -i
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

heinzfo

#21
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

heinzfo

#22
Meinst Du mit backup direkt, das commando backup in den text input von FHEMWEB eingeben?

Wernieman

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????
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

heinzfo

#24
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

Wernieman

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?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rudolfkoenig

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.

Wernieman

Aber FHEM sollte dann nicht mit "Out of Memory" Kollabieren ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rudolfkoenig

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

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html