Speicherverbrauch steigt mit der Zeit

MegaV0lt · Jun 3rd 2020

Mir ist schon vor langer Zeit aufgefallen, dass der VDR (oder ein Plugin) Speicher verbraucht. Beim Start ligt der VDR noch bei 12% und steigt dann stetig an, bis sogar der Swap verwendet wird. Meistens nach 5 oder 6 Stunden.

Hier mal 30 Minuten. ps_mem.py wird alle 10 Minuten gestartet:

Display Spoiler

Code

20-06-03 11:37 - ./checkmem.sh Start
 Private  +   Shared  =  RAM used    Program

144.0 KiB +  22.5 KiB = 166.5 KiB    init
148.0 KiB +  46.5 KiB = 194.5 KiB    logger
196.0 KiB +  25.5 KiB = 221.5 KiB    acpid
192.0 KiB +  30.5 KiB = 222.5 KiB    cron
288.0 KiB +  91.5 KiB = 379.5 KiB    irexec
284.0 KiB + 100.5 KiB = 384.5 KiB    rpcbind
348.0 KiB +  55.5 KiB = 403.5 KiB    grep
308.0 KiB + 125.5 KiB = 433.5 KiB    nalu_stat.sh
288.0 KiB + 160.0 KiB = 448.0 KiB    sftp-server (2)
340.0 KiB + 111.5 KiB = 451.5 KiB    xwatch.sh
340.0 KiB + 112.5 KiB = 452.5 KiB    rec_not_complet
348.0 KiB + 109.5 KiB = 457.5 KiB    gg_startapp.sh
252.0 KiB + 216.5 KiB = 468.5 KiB    xinit
364.0 KiB + 110.5 KiB = 474.5 KiB    g2v_netmount.sh
368.0 KiB + 106.5 KiB = 474.5 KiB    gg_g2vgui.sh
364.0 KiB + 111.5 KiB = 475.5 KiB    check_df.sh
368.0 KiB + 110.5 KiB = 478.5 KiB    vdsb.sh
392.0 KiB + 108.5 KiB = 500.5 KiB    g2v_automount.s
344.0 KiB + 179.5 KiB = 523.5 KiB    runvdr
332.0 KiB + 200.0 KiB = 532.0 KiB    sleep (4)
432.0 KiB + 109.5 KiB = 541.5 KiB    lircd
340.0 KiB + 277.5 KiB = 617.5 KiB    unclutter
596.0 KiB +  38.5 KiB = 634.5 KiB    rpc.idmapd
652.0 KiB +  21.5 KiB = 673.5 KiB    dhcpcd
576.0 KiB + 105.5 KiB = 681.5 KiB    dbus-daemon
644.0 KiB + 151.5 KiB = 795.5 KiB    chronyd
760.0 KiB + 108.5 KiB = 868.5 KiB    rpc.statd
664.0 KiB + 262.0 KiB = 926.0 KiB    su (2)
872.0 KiB + 237.0 KiB =   1.1 MiB    agetty (6)
  1.0 MiB + 490.5 KiB =   1.5 MiB    ratpoison
  1.2 MiB +   1.0 MiB =   2.2 MiB    console-kit-daemon
  2.4 MiB +  43.5 KiB =   2.4 MiB    udevd
  2.0 MiB + 822.5 KiB =   2.8 MiB    nmbd
  2.1 MiB + 991.5 KiB =   3.1 MiB    bash (7)
  2.6 MiB +   1.0 MiB =   3.6 MiB    screen-4.6.1 (6)
  2.5 MiB +   1.4 MiB =   3.9 MiB    syslog-ng (2)
  2.6 MiB +   2.1 MiB =   4.7 MiB    sshd (4)
  9.2 MiB +   1.2 MiB =  10.4 MiB    epghttpd
  6.5 MiB +   4.9 MiB =  11.3 MiB    smbd (4)
 10.3 MiB +   1.1 MiB =  11.5 MiB    fail2ban-server
 14.9 MiB +   1.3 MiB =  16.2 MiB    polkitd
 15.2 MiB +   1.4 MiB =  16.6 MiB    epgd
 43.1 MiB +   6.8 MiB =  49.9 MiB    Xorg
 73.0 MiB +   5.7 MiB =  78.8 MiB    markad (2)
