Speicherleck im VDR oder einem Plugin

  • Hallo


    Dieses Thema ist ja scheinbar schon älter, aber offensichtlich nie behoben worden. Siehe dazu unter Anderem:

    133612-speicherverbrauch-steigt-mit-der-zeit

    131748-vdr-per-cron-neustarten-wenn-keine-aufnahme-aktiv

    126111-etwas-frist-speicher-vdr-streamdev-softhddevice-ffmpeg-vdpau-vdr


    Mir ist das auch schon vor längerer Zeit aufgefallen, habe aber bisher immer einfach den VDR neu gestartet wenn es zu viel wurde. Es wäre aber durchaus willkommen, wenn die Ursache dazu gefunden werden würde. Mein VDR läuft 24/7 auf openmediavault 4.1.31-1, Kernel 4.19.0-0.bpo.9-amd64, Debian 9. VDR wurde aus den e-Tobi Repos installiert. Alles schon älter und ich sollte mal updaten, ich weiß.


    Code
    vdr/now 2.4.1-1~etobi1 amd64  [Installiert,lokal]
    vdr-plugin-epgsearch/now 2.4.0+git20190507-1 amd64  [Installiert,lokal]
    vdr-plugin-femon/now 2.4.0-1 amd64  [Installiert,lokal]
    vdr-plugin-live/now 2.3.1-3 amd64  [Installiert,lokal]
    vdr-plugin-streamdev-server/now 0.6.1+git20180514-1 amd64  [Installiert,lokal]
    vdr-plugin-svdrposd/now 1.0.0-7 amd64  [Installiert,lokal]
    vdr-plugin-vnsiserver/now 1:1.8.0-1 amd64  [Installiert,lokal]


    Das Bild stellt natürlich den gesamten Speicherverbrauch des Systems dar. Aber jede fallende Flanke von dem "Sägezahn" ist ein systemctl restart vdr, somit kann man den Speicherverbrauch vom VDR+Plugins schon sehr schön einschätzen.


    Wie kann ich helfen, das Problem einzugrenzen oder gar zu lösen. Das System ist produktiv und ich bin als Linux Anfänger einzustufen.


    Vielen Dank für eure Unterstützung

    Marcus

  • Moin!


    Am besten mal die Hälfte der Plugins deaktivieren, um zu schauen, ob eins davon der Schuldige ist.

    Wenn nicht, dann von den übrig gebliebenen wieder die Hälfte deaktivieren.


    Ist der Speicherverbrauch dann nicht mehr so radikal, dann war bei der zuletzt deaktivierten Hälfte das gesuchte dabei. Da die Anzahl bei dir recht übersichtlich ist, eins nach dem anderen wieder aktivieren, bis es feststeht.


    Ist natürlich mit einem Produktivsystem nicht so einfach. Und der Speicherverbrauch scheint sich ja auch über Tage aufzuschaukeln, oder? Evtl. sonst mal ein Dev-System aufsetzen und versuchen, das Problem nachzustellen.


    Lars.

  • Hallo Lars!


    Ein anderes System ist nicht machbar, dazu müsste ich ja erst Hardware kaufen. Das ein oder andere Plugin kann ich testweise deaktivieren, aber da es ein Produktivsystem ist, nicht alle.


    Auf femon, live, svdrposd und vnsiserver kann ich sicherlich ein paar Wochen verzichten. Aber epgsearch und streamdev-server werden zwangsläufig benötigt, der VDR ist ein headless Server und versorgt den ganzen Haushalt.


    Deine Vorschläge zielen auch darauf ab, dass ein Plugin schuld sein muss. Wenn ich mir die oben verlinkten Threads durchlese, denke ich eher dass es der VDR selbst ist. Ich werde den VDR jetzt ein paar Tage/Wochen nur mit streamdev-server und epgsearch laufen lassen. Mal sehen was passiert.


    Ich hatte die Hoffnung dass man das auch ohne try+error eingrenzen kann.


    EDIT: Wie deaktiviere ich ein oder mehrere Plugins? Konnte nichts dazu finden. Irgendwo in den Startroutinen vom VDR muss ja angegeben werden, welche Plugins geladen werden sollen?

    Einmal editiert, zuletzt von Marcus 2208 ()

  • Moin!


    Nein, ein Plugin muss nicht Schuld sein, aber so könnte man es herausfinden. Sonst müsstest du den vdr auch einfach mal ohne Plugins laufen lassen. Wenn der Speicherverbrauch dann auch ansteigt, dann ist der vdr Schuld. Das wäre dann der Schritt, wenn man die Plugins ausgeschlossen hat. Aber man könnte auch damit anfangen.


    Es ist natürlich schwer, einen Fehler zu finden, wenn man das System eigentlich nicht wirklich anfassen kann.


    vdr 2.4.1 müsste seine Konfiguration aus /etc/vdr beziehen. Da müsste es ein conf.d-Verzeichnis geben, wo man dann einzelne Abschnitte deaktivieren kann.


    Viel Erfolg!


    Lars.

  • EDIT: Wie deaktiviere ich ein oder mehrere Plugins? Konnte nichts dazu finden. Irgendwo in den Startroutinen vom VDR muss ja angegeben werden, welche Plugins geladen werden sollen?

    Hmm, ich mache das zur Laufzeit des VDR über ein 'homemade' Plugin, mit dem ich andere Plugins zur Laufzeit des VDR stoppen/starten bzw. aus dem VDR laden/neuladen kann, während der vdr weiter läuft (weil z.B. wichtige Aufnahmen laufen), das Menü des VDR bekomme dazu ich über das control Plugin.


    So entwickele ich zumeist neue Ideen vom wirbelscan Plugin/w_scan_cpp oder pull requests für andere Plugins. Aber das hat außer mir wohl niemand..


    Wär mal interessant, wie das andere hier machen!

  • vdr 2.4.1 müsste seine Konfiguration aus /etc/vdr beziehen. Da müsste es ein conf.d-Verzeichnis geben, wo man dann einzelne Abschnitte deaktivieren kann.

    Das Verzeichnis gibt es in der Tat. Aber mir ist nicht klar, wie ich dort die Plugins deaktivieren kann.


    Code
    00-vdr.conf  
    50-conflictcheckonly.conf  
    50-epgsearch.conf  
    50-epgsearchonly.conf  
    50-femon.conf  
    50-live.conf  
    50-quickepgsearch.conf  
    50-streamdev-server.conf  
    50-svdrposd.conf  
    50-vnsiserver.conf

    Der Inhalt von 00-vdr.conf:

    Ich glaube ich benötige da noch Nachhilfe bitte.


    EDIT: Ich habs kapiert glaube ich. Die Konfig-files der Plugins löschen, dann werden sie wohl auch nicht mehr geladen. Richtig? Backup machen macht auch Sinn.

  • Mit Ausnahme der 00-vdr.conf sollten das Symlinks aus /etc/vdr/conf.avail sein - die kann man einfach Löschen und bei Bedarf wieder anlegen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, genau so ist das. Vielen Dank für die Aufklärung. Jetzt warten wir einfach 4 Wochen ab und sehen was passiert.


    EDIT: Alles gelöscht, bis auf 50-streamdev-server.conf

    2 Mal editiert, zuletzt von Marcus 2208 ()

  • Hallo Klaus


    Ich habe dein Diagramm schon im Thread vom letzten Jahr gesehen. Daher eben die Vermutung von mir, dass das Speicherleck eher im VDR zu suchen ist. Falls ich in irgend einer Form unterstützen kann, würde ich das sehr gerne tun. Wie gesagt, Produktivsystem und ich stecke leider nicht sehr tief in der Materie drin. Trotz dass ich den VDR schon seid über 15 Jahren nutze. Gab halt nie Anlass mich intensiver damit zu beschäftigen, da er immer absolut zuverlässig funktioniert hat. An dieser Stelle vielen Dank! Fernsehen ohne den VDR kommt mir mittlerweile völlig unmöglich vor.


    Grüße

    Marcus

  • Ich kann bereits jetzt grob abschätzen, dass der Speicher auch mit den deaktivieren Plugins in ähnlichem Maße vollläuft. Laut meinem Diagramm oben, sind es bei mir ca 180 MB pro Tag. Seid ich den VDR gestern Abend neu gestartet habe, ist der Speicherverbrauch des VDR um ca 120 MB angestiegen. Ist jetzt keine hochwissenschaftliche Mathematik, aber Pi*Daumen kommt das ungefähr hin. Sind ca 17h seid Neustart vergangen. Werde das weiter beobachten.

  • Auf jeden Fall macht diese Problematik meinen Plan, einem Bekannten einen kleinen VDR-Server auf einem Raspberry aufzubauen, einigermaßen zunichte. Der hat halt nicht allzu üppig RAM. Als reiner VDR-Server sollte er aber eigentlich genügend Power haben.


    Im Prinzip könnte ich, wenn man mir dabei hilft und Tipps gibt, mit einem VDR unterstützen der nicht produktiv genutzt wird. Also solange ich parallel noch Kodi verwenden kann. Für mich ist TV faktisch schon gestorben und ich hab die VDR-Instanz auf meinem HTPC nur noch laufen um zu prüfen ob meine Pakete noch passen und zum Testen für die Kiste die ich bei einem Bekannten noch pflege.


    Eigentlich muss dieser Bug ja an einer bestimmten Stelle dazu gekommen sein. Es gab mal eine Zeit wo hier mehr oder weniger ein Wettrennen um Uralt-Hardware war und alte Pentium 2 oder 3 via Full-Featured-Karte zum VDR wurden. Mit so einer Speicher-Lücke wäre das kaum praktikabel gewesen sein.


    "Git bisect" ist aber faktisch unmöglich wenn man immer erst recht lange warten muss bis der Fehler sichtbar wird.


    Was mir auffällt: Die Steigung der Geraden der Speicherzunahme ist relativ konstant. Wenn man es schaffen würde diese Steigung zu beeinflussen könnte man vielleicht auf die Ursache schließen.


    Zwei Dinge die mir da einfallen (aber bitte nur eines nach dem anderen und dazwischen immer solange warten das man die Geradensteigung auch sicher beurteilen kann):


    - Die "channels.conf" mal entweder deutlich zusammenkürzen (wenn die aktuell eher viele ungenutzte Kanäle drin sind) oder mit möglichst vielen zusätzlichen Kanälen vergrößern. Der VDR lässt sich ja nicht so einfach abgewöhnen für all diese Kanäle (auch wenn man die eigentlich nie anschaut) auch EPG zu holen.

    - EPG-Scan mal abschalten (wenn aktuell eingeschaltet)


    Vielleicht bin ich da auch komplett auf dem Holzweg, aber ich hatte, seit dieses Speicherproblem diskutiert wurde, eigentlich schon immer das EPG in Verdacht. Ich wüsste nicht was sonst regelmäßig vom VDR erfasst und abgelegt wird.

  • Meine channels.conf hat gerade 498 Kanäle, DVB-C. Ich kann sie ohne etwas zu vermissen auf 56 Kanäle eindampfen, muss dann aber dem VDR verbieten neue Kanäle hinzuzufügen. Werde ich in Kürze umsetzen. Mal sehen ob sich die Steigung dadurch ändert. EPG komplett abschalten kann ich aber hier nicht.

  • Mein headless-VDR-Server läuft nun seit 401 Tagen. Damals Neustart wegen Update. Und davor waren's sicherlich auch mehrere hundert Tage am Stück. Auffällig war hier nie was.

    Allerdings ist der EPG-Scan ausgeschaltet. Ich lasse nachts die 65 Sender der channels.conf per Script durchschalten.


    Wie erstelle ich denn die schönen Speicherauslastungsdiagramme vom Anfang des Threads? Kann ich/ soll ich irgendwas beobachten?


    Beste Grüße

    Stefan

  • Hallo Stefan


    Das klingt sehr interessant, offensichtlich hast du dieses Problem nicht, oder in so geringem Umfang, dass es nicht auffällt.


    Das Diagramm stammt von Openmediavault, einem NAS Bertiebssystem welches auf Debian aufsetzt. Dort habe ich einfach den VDR installiert, über das Repo von eTobi.


    EDIT: Stimmt deine Signatur? VDR 2.2.0?

    Du könntest mal mit top/htop nachsehen, wie viel Speicher der VDR Prozess benötigt.


    EDIT2: Ich kann mich auch irren, aber ich glaube, dass so ein amok-laufender Prozess (sorry kls :saint:) irgendwann automatisch neu gestartet wird, wenn der Speicher knapp wird. Weiß hierzu vielleicht jemand näheres? Ich bin mir fast sicher, dass ich das bei mir schoneinmal beobachtet habe. Wenn mir openmediavault nicht immer eMails schicken würde, wenn der Speicher >90% gefüllt ist, würde mir das vermutlich auch nicht auffallen. Von dem Sägezahn im Diagramm mal abgesehen.

    2 Mal editiert, zuletzt von Marcus 2208 ()

  • Der Kernel killt irgendwann einen Prozess der zu viel Speicher verbraucht. Besser und schneller geht das mit dem systemd-oomd.


    Aber interessant das es ohne EPG-Scan nicht auftritt. Wenn jetzt noch die kürzere channels.conf einen Effekt hat könnte man mutmaßen das es tatsächlich irgendwas mit EPG zu tun hat.

  • Entweder tritt es nicht auf, oder es fällt nicht auf. Das gilt es noch zu klären. Wenn kls das Problem schon bekannt ist, und es hier bei mir mit nur einem geladenen Plugin auftritt, kann man fast davon ausgehen, dass es überall auftreten sollte. Wie bereits erwähnt, ich bekomme das nur mit, weil ich eine E-Mail bekomme, wenn der Speicher >90% gefüllt ist, oder ich auf die Diagramme gucke. Sonst würde der Kernel das Problem still und leise lösen. Falls der kill nicht genau in einer Aufnahme passiert, oder beim live gucken.

  • Leider habe ich trotz längerem Suchen bisher nicht gefunden, woran es liegt.

    Die Kanaltabelle vom VDR ist doch im Prinzip ein "moving target". Da kommen ja - je nach aktuellem Programm aller Sender - schon mal zusätzliche 5.1 Audiokanäle, Originalton.... etc. dazu oder verschwinden wieder. Das wird doch vermutlich im VDR im Memory gehalten, könnte sich da im Laufe der Zeit so viel ändern und der alte Eintrag in der "Tabelle" wird nicht gelöscht? 180MB/Tag wäre allerdings schon sehr viel. Selbst im Multi-Satelliten-Betrieb.

Jetzt mitmachen!

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