Speicherverbrauch steigt mit der Zeit

  • Wie kommt man dem Verursacher auf die Spur. Hab keine Programmierkenntnisse...

    Ich würde anfangen mir mal die Einzelnen VDR-Threads anzusehen. (das ging AFAIK mit "H" in top)

    Anhand der PIDs und Logfiles kann man die Threads dann den Plugins bzw. dem VDR selber zuordnen.

    Dann weiss man wenigstens wo in etwa es hängt.



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

    Vielleicht so:

    /usr/bin/top -b -n 1 | grep -m 1 -e 'vdr$'


    Damit bekomme ich dann sowas:

    Interessant, der Anstieg scheint linear zu sein und immer die gleiche Steigung zu haben.

    Damit kann man eigentlich alles, was mit User-Interaktion, Aufnahmen, EPG usw. zusammen hängt auszuschliessen.


    100MiB pro Woche sind etwa 170Byte pro Sekunde. Das könnte ein Puffer sein, der jede Sekunde erstellt und dann vergessen wird.


    Blöde Frage:

    Ist es möglich den Intervall, in dem der Mainloop läuft zu verkürzen?

    Wenn man denn doppelt so häufig laufen lässt und der Spericherverbrauch doppelt so schnell steigt, grenzt das die möglichen Fehler etwas ein.

    Gruss
    SHF


  • lnj

    Wollte den VDR aktualisieren. Leider baut jetzt das SHD nicht mehr:
    https://www.dropbox.com/s/i8tbw2xqa5z9chh/make_shd.log?dl=0

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Dann fang am besten oben an das Gewirr aufzulösen:

    Code
    1. WARNING, you have libavresample and libswresample together!!!

    Also am besten erst mal libavresample entfernen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Irgendwelche Nebenwirkungen sind dadurch nicht zu erwarten?


    Beim zweiten Blick auf das Diagramm hab ich aber festgestellt, dass es sich wohl erst nach mindestens zwei Wochen ein aussagekräftiger Anstieg zeigt.

    Ich gehöre zu der Gruppe, wo der VDR normalerweise nie solange durch läuft. Da muss ich ers tmal schauen, ob ich überhaupt was erkennen kann.

    Gruss
    SHF


  • Ich habe das Skript von Klaus genommen und lasse es stündlich per cron laufen und die Ausgabe loggen.


    Bei mir ist der Speicherverbrauchanstieg auf jeden Fall mehr!


    Das hilft aber nicht weiter, da die Ursache sicherlich ein Plugin ist, sonst wäre das ja verbreiteter und ich nicht immer der Einzelfall


    pmap: https://www.dropbox.com/s/7tyy7mvh20q37ga/vdrpmap.txt?dl=0

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Das hilft aber nicht weiter, da die Ursache sicherlich ein Plugin ist, sonst wäre das ja verbreiteter und ich nicht immer der Einzelfall

    Versuch es mal mit:

    top -H -o RES -b -n 1 | grep -e 'vdr$'(oder besser -o VIRT?)

    Da bekommst du den Speicherverbrauch nach Threads aufgeteilt.

    Dann musst du nur schauen, zu welchem Plugin der Übeltäter gehört.




    Ausser einer eventuell etwas höheren CPU-Last sehe ich da nichts.

    Dann wäre es wohl am besten, wenn es mal jemand versucht, dem das Leck eh schon aufgefallen ist.


    Kommt man an die Rohdaten vom rrdtool eigentlich noch ran?

    Mich würde primär der lange Anstieg Oktober/November 19 interessieren.

    Das wären genug Daten, um das Rauschen durch EPG usw. zuverlässig raus zu filtern, denke ich.

    Wenn man dann annimmt, dass der Fehler aus dem Mainloop aufgerufen wird und konstant ist, wüsste man die Grösse des Speichers, die jedes mal nicht wieder freigegeben wird.

    Vielleicht findet man eher was, wenn man weiss wir gross das Objekt ist, nach dem man sucht.

    Gruss
    SHF


  • Versuch es mal mit:


    top -H -o RES -b -n 1 | grep -e 'vdr$'(oder besser -o VIRT?)

    Kommt bei beiden Optionen das gleiche raus. Und die Threads werden auch nicht alle gezeigt und außerdem mit den gleichen Werten


    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Das zeigt zwar die Threads aber ohne nutzbare Werte

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Sag bitte bescheid, wenn du sie geholt hast.

    Hab ich.

    Scheint aber ein Binärformat zu sein. Da muss ich mich wohl erstmal schlau machen, wie man da an die Daten kommt.


    Das zeigt zwar die Threads aber ohne nutzbare Werte

    Auch, wenn es eine Weile gelaufen ist?

    Wenn ein Prozess geforkt wird, übernimmt er wohl das Speicherlayout des Elternprozesses. Ich hätte jetzt aber erwartet, dass sich das mit der Laufzeit ändert.

    Mit dem VDR hab ich das noch nicht versucht, aber einer der Prozesse müsste eigentlich grösser werden. Bei anderen Programmen hatte ich das schon gesehen.

    Gruss
    SHF


  • Auch, wenn es eine Weile gelaufen ist?

    Wenn ein Prozess geforkt wird, übernimmt er wohl das Speicherlayout des Elternprozesses. Ich hätte jetzt aber erwartet, dass sich das mit der Laufzeit ändert.

    Lief da gerade knapp zwei Stunden. Bringt also nichts. Nur pmap zeigt was an, was ich aber nicht auswerten kann


    top - 16:43:33 up 1:53, 1 user, load average: 0.33, 0.32, 0.40

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • kls

    Ich glaube, ich habe einen Leak gefunden: Müsste nach einem memmove nicht auch ein realloc kommen, um den Speicher freizugeben ?

    VDR
  • Jetzt haben sich die Posts überschnitten.

    Ich denke nicht, denn hier wird ja innerhalb eines bestehenden Speicherblocks ein Teil davon "nach vorne" verschoben. Der Speicherblock als Ganzes bleibt unverändert.

    Stimmt, müsste dann aber nicht size gleich bleiben, damit der freie Platz hinten auch wieder für ein neues Element verwendet wird.

    VDR
  • Ich widerspreche hier mir mal selber: Die Größe wird über allocated verwaltet, size bestimmt nur die belegte Objekte. Somit alles richtig.

    Sorry for the noise.

    VDR
  • Nach Auswertung der Daten scheint der Anstieg wirklich sehr gut linear zu sein.

    In Zahlen komme ich auf: 652.27Byte/Sekunde bzw. 376.22MiB/Woche.


    Jedenfalls ist es mehr als die 100Mib die bislang im Raum standen.

    Eigentlich muss der fragliche Block doch grösser oder gleich 652.27Byte sein?

    Das ist ja nicht so ganz klein, vielleicht hilft das die Suche einzugrenzen?

    Gruss
    SHF