282.3 MiB + 994.5 KiB = 283.3 MiB    mysqld
378.1 MiB +  98.5 KiB = 378.1 MiB    vdradmind
440.4 MiB +  10.8 MiB = 451.2 MiB    vdr
---------------------------------
                          1.3 GiB
=================================
 Private  +   Shared  =  RAM used    Program

144.0 KiB +  21.5 KiB = 165.5 KiB    init
148.0 KiB +  44.5 KiB = 192.5 KiB    logger
196.0 KiB +  25.5 KiB = 221.5 KiB    acpid
192.0 KiB +  29.5 KiB = 221.5 KiB    cron
288.0 KiB +  91.5 KiB = 379.5 KiB    irexec
284.0 KiB +  99.5 KiB = 383.5 KiB    rpcbind
348.0 KiB +  52.5 KiB = 400.5 KiB    grep
308.0 KiB + 117.5 KiB = 425.5 KiB    nalu_stat.sh
288.0 KiB + 158.0 KiB = 446.0 KiB    sftp-server (2)
340.0 KiB + 106.5 KiB = 446.5 KiB    rec_not_complet
340.0 KiB + 106.5 KiB = 446.5 KiB    xwatch.sh
348.0 KiB + 104.5 KiB = 452.5 KiB    gg_startapp.sh
368.0 KiB +  99.5 KiB = 467.5 KiB    gg_g2vgui.sh
252.0 KiB + 216.5 KiB = 468.5 KiB    xinit
364.0 KiB + 105.5 KiB = 469.5 KiB    check_df.sh
364.0 KiB + 106.5 KiB = 470.5 KiB    g2v_netmount.sh
368.0 KiB + 104.5 KiB = 472.5 KiB    vdsb.sh
400.0 KiB + 102.5 KiB = 502.5 KiB    g2v_automount.s
344.0 KiB + 173.5 KiB = 517.5 KiB    runvdr
332.0 KiB + 194.0 KiB = 526.0 KiB    sleep (4)
432.0 KiB + 108.5 KiB = 540.5 KiB    lircd
340.0 KiB + 276.5 KiB = 616.5 KiB    unclutter
596.0 KiB +  37.5 KiB = 633.5 KiB    rpc.idmapd
652.0 KiB +  20.5 KiB = 672.5 KiB    dhcpcd
576.0 KiB + 105.5 KiB = 681.5 KiB    dbus-daemon
636.0 KiB + 150.5 KiB = 786.5 KiB    chronyd
760.0 KiB + 108.5 KiB = 868.5 KiB    rpc.statd
664.0 KiB + 256.0 KiB = 920.0 KiB    su (2)
872.0 KiB + 231.0 KiB =   1.1 MiB    agetty (6)
  1.0 MiB + 487.5 KiB =   1.5 MiB    ratpoison
  1.2 MiB + 985.5 KiB =   2.1 MiB    console-kit-daemon
  2.4 MiB +  42.5 KiB =   2.4 MiB    udevd
  2.0 MiB + 820.5 KiB =   2.8 MiB    nmbd
  2.6 MiB + 962.0 KiB =   3.6 MiB    screen-4.6.1 (6)
  2.4 MiB +   1.3 MiB =   3.7 MiB    syslog-ng (2)
  2.5 MiB +   1.2 MiB =   3.7 MiB    bash (8)
  2.6 MiB +   2.0 MiB =   4.6 MiB    sshd (4)
  4.3 MiB + 690.5 KiB =   4.9 MiB    mc
  9.2 MiB +   1.2 MiB =  10.4 MiB    epghttpd
  6.5 MiB +   4.9 MiB =  11.3 MiB    smbd (4)
 10.3 MiB +   1.1 MiB =  11.5 MiB    fail2ban-server
 14.9 MiB +   1.2 MiB =  16.1 MiB    polkitd
 15.2 MiB +   1.4 MiB =  16.5 MiB    epgd
 43.1 MiB +   6.8 MiB =  49.9 MiB    Xorg
 84.7 MiB +   5.7 MiB =  90.4 MiB    markad (2)
