Memory leak?
-
das ist ein problem !
-
@liv-in-sky ja. leider habe ich keine Ahnung von Linux. ich kann auch in den angegeben informationen nicht sehen, wo der arbeitsspeicher weg geht. oder kannst du was erkennen?
-
@djsirius irgendwelche auffälligkeiten im iob log oder system log ?
tail -f /var/log/syslogist genug festplattenplatz da - nicht das irgendwelche file (z.b backup) gespeichert werden ...
versuche mal das script aus https://forum.iobroker.net/post/883517 - wird gerade entwickelt und gibt wichtige infos aus
ich sehe gerade keine problem bei deinen posts - wie ist die cpu auslastung (top/htop) auf längere sicht - gibt es einen adapter der immer wieder auf einen hohen cpu wert geht ?
-
@liv-in-sky said in Memory leak?:
tail -f /var/log/syslog
Festplattenspeicher habe ich genug und die Backups werden auf einer USB HDD ausgelagert.
Ich schau mir das Script mal an.
root@debian:/home/iobroker# df -h Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf udev 3,9G 0 3,9G 0% /dev tmpfs 790M 2,5M 788M 1% /run /dev/sda2 454G 24G 407G 6% / tmpfs 3,9G 0 3,9G 0% /dev/shm tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup /dev/sda1 511M 3,4M 508M 1% /boot/efi tmpfs 790M 0 790M 0% /run/user/1000 -
@djsirius und poste dann bitte die ausgabe des scriptes
-
@djsirius wichtig wäre auch zu wissen, wann der exakte start des disasters ist und dann herausfindet, was da gerade läuft - ich weiß: hört sich einfach an, ist aber manchmal extrem schwierig
-
wenn du denkst, die scripte können es nicht sein, läuft backitup evtl und dann "kracht es" - wielange läuft der rechner, bis er wieder stehen bleibt - mehrere tage oder passiert das in einem tag zur selben uhrzeit oder mehrmals am tag
-
=========== Ab hier kopieren ========== *** BASISSYSTEM *** CPU-Architektur: x86_64 Docker: Nein LXC: none Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster Systemuptime und Load: 08:44:07 up 19:44, 1 user, load average: 0,12, 0,19, 0,19 CPU threads: 4 *** Zeit und Zeitzonen *** Fr 4. Nov 07:44:07 UTC 2022 Fr 4. Nov 08:44:07 CET 2022 CET +0100 Europe/Berlin *** User und Gruppen *** iobroker /home/iobroker iobroker tty dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner *** X-Server-Setup *** X-Server: Nein Desktop: Konsole: tty *** ARBEITSSPEICHER *** total used free shared buff/cache available Mem: 7,7Gi 2,8Gi 4,6Gi 5,0Mi 364Mi 4,7Gi Swap: 3,9Gi 0,0Ki 3,9Gi Total: 11Gi 2,8Gi 8,5Gi *** DATEISYSTEM *** Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf udev devtmpfs 3,9G 0 3,9G 0% /dev tmpfs tmpfs 790M 2,5M 788M 1% /run /dev/sda2 ext4 454G 23G 407G 6% / tmpfs tmpfs 3,9G 0 3,9G 0% /dev/shm tmpfs tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup /dev/sda1 vfat 511M 3,4M 508M 1% /boot/efi tmpfs tmpfs 790M 0 790M 0% /run/user/1000 Daten in neuralgischen Verzeichnissen: /var: 3,3G /var/ 2,1G /var/cache/apt 2,1G /var/cache 2,0G /var/cache/apt/archives 667M /var/lib /opt/iobroker/backups: 68M /opt/iobroker/backups/ /opt/iobroker/iobroker-data: 813M /opt/iobroker/iobroker-data/ 400M /opt/iobroker/iobroker-data/files 337M /opt/iobroker/iobroker-data/backup-objects 58M /opt/iobroker/iobroker-data/files/scenes.admin/static/js 58M /opt/iobroker/iobroker-data/files/scenes.admin/static Die 5 größten Dateien in iobroker-data: 23M objects.jsonl 18M objects.json.migrated 18M objects.json.bak.migrated 7,9M states.jsonl 4,1M states.json.migrated *** Nodejs-Installation *** /usr/bin/nodejs v16.18.0 /usr/bin/node v16.18.0 /usr/bin/npm 8.19.2 nodejs: Installiert: 16.18.0-deb-1nodesource1 Installationskandidat: 16.18.0-deb-1nodesource1 Versionstabelle: *** 16.18.0-deb-1nodesource1 500 500 https://deb.nodesource.com/node_16.x buster/main amd64 Packages 100 /var/lib/dpkg/status 10.24.0~dfsg-1~deb10u2 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages 500 http://deb.debian.org/debian-security buster/updates/main amd64 Packages 10.24.0~dfsg-1~deb10u1 500 500 http://ftp.de.debian.org/debian buster/main amd64 Packages 500 http://deb.debian.org/debian buster/main amd64 Packages *** ioBroker-Installation *** Versionsnummern der Kern-Adapter js-controller: 4.0.23 Admin-Adapter: 6.2.23 ioBroker-Repos und Updates stable : http://download.iobroker.net/sources-dist.json beta : http://download.iobroker.net/sources-dist-latest.json Active repo(s): stable Used repository: stable Objekte und Zustände werden ermittelt - Dies kann einen Moment dauern. Objekte: 23443 Zustände: 18574 *** Repositories und OS-Updates *** OK:1 http://deb.debian.org/debian buster InRelease OK:2 http://ftp.de.debian.org/debian buster InRelease OK:3 http://security.debian.org/debian-security buster/updates InRelease OK:4 http://deb.debian.org/debian-security buster/updates InRelease OK:5 http://ftp.de.debian.org/debian buster-updates InRelease OK:6 http://deb.debian.org/debian buster-updates InRelease OK:7 https://deb.nodesource.com/node_16.x buster InRelease OK:8 http://deb.debian.org/debian buster-backports InRelease OK:9 https://packages.sury.org/php buster InRelease OK:10 https://packagecloud.io/ookla/speedtest-cli/debian buster InRelease Paketlisten werden gelesen... Fertig Ausstehende Updates: *** Lauschende Ports *** Aktive Internetverbindungen (Nur Server) Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 1000 734935 12109/iobroker.js-c tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 1000 735672 12109/iobroker.js-c tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 0 21642 814/smbd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 12578 1/init tcp 0 0 192.168.1.16:2001 0.0.0.0:* LISTEN 1000 737352 12309/io.hm-rpc.0 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 16353 491/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 1899266 9569/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 19588 804/exim4 tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 0 21641 814/smbd tcp6 0 0 :::8000 :::* LISTEN 1000 1613850 15065/io.upnp.0 tcp6 0 0 :::139 :::* LISTEN 0 21640 814/smbd tcp6 0 0 :::111 :::* LISTEN 0 12582 1/init tcp6 0 0 :::80 :::* LISTEN 0 21582 815/apache2 tcp6 0 0 :::8081 :::* LISTEN 1000 735714 12134/io.admin.0 tcp6 0 0 :::8082 :::* LISTEN 1000 742937 15389/io.web.0 tcp6 0 0 :::8084 :::* LISTEN 1000 738218 14148/io.socketio.0 tcp6 0 0 :::22 :::* LISTEN 0 16355 491/sshd tcp6 0 0 ::1:631 :::* LISTEN 0 1899265 9569/cupsd tcp6 0 0 :::8087 :::* LISTEN 1000 739935 13922/io.simple-api tcp6 0 0 :::8088 :::* LISTEN 1000 742564 14530/io.terminal.0 tcp6 0 0 ::1:25 :::* LISTEN 0 19589 804/exim4 tcp6 0 0 :::443 :::* LISTEN 0 21586 815/apache2 tcp6 0 0 :::445 :::* LISTEN 0 21639 814/smbd udp 0 0 0.0.0.0:68 0.0.0.0:* 0 19051 504/dhclient udp 0 0 0.0.0.0:111 0.0.0.0:* 0 12579 1/init udp 0 0 192.168.1.255:137 0.0.0.0:* 0 19720 530/nmbd udp 0 0 192.168.1.16:137 0.0.0.0:* 0 19719 530/nmbd udp 0 0 0.0.0.0:137 0.0.0.0:* 0 19705 530/nmbd udp 0 0 192.168.1.255:138 0.0.0.0:* 0 19722 530/nmbd udp 0 0 192.168.1.16:138 0.0.0.0:* 0 19721 530/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 0 19706 530/nmbd udp 0 0 0.0.0.0:53421 0.0.0.0:* 1000 738385 12384/io.mihome-vac udp 0 0 0.0.0.0:631 0.0.0.0:* 0 1901805 9570/cups-browsed udp 0 0 0.0.0.0:41860 0.0.0.0:* 112 17706 416/avahi-daemon: r udp 0 0 192.168.1.16:5353 0.0.0.0:* 1000 740325 14501/io.tr-064.0 udp 0 0 0.0.0.0:5353 0.0.0.0:* 112 17704 416/avahi-daemon: r udp 0 0 0.0.0.0:1900 0.0.0.0:* 1000 742957 15065/io.upnp.0 udp6 0 0 :::47018 :::* 112 17707 416/avahi-daemon: r udp6 0 0 :::111 :::* 0 12585 1/init udp6 0 0 :::5353 :::* 112 17705 416/avahi-daemon: r =========== Bis hier kopieren =========== -
mir fällt nix auf - außer "buster" gehört upgedatet - sollte keine ursache für das problem sein
und du nutzt einen user iobroker - das ist eigentlich der service account des iobrokers - weiß nicht wirklich, ob das gut ist, aber sollte auch nicht das problem sein@liv-in-sky sagte in Memory leak?:
wielange läuft der rechner, bis er wieder stehen bleibt - mehrere tage oder passiert das in einem tag zur selben uhrzeit oder mehrmals am tag
was ist damit ?
@thomas-braun siehst du was ?
-
@liv-in-sky Der Rechner läuft unterschiedlich lange, bzw. es ist keine Regelmäßigkeit zu erkennen. Manchmal läuft er 7 Tage und manchmal eben nur 2 Tage.
-
@djsirius weiß du den letzten absturz zeitpunkt ? es gibt meist mehrere syslog files unter /var/log
dort könnte man mal schauen, was zu desem zeitpunkt war
-
-
@thomas-braun ich mag dein neues script
-
@liv-in-sky Da ist doch gar nicht so viel in 'Grün' drin?
-
@liv-in-sky said in Memory leak?:
@djsirius weiß du den letzten absturz zeitpunkt ? es gibt meist mehrere syslog files unter /var/log
dort könnte man mal schauen, was zu desem zeitpunkt war
Ich mache seit einiger Zeit regelmäßig einen reboot, weil ich mir nicht anders zu helfen wusste.
-
Schau halt in die Logs rein.
-
@djsirius sagte in Memory leak?:
@liv-in-sky said in Memory leak?:
@djsirius weiß du den letzten absturz zeitpunkt ? es gibt meist mehrere syslog files unter /var/log
dort könnte man mal schauen, was zu desem zeitpunkt war
Ich mache seit einiger Zeit regelmäßig einen reboot, weil ich mir nicht anders zu helfen wusste.
ich glaube, ich kann dir nicht helfen, wenn ich keine daten habe, wann genau was wo passiert - bisher kann ich keine großen themen auf deinem system sehen/erkennen
vielleicht fällt jmd anderes was auf -
@liv-in-sky said in Memory leak?:
@djsirius sagte in Memory leak?:
@liv-in-sky said in Memory leak?:
@djsirius weiß du den letzten absturz zeitpunkt ? es gibt meist mehrere syslog files unter /var/log
dort könnte man mal schauen, was zu desem zeitpunkt war
Ich mache seit einiger Zeit regelmäßig einen reboot, weil ich mir nicht anders zu helfen wusste.
ich glaube, ich kann dir nicht helfen, wenn ich keine daten habe, wann genau was wo passiert - bisher kann ich keine großen themen auf deinem system sehen/erkennen
vielleicht fällt jmd anderes was aufok, vielen Dank!
-
Da sich das Problem über die Zeit entwickelt, kann man aus einer Sicht auf einen einzelnen Zeitpunkt keine Informationen ableiten.
Beobachte mal den speicherverbrauch der einzelnen Prozesse über die Zeit. Also so über 1/2 Tage immer wieder mal die Werte aufschreiben. Theoretisch könntest du das per copy Paste nach excel kopieren
Bei den meisten Fällen liegt es hier, wie du schon geschrieben hast an ein oder mehreren Skripten im js adapter.
Wenn der konkrete Prozess eingegrenzt ist, können wir hier weiter analysieren.
Wie hast du deine Skripte überprüft? Kennst du dich gut mit JS aus?
Wieviele Skripte hast du?
Ggfs. könnten wir hier mal drüberschauen.
Aber erst wenn wir es wissen das es der js Adapter ist -
@djsirius Hallo,
sowas habe ich auch. Allerdings nur sehr sichtbar, wenn ein bestimmter Adapter startet. Dann bin ich beim RAM direkt bei 200 MB frei bis noch weniger (50 MB)
Bei mir ist das der Slideshow, issue ist eröffnet und mit Dutchman zusammen konnte ich es reproduzieren. Den Adapter hab ich momentan gestoppt und so läufts erst mal stabil.Grüße Maschine20
