Speicherleck im VDR oder einem Plugin

  • Ich stelle folgende Frage in den Raum:

    .. warum MUSS der vdr ( Core ) immer laufen ?

    Schau jemand ununterbrochen fern ?

    Nein, ich schaue nicht ununterbrochen fern. Und nein, der VDR muss auch nicht immer laufen. Aber da er auf einer Hardware läuft die eh immer läuft, macht das keinen Unterschied mehr. Ich hatte früher auch einen dedizierten "VDR" der nur bei Bedarf lief. Aber da ich eh einen Server betreibe, der aus praktischen Gründen immer läuft, ist der VDR dort hin umgezogen und läuft seid dem auch immer. Unterm Strich verbrauche ich somit weniger Strom, weil die Hardware für den dedizierten VDR weggefallen ist. Alles in einer Kiste eben, Verbrauch so ca. 15 Watt wenn die Platten nicht laufen. Die schalten nach 20 Minuten aus Stromspargründen ab.


    Das Teil ist Datengrab (NAS), Musiklieferant (LMS), TV Lieferant (VDR), Tunnelendpunkt (VPN), Accesspoit für 802.11ac, Telefonanlage (Asterisk) und diverser "Kleinkram".

  • Hallo Zusammen,


    ich benutze den vdr seit über 10 Jahren (btw: danke Klaus!). Ich erlebe seit dem einen zunehmenden Speicherverbrauch von ca. 30 MB / Woche (ich vermute das ist das Leak auf das Klaus sich in dem Thread mit der rrd-tool Grafik und dem perl script bezieht).


    In der Zeit zwischen Anfang und Mitte Mai bemrkte ich plötzlich einen Memory leak von 120 MB bis 200 MB pro Tag. Da der vdr trotzdem stabil funktioniert, kann ich nicht genau sagen, wann es begonnen hat. Zu dieser Zeit benutzte ich vdr 2.4.1.


    In diesem Zeitfenster habe ich updates für gcc (10.x -> 11.x), glibc (2.32 -> 2.33) und die Umstellumg auf libglvnd gemacht. Mittlerweile habe ich vieles versucht:


    • ganzes system mit gcc-10.3.0 neugebaut
    • zu vdr-2.2.x downgraded
    • zu vdr-2.4.7 geupdated (nutze ich auch im Moment)
    • zu vdr-2.5.6 geupdated
    • xineliboutput anstelle von softhddevice benutz
    • diverse ffmpeg Versionen >=4.2

    Nichts hat das leak beeinflußt.


    Ich hatte dann die Kombi softhddevice (bzw. xineliboutput), libglvnd, nvidia opengl und vdpau und ffmpeg in Verdacht. Da meine Distro (gentoo) x11 ohne linglvnd nicht mehr unterstützt, konnte ich das nicht weiter testen - aber nach den Berichten von kfb77 können wir Ausgabeplugin + nvidia-Schrunz wohl als Ursache ausschließen.


    Leider konnte ich ein Dpwngrade auf glibc-2.32 nicht testen, da gentoo das Downgrading von glibc nicht unterstützt.


    Ich habe seit gestern das abschalten des epg scans getestet, aber das leak besteht fort. Könnte es also sein, dass nicht der epg scan an sich, sondern das Tuning das leak triggert (da epg scan tuning triggert, wäre es ein indirekter epg scan Effekt)?


    Wie eingangs erwähnt, variiert das Leak in meinem Setup. Ich glaube (keine scriptbasierten, standarisierten, reproduzierbare Messungen, aber 7 Monate empirisches zappen... ;) ), die Anzahl der Kanalwechsel (tuning), als auch der angezappte Kanal (zdf hd mehr als die anderen 720p Kanäle mehr als sd Kanäle) einen Einfluss auf des Ausmaß des Leaks. Ausgelöst durch glibc-2.33 (und neuer - mittlerweile nutze ich 2.34) auf einem 64bit System. Wie schon gesagt, dass ist nur eine Vermutung.


    kfb77:


    Kannst Du auf Deinem Testserver mal ein Script laufen lassen, dass die Kanäle wechselt? Mit epg scan abgeschaltet und ohme Kanalwechsel, habe ich auch kein Leak mehr - aber das dürfte wohl kein üblicher Usecase sein... ;)

  • Könnte es also sein, dass nicht der epg scan an sich, sondern das Tuning das leak triggert (da epg scan tuning triggert, wäre es ein indirekter epg scan Effekt)?

    daran habe ich auch schon gedacht.

    Ich lasse gerade den VDR nur mit dem dummydevice laufen, habe aber den Eit-Sectionfilter ganz deaktiviert und die epg.dat gelöscht. Ich schalte nicht Live über alle Programme, sondern lasse im Hintergrund durch aktivierten EPG-Scan über alle Transponder durchschalten. "UpdateChannels" ist auf "neue Transponder hinzufügen" eingestellt.

    Er läuft jetzt erst seit etwas mehr als einer Stunde, für eine eindeutige Aussage ist es daher noch zu früh.


    Den EIT/EPG Filter habe ich so deaktiviert:

    LG Helmut

  • Ich widerlege mich jetzt selbst. Mein produktiver VDR Server mit EPG Scan hatte gestern gar kein Speicher verbraucht:

    Code
    2021-12-07 108470 vdr 20 0 2475052 509356 7936 S 0,0 1,6 155:02.99 vdr
    2021-12-08 108470 vdr 20 0 2610224 631976 6708 S 0,0 1,9 295:11.16 vdr
    2021-12-09 108470 vdr 20 0 2806832 705632 7076 S 6,2 2,2 350:57.07 vdr
    2021-12-10 108470 vdr 20 0 2806832 815760 6932 S 0,0 2,5 434:37.16 vdr

    Exakt gleicher Speicherverbrauch am 4. Tag der Aufzeichnung,

    Vor der ersten Aufnahme heute wurde sogar wieder ein wenig Speicher freigegeben:

    Code
    108470 vdr       20   0 2798628 866720  10804 S  12,5   2,7 480:53.18 vdr

    Nach der ersten Aufnahme heute hatte ich wieder einen zusätzliche Speicherverbrauch von ca. 64 MB gegenüber den Wert von gestern:

    Zitat

    108470 vdr 20 0 2864172 871024 10260 S 6,2 2,7 502:35.72 vdr

    Das sieht jetzt doch nicht wirklich nach EPG Problem aus. Ich denke, wir brauchen hier noch mehr Werte, von mehreren Tagen, für eine klare Aussage.

  • Der Verbrauch von physischem RAM ist schon gestiegen. Das ist die Spalte "RES" (für resident) in KiB.

    Der Steigerung wäre bei dir in den 3 Tagen 306 MiB und heute nach der Aufnahme noch einmal 66 MiB.

    Code
                 PID  USER PR NI    VIRT    RES   SHR S %CPU %MEM      TIME+ COMMAND
    2021-12-07 108470  vdr 20  0 2475052 509356  7936 S  0,0  1,6  155:02.99 vdr
    2021-12-08 108470  vdr 20  0 2610224 631976  6708 S  0,0  1,9  295:11.16 vdr
    2021-12-09 108470  vdr 20  0 2806832 705632  7076 S  6,2  2,2  350:57.07 vdr
    2021-12-10 108470  vdr 20  0 2806832 815760  6932 S  0,0  2,5  434:37.16 vdr
    --- nach Aufnahme
               108470  vdr 20  0 2864172 871024 10260 S  6,2  2,7  502:35.72 vdr

    Man sieht es auch an %MEM vom gesamten phsischen Speicher (32 GIB ?)

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • 32 GIB ?

    Ja, das ist der physikalische Wert vom Host System, die VDRs (und andere Anwendungen) laufen jeweils auf einem eigenen LXC Container.


    Gibt mir mal bitte Nachhilfe in Speicherverwaltung: Ich dachte relevant ist der virtuelle Speicher, der gibt an, wie viel Speicher eine Anwendung allokiert hat. Der resistente Speicher ist der Teil davon, der aktuell wirklich im physikalischen Speicher vorhanden ist. Das bestimmt das Betriebssystem über sein Swap Verhalten, die Anwendung hat keinen Einfluss darauf. Oder nicht ?

    2 Mal editiert, zuletzt von kfb77 ()

  • Seit meinen letzten Versuchen zu dem Thema ist mir noch eine Idee gekommen, die ich aus Zeitgründen aber nicht weiter verfolgt habe.


    Mir war aufgefallen, dass (fast?) alle Datenstrukturen im VDR irgendwie von ListObject() erben. Warum nicht einfach da einen Zähler einbauen?

    Im Konstruktor 1 hoch und im Destruktor wieder runter zählen.

    Wenn die Zahl der Instanzen immer weiter hoch läuft, weiss man dass irgendwo vergessen wird erzeugte Datenobjekte wieder zu löschen.

    Wenn nicht, dass man wo anders suchen muss.


    So ganz sicher, ob das wirklich so klappt, bin ich nicht. Ich hatte bislang nur die Idee und es mir noch nicht angesehen.

    Gruss
    SHF


  • kfb77 : Hier mein Wissenstand, ohne Anspuch auf vollkommene Richtigkeit :).

    Virtual Memory gibt an, wieviel Speicher ein Prozess aktuell insgesamt ansprechen kann.


    "Speicher" bezieht sich aber nicht nur auf das RAM in dem der Code und Daten abgelegt sind, sondern auf alles was in den virtuellen Adressbereich "gemapt" wurde.

    Das kann auch RAM von Peripheriegeräten wie z.B. einer Grafkkarte sein oder eine Datei auf einer Disk - es wird zB für alle verwendeten Bibliotheken Virtual Memory reserviert, über die virtuelle Adresse können diese Dateien dann gelesen werden, physisch wird aber auf den Speicher der Disk zugegriffen. Ins RAM werden aus einer Bibliothek außerdem nur die benötigten Funktionen kopiert, im Virtual Memory ist der Speichebereich aber in Größe der gesamten Datei reserviert.
    Der Virtual Memory ist daher immer um einiges größer als nur der tatsächlich belegte Arbeitsspeicher.


    SWAP-space kommt dann ins Spiel, wenn kein physische RAM mehr frei ist. Dann wird der von einem Prozess gerade nicht benötigte Speicher auf eine Disk kopiert und so RAM freigemacht.


    "RES" ist daher der aussagekräftigere Wert für die Speicherbelegung.

    LG Helmut

  • SWAP-space kommt dann ins Spiel, wenn kein physische RAM mehr frei ist.

    Dem Punkt würde ich gerne widersprechen, mit dem Rest hast du mich überzeugt, RES ist das was am Ende wirklich weh tut.

    Der Kernel fängt durchaus schon viel früher an, lange nicht benutzte Seiten auszulagern, auch wenn es noch genug freien Speicher gibt. Meine 32GB sind sicher nie voll belegt, trotzdem habe ich 5 GB im Swap. Das wird vorsorglich gemacht (es könnte ja bald jemand Speicher brauchen) sowie um möglichst viel Speicher für Platten Cache nutzen zu können.

  • kfb77:


    Ab wann swap benutzt wird, legt der Parameter /proc/sys/vm/swapiness fest. Vereinfacht gesagt: liegt dieser Wert bei 60 wird der kernel bei 60% ram-Nutzung anfangen, swap zu benutzen (natürlich nicht für alle Prozesse gleich - aktuelle Nutzung, Priorität, Niceness und/oder Echtzeit-Flag spielen eine Rolle welche Prozesse in welchen Teilen ausgeswapt werden. Meine Prozent-Umrechnung hinkt natürlich, aber erklärt schön, wie swapiness funktioniert.

  • Der Kernel fängt durchaus schon viel früher an, lange nicht benutzte Seiten auszulagern, auch wenn es noch genug freien Speicher gibt.

    Das kenne ich so eigentlich nur von Windows, bei meinen Linux-Rechnern ist Swap immer 0, naja, fast.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    Einmal editiert, zuletzt von jsffm ()

  • Kein Wiederspruch, so kenne ich das auch.

    Aber da muss es noch mehr Kriterien geben: Der Wert steht bei mir auf 60, ich habe in htop noch nie mehr wie 6 GB genutzter Speicher ohne Cache gesehen (von 32GB, also sind die 6 GB weit weg von 60%), trotzdem sind aktuell 5 GB ausgelagert. Warum auch immer ...

  • Das kenne ich so eigentlich nur von Windows

    Echt jetzt ? Hat mir einer Windows untergeschoben ???


    Code
    Server3:~$ free -m
                  gesamt      belegt       frei     gemeinsam    Zwischen   verfügbar
    Speicher:       31777        5296         473          48       26006       25975
    Auslager:        8191        4938        325
  • Echt jetzt ? Hat mir einer Windows untergeschoben ???


    Code
    Server3:~$ free -m
                  gesamt      belegt       frei     gemeinsam    Zwischen   verfügbar
    Speicher:       31777        5296         473          48       26006       25975
    Auslager:        8191        4938        325

    Hm, das ist merkwürdig. Ich habe nur 16 GB und geswappt hat die Maschine vorhin, als ich ein paar updates übersetzt habe (bei gut der Hälfte Speichernutzung, also etwa 60%). Einmal ausgswappt werden die pages natürlich nur zurückgeholt, wenn sie auch wieder benötigt werden.


    Code
    free -m
                   total        used        free      shared  buff/cache   available
    Mem:           16028        3973        1926          11       10128       11284
    Swap:          32565         191       32374

    Keine Ahnung, ob bei Deiner Maschine was falsch läuft, oder ob es einfach eine Situation gab, als sie mehr Auslastung hatte, ausgelagert hat und die Pages einfach noch nicht wieder gebraucht hat.


    Das geht jetzt jedenfalls in Richtung off topic und hat nichts mehr mit dem Ursprünglichen Thread-Thema zu tun.

  • Hier die ersten Erkenntnis ohne EIT: der Speicherverbrauch steigt ziemlich konstant um ~700 KiB/Std.

    Wenn aber zusätzlich auch der NIT-Filter deaktiviert wird, ändert sich die Speicherbelegung nur wärend des ersten Tranponderscans, in den darauffolgenden 1,5 Stunden habe ich keine Steigerung mehr beobachtet.

    Ich werde mir daher nit.c etwas genauer ansehen.

    Im Anhang die Logs mit den Ausgaben von "top".

  • Mit der geänderten channels.conf die nur ca 11% der ursprünglichen Kanäle enthält, komme ich hochgerechnet auf ca 150 MB / 24h. Vorher waren es ca 180 MB / 24h. Da das jetzt nur ein relativ kurzer Beobachtungszeitraum war, gibt es da eine gewisse Unschärfe. Ich habe den VDR vorher ca. 2h laufen lassen, bevor ich den Speicherverbrauch notiert habe. Unterm Strich kann man sagen, keine Änderung.

  • FireFly: cEIT::cEIT() sorgt durch seinen Write-Lock auf Channels dafür, dass immer nur *ein* Handler aufgerufen wird.

    Möglicherweise wird der Lock aber einen Tick zu früh freigegeben.

    Hallo Klaus, das war es offenbar, der Fehler ist nicht wieder aufgetreten so dass der Fix in den offiziellen VDR übernommen werden kann.

    Jetzt muss ich das Logging wieder ausbauen, da das Logfile mit 2,1 GB die Platte voll laufen ließ :D

  • Hier die ersten Erkenntnis ohne EIT: der Speicherverbrauch steigt ziemlich konstant um ~700 KiB/Std.

    Wenn aber zusätzlich auch der NIT-Filter deaktiviert wird, ändert sich die Speicherbelegung nur wärend des ersten Tranponderscans, in den darauffolgenden 1,5 Stunden habe ich keine Steigerung mehr beobachtet.

    Ich werde mir daher nit.c etwas genauer ansehen.

    Im Anhang die Logs mit den Ausgaben von "top".

    Ich habe gestern den vdr mit

    übersetzt.


    Zuerst sah das auch gut aus. In den ersten Stunden gab der vdr sogar 'mal 70KB wieder frei. Aber nachdem ich gestern Abend etwas gezappt habe, gings wieder los - und heute morgen habe ich verglichen mit dem Speicherverbrauch der ersten Stunden wieder 110 MB verloren. Sorry.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!