282.5 MiB + 989.5 KiB = 283.5 MiB    mysqld
378.1 MiB +  95.5 KiB = 378.1 MiB    vdradmind
449.1 MiB +  10.7 MiB = 459.8 MiB    vdr
---------------------------------
                          1.3 GiB
=================================
 Private  +   Shared  =  RAM used    Program

144.0 KiB +  22.5 KiB = 166.5 KiB    init
148.0 KiB +  48.5 KiB = 196.5 KiB    logger
196.0 KiB +  26.5 KiB = 222.5 KiB    acpid
192.0 KiB +  30.5 KiB = 222.5 KiB    cron
288.0 KiB +  92.5 KiB = 380.5 KiB    irexec
284.0 KiB + 101.5 KiB = 385.5 KiB    rpcbind
348.0 KiB +  57.5 KiB = 405.5 KiB    grep
340.0 KiB + 109.5 KiB = 449.5 KiB    xwatch.sh
324.0 KiB + 127.5 KiB = 451.5 KiB    nalu_stat.sh
292.0 KiB + 160.0 KiB = 452.0 KiB    sftp-server (2)
340.0 KiB + 114.5 KiB = 454.5 KiB    rec_not_complet
348.0 KiB + 111.5 KiB = 459.5 KiB    gg_startapp.sh
252.0 KiB + 217.5 KiB = 469.5 KiB    xinit
364.0 KiB + 108.5 KiB = 472.5 KiB    check_df.sh
368.0 KiB + 106.5 KiB = 474.5 KiB    gg_g2vgui.sh
364.0 KiB + 113.5 KiB = 477.5 KiB    g2v_netmount.sh
368.0 KiB + 112.5 KiB = 480.5 KiB    vdsb.sh
412.0 KiB + 109.5 KiB = 521.5 KiB    g2v_automount.s
344.0 KiB + 181.5 KiB = 525.5 KiB    runvdr
432.0 KiB + 111.5 KiB = 543.5 KiB    lircd
336.0 KiB + 219.0 KiB = 555.0 KiB    sleep (4)
340.0 KiB + 277.5 KiB = 617.5 KiB    unclutter
596.0 KiB +  38.5 KiB = 634.5 KiB    rpc.idmapd
652.0 KiB +  21.5 KiB = 673.5 KiB    dhcpcd
580.0 KiB + 106.5 KiB = 686.5 KiB    dbus-daemon
644.0 KiB + 166.5 KiB = 810.5 KiB    chronyd
760.0 KiB + 109.5 KiB = 869.5 KiB    rpc.statd
664.0 KiB + 263.0 KiB = 927.0 KiB    su (2)
872.0 KiB + 239.0 KiB =   1.1 MiB    agetty (6)
  1.0 MiB + 497.5 KiB =   1.5 MiB    ratpoison
  1.2 MiB +   1.0 MiB =   2.2 MiB    console-kit-daemon
  2.2 MiB +  43.5 KiB =   2.3 MiB    udevd
  2.0 MiB + 823.5 KiB =   2.8 MiB    nmbd
  2.1 MiB + 995.5 KiB =   3.1 MiB    bash (7)
  2.6 MiB +   1.0 MiB =   3.6 MiB    screen-4.6.1 (6)
  2.4 MiB +   1.4 MiB =   3.8 MiB    syslog-ng (2)
  2.6 MiB +   2.1 MiB =   4.7 MiB    sshd (4)
  9.2 MiB +   1.2 MiB =  10.4 MiB    epghttpd
  6.5 MiB +   4.9 MiB =  11.3 MiB    smbd (4)
 10.3 MiB +   1.1 MiB =  11.5 MiB    fail2ban-server
 14.9 MiB +   1.3 MiB =  16.2 MiB    polkitd
 15.2 MiB +   1.4 MiB =  16.6 MiB    epgd
 46.7 MiB +   1.4 MiB =  48.0 MiB    markad
 43.0 MiB +   6.9 MiB =  49.9 MiB    Xorg
