Speicherleck im VDR oder einem Plugin

  • Hat vielleicht die Anzahl an DVB Geräten, oder deren System einen Einfluss auf das Speicherleck?


    Ich habe 6x DVB-C per USB angebunden. Bei mir sind es ca 180 MB / 24h.

  • Hier noch ein Update nach 6 Tagen:

    produktiver Server mit EPG Scan:

    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
    2021-12-11 108470 vdr 20 0 2872368 891924 6864 S 0,0 2,7 552:20.91 vdr
    2021-12-12 108470 vdr 20 0 3003408 976112 7056 S 0,0 3,0 697:45.91 vdr

    Test Server ohne EPG Scan

    Code
    2021-12-07 157927 vdr 20 0 1427864 36156 3916 S 0,0 0,1 12:28.61 vdr
    2021-12-08 157927 vdr 20 0 1427864 18620 2432 S 0,0 0,1 14:25.08 vdr
    2021-12-09 157927 vdr 20 0 1427864 17336 1548 S 0,0 0,1 15:42.45 vdr
    2021-12-10 157927 vdr 20 0 1428160 62256 6360 S 0,0 0,2 27:30.80 vdr
    2021-12-11 157927 vdr 20 0 1428128 63784 6484 S 0,0 0,2 39:49.31 vdr
    2021-12-12 157927 vdr 20 0 1428128 42536 2980 S 0,0 0,1 45:26.19 vdr

    Auf beiden Servern laufen Aufnahmen, auf dem Testserver natürlich deutlich weniger. Bei mir kann man wohl eindeutig eine Abhängigkeit zum EPG Scan erkennen.

    Hat vielleicht die Anzahl an DVB Geräten, oder deren System einen Einfluss auf das Speicherleck?

    Glaube ich nicht, beide Server haben gar keine physikalischen DVB Devices, ich nutze SATIP. Der produktive Server hat 4 virtuelle Devices, der Testserver nur 2.

  • Hat vielleicht die Anzahl an DVB Geräten, oder deren System einen Einfluss auf das Speicherleck?


    Ich habe 6x DVB-C per USB angebunden. Bei mir sind es ca 180 MB / 24h.

    Möglich. Ich habe je nach Benutzung auch bis zu knapp 200MB/Tag gesehen. Da mehr devices meist auch mehr Aufnahmen (also Kanalwechsel bzw. tunings) bedeuten, halte ich zumindest einen indirekten Effekt für wahrscheinlich.


    Hast Du mal den epg scan abgeschaltet? behebt das bei Dir das Leak?

    Auf beiden Servern laufen Aufnahmen, auf dem Testserver natürlich deutlich weniger. Bei mir kann man wohl eindeutig eine Abhängigkeit zum EPG Scan erkennen.

    Hast Du mal ein "Umschaltescript" laufen lassen? Bei mir bringt das Abschalten des epg scans nichts: bei mir hängts an der Benutzung: viel zappen -> großes leak - wenig zappen -> kleines Leak. Vieleicht sind es aber auch einfach unterschoedliche Leaks. Der "Trick" mit eit- und nit-Filterabschalten hilft bei mir ja auch nicht.

    Oder das laek verhält sich auf headless Installationen anders, als eine mit Ausgabe-Plugin umd interaktiver Nutzung.

  • Hast Du mal ein "Umschaltescript" laufen lassen?

    Nein, hatte noch keine Zeit dazu, was zu basteln. Ich glaube auch nicht, dass das neue Erkenntnisse bringt. Das Verhalten wird sein, wie beim EPG Scan, nur eben extern getriggert. Ich hoffe, HelmutB ist da schon auf der richtigen Spur.


    Oder das laek verhält sich auf headless Installationen anders, als eine mit Ausgabe-Plugin umd interaktiver Nutzung.

    Davon gehe ich auch aus, das zappen fällt weg. Mein Server tunt ohne EPG Scan nur einen Kanal an, wenn er auch davon aufnehmen will.

  • Ich hoffe, HelmutB ist da schon auf der richtigen Spur.

    Die Hoffnung habe ich nach diesem Test ( Speicherleck im VDR oder einem Plugin ) aufgegeben.


    Wenn es nicht zwei unabhängige leaks sind, sollten wir im Hinterkopf behalten, dass der "epg scan off" Effekt nicht direkt das Leak behebt, sondern das tunen verhindert (welches dann eben nicht mehr das leak triggered). Deshalb würde ein Test mit "Umschaltscript" insofern neue Erkenntnisse bringen, als dass wir hinterher wissen, ob der epg scan direkt das leak beeinflusst, oder nur indirekt, wegen weniger tunings.


    Wie war das eigentlich bei Dir: meine vdr Installation lief Jahre lang ohne dieses massive leak, und es trat auf, ohne dass ich die vdr installation verändert habe (keine vdr und/oder plugin updates, in der Zeit, als das leak auftrat) , sondern "nur" normale distro updates durchgeführt habe.

  • Ich habe da nie darauf geachtet, mein Server hat 32 GB Memory und wird i.A. einmal im Monat für ein Clonezilla Backup der Systemplatte runtergefahren. Da fallen mir Leaks nicht auf. Ich habe es erst festgestellt nachdem ich gezielt per Script danach gesucht habe.

    dass der "epg scan off" Effekt nicht direkt das Leak behebt, sondern das tunen verhindert (welches dann eben nicht mehr das leak triggered)

    Das glaube ich auch. Aber "glauben" kommt von "nicht wissen". ;)

  • Hast Du mal den epg scan abgeschaltet? behebt das bei Dir das Leak?

    Kann ich leider nicht. Das System ist produktiv und ein anderes habe ich nicht. Sorry.

  • kfb77 : der Speicherverbauch von EPG ich sicher ein eigenes Kapitel, Im Augenblick suche ich nur die Ursache der Vermehrung um 700KiB/Std ohne EIT.

    Ein Grund könnte vielleicht ein fehlendes delete d in nit.c bei der Suche nach einem DVB-S2 Descriptor sein.

    Ich lasse den VDR gerade mit diesem Patch laufen, das Ergebnis dauert leider noch etwas, da ich zumindest 2 Durchläufe des Transponderscans abwarten muß, um eine Ändeung eindeutig zu erkennen.

  • Ein Grund könnte vielleicht ein fehlendes delete d in nit.c bei der Suche nach einem DVB-S2 Descriptor sein.

    Wird der DVB-S2 descriptor auch für DVB-C benutzt?. Min. zwei Leute, die unter diesem Leak leiden, benutzen ja Kabel.

  • Es sieht so aus, als ob mit dem "delete-d" Patch der Seicherverbrauch jetzt nach dem ersten vollständigen Transponderscan konstant bleibt. In den letzten 2 Stunden hat "top" nur einmal eine Steigerung um 8 KiB angezeigt.

    Der Eit-Filter war dabei deaktiviert.


    @nvertigo : Der DVB-S2 descriptor hat nur für DVB-S Relevanz, diese Überprüfung findet aber immer statt, auch wenn es nur DVB-T oder DVB-C Descriptoren geben kann.

    Hat vielleicht die Anzahl an DVB Geräten, oder deren System einen Einfluss auf das Speicherleck?

    Das Speicherleck in nt.c hätte sich schon mit der Anzahl der Geräte vervielfacht. Mit nur einem Device erfolgt der Transponderwechsel durch den Eitscanner 120 180 mal pro Stunde. Wenn 2 Devices zur Verfügung stehen, kann der Wechsel 240 360 mal pro Stunde erfolgen - und damit auch doppelt soviel Speicher verbrauchen. Das ist auch unabhängig von der Größe der channels.conf, es wird nur mehr oder weniger oft auf den gleichen Transponder getuned.

    Bei den von mir gemessenen 700 KiB/Std. wurde nur mit einem DVB-S Tuner gescanned.


    Edit: der Eitscanner wechselt alle 20s den Transponder, das ergibt dann klarerweise 180 Transponderwechsel pro Stunde pro Device.

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

    Einmal editiert, zuletzt von HelmutB ()

  • 700 kB / h / Gerät macht dann rund 100 MB / 24h mit 6 Geräten. Das klingt schonmal nicht so schlecht. Ich denke das ist ein heißer Kandidat. Würde mich sehr freuen, wenn das die Ursache war.

  • Ich bin mir nicht sicher, ob der Patch wirklich die vollständige Lösung deines Problems ist, da der belegte Speicher auch nach einem einfachen restart des VDR nicht mehr zur Verfügung gestanden wäre,

    Und in deiner Grafik im 1. Post geht die Speicherbelegung nach dem systemctl restart vdrwieder annähernd an die Ausgangsposition zurück.

    Ich werde das in den nächsten Tagen mit aktiven EPG auch noch vergleichen.

  • Ich beobachte jetzt auch mal den Speicher hier und habe zusätzlich https://github.com/WuBingzheng/libleak auf meinem Server reingehängt. Mal sehen, welche Aufschlüsse das bringt.... Den eit Patch und den delete-d habe ich drin.

    Gruß

    Andreas


  • prod ohne Patch, test mit Patch von HelmutB , auf beiden laufen Aufnahmen, auf dem prod wesentlich mehr, wie auf test.

    Edit: beide mit epg Scan.

    Zwei Tage sind natürlich sehr wenig, aber ich glaube, eine erste Tendenz kann man erkennen: Hat leider nichts gebracht.

    Einmal editiert, zuletzt von kfb77 ()

  • Ein Grund könnte vielleicht ein fehlendes delete d in nit.c bei der Suche nach einem DVB-S2 Descriptor sein.

    Klasse! Das ist auf jeden Fall schon mal ein sehr wichtiger Fund!

    Ich habe testweise mal die Schleife nicht nur einmal, sonder immer hundert Mal durchlaufen lassen (ohne 'delete d') und damit wuchs der Speicherverbrauch rasant an. Ich lasse das mit 'delete d' jetzt mal die nächsten Tage auf meinem VDR laufen und beobachte.

  • Ich beobachte auf meinem Server auch eine ständig steigende Speicherauslastung. Bei mir sind es hier ca. 500kB/h.

    Die beiden Patches (delete-d + eit)habe ich drin. Ich habe auch mit libleak gestartet, was nach 1h Laufzeit begann zu analysieren. Gibt natürlich jede Menge logs und ich bin noch nicht durch... Was mit aber aufgefallen ist, dass hier ganz oft 1byte alloziert wird, auch wenn strlen(ShortText) == 0 ist. Wäre es nicht richtig, es so zu machen, wie hier?

    Ich habe ein paar allocs aus dem libleak-log rausgepickt -> https://pastebin.com/raw/Tsjyp43M Das sind überwiegend reallocs. callstack[2957]z.B. ist da richtig gut dabei. Vielleicht hilfts ja.


    Gruß

    Andreas

  • rell Das sollte zwar nicht zum Memory Leak führen, aber grundsätzlich ist das natürlich ein berechtigter Einwand.

    Eventuell wäre diese Änderung an strcpyrealloc() nicht schlecht:

    Das würde dann gleich alle entsprechenden Stellen betreffen. Die Abfrage von '!isempty(Description)' in epg.c könnte dann vielleicht auch entfallen. Ich hab das mal schnell probiert, es kommen dann aber Abstürze, weil anscheinend auf cChannel::Name() zugegriffen wird ohne auf NULL zu testen. Anscheinend gibt es Zeiten, zu denen "namenlose" Kanäle existieren, die mit der bisherigen Methode wohl zu "leeren Strings" wurden (also "\0"). Muss ich mir erst noch genauer anschauen. Für das aktuelle Problem dürfte das aber nicht maßgeblich sein.

  • Ich habe heute den VDR ohne EIT-Filter aber mit einer 4-Tage alten epg.data gestarted.

    Zuvor habe ich in cEpgDataWriter::Perform() einen Zähler der Events Vor und Nach dem cEvents::CleanUp() eingebaut.

    Beim ersten CleanUp() werden von 176738 Events 70752 davon als veraltet gelöscht.

    Und obwohl rd. 40% der Events entfallen wirkt sich dass überhaupt nicht auf die Speichernutzung aus. Ich schätze, das es nach dem Purge in meinem Fall ca. 50 MB mehr freier Speicher seiin sollten.


    Ich habe zuerst den ListGarbageCollector in Verdacht gehabt, der "zerstört" aber wie geplant alle 70000 Events 5 min. nach dem CleanUp. Aber auch ohne GarbageCollecor wird der Speicherverbrauch nicht weniger.

    Hier die Ausgabe von Top zusammen mit den CleanUp() Meldungen aus dem syslog:

    rell : siehst du im libleak Log irgend eine Hinweis auf ein "free" durch ListGarbageCollector::Purge()?

Jetzt mitmachen!

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