282.7 MiB +   1.0 MiB = 283.7 MiB    mysqld
378.1 MiB + 102.5 KiB = 378.2 MiB    vdradmind
450.8 MiB +  11.1 MiB = 461.9 MiB    vdr
---------------------------------
                          1.3 GiB
=================================

Display More

Wie kommt man dem Verursacher auf die Spur. Hab keine Programmierkenntnisse...
Ich vermute eventuel markad, da sich der Verbrauch erhöht hat, seit dem Update auf die kfb77-Version. War aber vorher auch schon...

kls · Jun 3rd 2020

Ich beobachte auch schon seit einiger Zeit einen stetig ansteigenden Speicherbedarf, allerdings "nur" in der Größenordnung von ca. 100MB pro Woche (wenn der VDR 24/7 läuft). Ich hatte in Version 2.3.5 mal was in der Richtung gefixt:

- Fixed a memory leak in cSectionSyncerHash. The cSectionSyncerEntry objects put into

the hash were never explicitly deleted. Now the cSectionSyncerHash takes ownership of

these objects.

aber anscheinend war das noch nicht alles. Wenn bei dir bereits nach einigen Stunden der Speicher aufgebraucht ist, hat das vermutlich eine andere Ursache.

So ein Speicherleck mit 100MB/Woche zu finden ist mühsam, daher bin ich dem bisher noch nicht nachgegangen...

M-Reimer · Jun 3rd 2020

Etwas ähnliches hatte ich halt auch mit tvheadend. 100 MB pro Woche ist gefühlsmäßig sicher erstmal nicht viel aber wenn man sowas auf einem Raspberry fahren will dann sind 4GB RAM halt in endlicher Zeit voll. Man kann den VDR über systemd bei Überschreiten einer Speichergrenze hart restarten lassen, aber dann läuft man Gefahr eine Aufnahme zu killen.

Ärgerlich für mich vor allem weil das eigentlich mein Hauptgrund war um von tvheadend auf VDR zu wechseln. Ich möchte einfach einen kleinen Mini-Server der wenig Strom braucht und einfach TV-Programm ins Haus-LAN streamt. Mit tvheadend wird das nix, denn da tut sich deutlich weniger wie aktuell im Bereich VDR.

Gibt es nicht Hilfstools die "verlorenen" Speicher erkennen und die Stelle wo der verloren gegangen ist melden?

Edit: https://www.cprogramming.com/debugging/valgrind.html

Ich erinnere mich aber das für irgendwas schonmal genutzt zu haben und der Erfolg war begrenzt.

Argus · Jun 3rd 2020

Johns hatte doch einige Jahre lang versucht, das Speicherleck in Softhddevice zu stopfen. Rofafor hatte dann 2017 dieses in seinem pesintta's github repo gefixt. Kann es sein, das es in den anderen Derivaten immer noch umherdümpelt?

(valgrind hatte damals auch nichts gefunden)

kfb77 · Jun 3rd 2020

Quote from MegaV0lt

Ich vermute eventuel markad, da sich der Verbrauch erhöht hat, seit dem Update auf die kfb77-Version. War aber vorher auch schon...

Nichts ist unmöglich, aber eher unwahrscheinlich, da das Plugin fast nichts macht, sondern nur im VDR Recording Event Händler hängt und wenn da was ankommt, markad startet. markad wird für jede Aufnahme neu gestartet und somit räumt spätestens am Ende der Bearbeitung das Betriebssystem den Speicher vollständig auf.

Ich habe (bis jetzt) am Plugin fast nichts geändert, sondern nur ein paar zusätzliche Parameter eingebaut. Die eigentliche Funktion ist ja außerhalb dem Plugin.

Entferne doch zum Test einfach mal den Link /etc/vdr/conf.d/50-markad.conf, dann wird nach einem Neustart des VDRs das Plugin nicht mit gestartet. Interessant wäre, ob dann der Memory Leak immer noch da ist.

Unter contrib im Source Code liegt ein Script, mit dem man markad auf vorhandene Aufnahmen starten kann ohne das Plugin.

MegaV0lt · Jun 3rd 2020

Quote from kls

... in der Größenordnung von ca. 100MB pro Woche

Das kann man vernachlässigen. Bei mir läuft der VDR nur bei Aufnahmen und wenn ich was schaue. In der Regel abends so 6 Stunden. Und da im Skinflatplus der Speicherverbrauch angezeigt wird, ist mir das aufgefallen. Aber letztens wurde dann sogar geswapped...

Ich vermute dass es eher ein Plugin ist, oder was ganz anderes wie z.B vdradmind oder MySql...

Die meisten werden das kaum bemerken, weil der VDR nur zum Schauen kurz läuft, oder mehr als 4GB verbaut sind. Woche 4GB ja eigentlich dicker reichen sollten

lnj · Jun 3rd 2020

There is a decrease in free memory with cuvid, with softhddevice, softhdcuvid, mpv. With vdpau did not notice, vaapi did not tested.

I think this is ffmpeg problem.

This is clearly visible if you have no more than 2 GB of RAM.

MegaV0lt · Jun 3rd 2020

Ich verwende VDPAU. Daran liegt es dann wohl nicht.

Wäre halt schön, wenn man erst mal raus finden könnte, wo (bei welchem Plugin) man ansetzen muss...

MegaV0lt · Jun 3rd 2020

Würde es sich lohnen so ein Tool mal zu testen?
https://github.com/WuBingzheng/libleak

Ich bin gerade nicht da und kann nichts machen...

Oder wie ist es damit:

https://unix.stackexchange.com…leak-of-a-running-process

Erste Antwort

M-Reimer · Jun 3rd 2020

Ein Versuch ist letztlich nie verkehrt. Schaut beides gut aus. Kenne ich beides nicht. Wäre aber für beide interessiert wie so deine Erfahrung damit ist.

Wegen des 100MB-Problems muss ich dann wohl selber mal schauen. So grob überschlagen ist das deutlich weniger als TVHeadend bei mir "gefressen" hat und vielleicht habe ich ja auch das Glück das das Problem gar nicht auftritt wenn der VDR keine Ausgabe macht. Bei mir soll der eigentlich nämlich tatsächlich 24/7 als reiner Server laufen. Wenn es aber "nur" 100MB pro Woche sind ist durchaus möglich das in der Zwischenzeit sowieso geplante Reboots fällig werden wegen Sicherheitsupdates.

davie2000 · Jun 3rd 2020

Wie kann ich denn den Speicherverbrauch vom VDR sinnvoll und dauerhaft (über Stunden, Tage) monitoren?

Bzw. wie ist dir der steigende Verbrauch aufgefallen?

Ich verwende zwar nur das alte softhddevice openglosd für ffmpeg 2.8, aber interessieren würds mich (und euch evtl.) auch.

Aus den Zahlenwerten von ganz oben werd ich nicht schlau: der VDR verbraucht knapp unter 500 MB (leicht schwankend) und markad - das du erwähnst - braucht sogar weniger im Laufe der Zeit (von ca. 100 MB auf ca. 50MB im letzten Log). Oder sind die Logs von unten nach oben chronologisch zu lesen?

Edit:

Bei mir scheint der mysqld am meisten zu brauchen (eh klar, is ja auch so eingestellt) - VDR braucht so um die 550 MB:

Code

ps -e -orss=,args= | sort -rn | pr -TW$COLUMNS
1641220 /usr/sbin/mysqld
569920 /usr/bin/vdr
47708 /usr/lib/xorg/Xorg -noreset vt7
...

Der Rest ist (einzeln betrachtet) vernachlässigbar.

Ich nehm den Timeout mal raus und werde den Wert vom VDR beobachten ...

rkp · Jun 3rd 2020

Wow, das ist ja eine Menge Speicherverbrauch. Hier:

Code

root@ubuntuwz:~# ps -e -orss=,args= | sort -rn | pr -TW$COLUMNS
243456 /usr/sbin/mysqld
171200 /usr/bin/vdr
92252 /lib/systemd/systemd-journald
63300 /usr/lib/xorg/Xorg -noreset vt7
...

kls · Jun 3rd 2020

Quote from davie2000

Wie kann ich denn den Speicherverbrauch vom VDR sinnvoll und dauerhaft (über Stunden, Tage) monitoren?

Bzw. wie ist dir der steigende Verbrauch aufgefallen?

Ich mache das mit rrdtool. Die Daten hole ich mit

/usr/bin/top -b -n 1 | grep -w vdr | head -1

und nehme davon die Felder 4 und 5.

Damit bekomme ich dann sowas:

kfb77 · Jun 3rd 2020

Quote from davie2000

markad - das du erwähnst - braucht sogar weniger im Laufe der Zeit (von ca. 100 MB auf ca. 50MB im letzten Log)

markad verbraucht nur Speicher, wenn es gerade eine Aufnahme bearbeitet. Wieviel, hängt stark vom Codec der Aufnahme und ob es gerade versucht ein Logo in der Aufnahme zu finden. Dabei kann es auch kurzzeitig noch viel mehr sein. Auf jeden Fall wird am Ende der Bearbeitung das Programm beendet und vom Betriebssystem vollständig aus dem Speicher geworfen. markad läuft als eigenes Programm im eigenen Speicherbereich und kann nicht den Speicherverbrauch vom VDR erhöhen.

Die libvdr-markad.so (also das Plugin, das markad startet) hat nur die Funktion markad zu starten und eine Konfigurationsoberfläche. Ich bin gerade dabei den Code zu prüfen. Da dauert noch, bei fremdem Code muss man sich zuerst zurechtfinden, aber auf den ersten Blick habe ich da schon ein paar memory leaks in der Konfigurationsoberfläche gefunden. Das sind nur ein paar kBytes und nur, wenn man an der Konfiguration was ändert. Kann nicht die Ursache für o.g. Leaks sein, aber schön ist das nicht. Ich werde mich drum kümmern.

kfb77 · Jun 3rd 2020

kls

Kann es sein, dass Speicher für Konfigurationsmenue Punkte, die über z.B. "new cMenuEditBoolItem" erzeugt werden, vom VDR selbst beim Schießen des Menues wieder freigegeben werden ? Ich kann keine Stelle finden, wo ich das wieder freigeben könnte.

davie2000 · Jun 3rd 2020

Quote from rkp

Wow, das ist ja eine Menge Speicherverbrauch.

Ja stimmt, jetzt wo ich deinen lese. mysqld ist egal, das ist absichtlich so eingestellt (cache).
Aber dass mein VDR doppelt soviel RAM braucht wie deiner? Aber vermutlich schwankt das so stark, dass man das nicht vergleichen kann.

Quote from kls

Ich mache das mit rrdtool. Die Daten hole ich mit
/usr/bin/top -b -n 1 | grep -w vdr | head -1 ...

Danke dafür! rrdtool muss ich mir noch anschauen. Jetzt gerade sinds sogar schon über 600 MB!

/usr/bin/top -b -n 1 | grep -w vdr | head -1

1901 vdr 20 0 3122020 629452 61916 S 12,5 15,6 14:54.95 vdr
Scheint (in dem kurzen Beobachtungszeitraum) tatsächlich zu steigen.

Interessant bzw. komisch ist, dass der Befehl zwar meist den VDR ausspuckt, oft aber auch was anderes???

Code

/usr/bin/top -b -n 1 | grep -w vdr | head -1
 1901 vdr       20   0 3122020 626808  59272 S   6,2 15,6  15:02.89 vdr
/usr/bin/top -b -n 1 | grep -w vdr | head -1
 1121 root      20   0  149676  10504   5412 S   0,0  0,3   0:00.08 vdr-update-moni
/usr/bin/top -b -n 1 | grep -w vdr | head -1
 1121 root      20   0  149676  10504   5412 S   0,0  0,3   0:00.08 vdr-update-moni
/usr/bin/top -b -n 1 | grep -w vdr | head -1
 1905 vdr       20   0 1121628  12776   8744 S   6,2  0,3   3:09.68 pulseaudio
/usr/bin/top -b -n 1 | grep -w vdr | head -1
 1121 root      20   0  149676  10504   5412 S   0,0  0,3   0:00.08 vdr-update-moni
/usr/bin/top -b -n 1 | grep -w vdr | head -1
 1901 vdr       20   0 3122020 626820  59272 S  12,5 15,6  15:04.36 vdr

Display More

Ist das normal?

Und Klaus: du lässt den Befehl vermutlich alle paar Minuten in eine Datei ausgeben (anhängen) und wertest diese dann mit dem Tool aus, richtig?

Oder filterst du die Nicht-VDR Prozesse (siehe oberhalb) dann vorher aus?

Quote from kfb77

markad verbraucht nur Speicher, wenn es gerade eine Aufnahme bearbeitet. ...

Danke für die ausführliche Antwort! Wieder was gelernt.

kls · Jun 3rd 2020

Quote from kfb77

Kann es sein, dass Speicher für Konfigurationsmenue Punkte, die über z.B. "new cMenuEditBoolItem" erzeugt werden, vom VDR selbst beim Schießen des Menues wieder freigegeben werden ?

Alle Menü-Items werden beim Schließen des Menüs über cListBase::~cListBase() gelöscht.

kfb77 · Jun 3rd 2020

kls

danke, dann habe ich zumindest mal an der Stelle kein Leak

davie2000 · Jun 3rd 2020

Sorry, aber ich muss nochmal fragen: die 600 MB vom VDR - da sind aber auch alle Plugins miteingerechnet, oder?
Ich denke da zB an skindesigner oder epg2vdr, die ich wirklich sehr viel cachen lasse.

rkp: kann es sein, dass du nur sehr wenige Plugins laufen hast bzw. diese sehr speicherfreundlich eingestellt hast?

kls · Jun 3rd 2020

Quote from davie2000

Und Klaus: du lässt den Befehl vermutlich alle paar Minuten in eine Datei ausgeben (anhängen) und wertest diese dann mit dem Tool aus, richtig?

Oder filterst du die Nicht-VDR Prozesse (siehe oberhalb) dann vorher aus?

Bei mir gibt es keinen User namens 'vdr', daher liefert mir die angegebene Zeile nur den Prozess des laufenden VDRs.

Genau genommen müsste man grep wohl noch etwas genauer formulieren.

Der Aufruf erfolgt alle 5 Minuten über rrdtool.

Hier das gesamte Script um die Daten zu erzeugen (wird mit "vdr" als Parameter aufgerufen):

Perl

#!/usr/bin/perl

$Virt = "U";
$Res = "U";

sub MB
{
  my $s = shift;
  if    ($s =~ s/g$//) { $s *= 1000; }
  elsif ($s =~ s/m$//) { }
  else                 { $s /= 1000; }
  return $s;
}

if ($ARGV[0]) {
   $s = `/usr/bin/top -b -n 1 | grep -w $ARGV[0] | head -1`;
   chomp($s);
   if ($s) {
      $s =~ s/^ *//;
      @a = split(/ +/, $s);
      $Virt = MB($a[4]);
      $Res  = MB($a[5]);
      }
   }

print "$Virt\n$Res\n";

Display More

Participate now!

Share