Das kann ich mir nicht vorstellen. Auch für EPG wäre das viel zu viel. Aber sollte es an einem von beidem, oder beidem liegen, sollte sich die Steigung ändern, sobald ich die Kanalliste reduziere. Test kommt die Tage.
Speicherleck im VDR oder einem Plugin
-
-
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 ) 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.
Ups, meine Signatur habe ich schon länger nicht mehr angepasst...
Mein VDR-Server - der RAM-Verbrauch ist iO - aber: es ist auch nicht die aktuellste VDR-Version...
vdr 2.4.4
epg2vdr
epgsearch
live
markad
scraper2vdr
wirbelscan
satip
-
Danke Stefan
Vielleicht kannst du in ein paar Tagen nocheinmal nachsehen. Aktuell braucht dein VDR ~290 MB, meiner liegt gerade bei 555 MB. Die absoluten Zahlen sagen natürlich nichts aus, aber wenn wir in ein paar Tagen nocheinmal vergleichen, sehen wir den Trend.
Ich habe auch "nur" VDR 2.4.1
Ich bin echt gespannt auf den Test mit weniger Kanälen. Aber wenn das was verändern würde, was sollen dann die DVB-S Nutzer mit mehreren tausend Kanälen sagen? Kann ich mir auch noch nicht so recht vorstellen. Ich lasse den jetzt noch eine Weile so laufen, mit den deaktivierten Plugins. Danach ist die channels.conf fällig.
Vielen Dank an alle die hier unterstützen!
-
Der VDR läuft nun seid ziemlich genau drei Tagen mit nur dem einen Plugin, streamdev-server. Der Speicherverbrauch ist seid dem von 180 MB nach Start um 560 MB auf 740 MB angestiegen.
560 MB / 3 Tage = 186,7 MB / Tag.
186,7 MB / 24 Std. = 7,778 MB / Std.
7,778 MB / 60 Min. = 130 kB / Min.
130 kB / 60 Sek. = 2,16 kB / Sek.
Vielleicht kommen ja dem einen oder anderen diese Zahlen bekannt vor? Nur für den Fall.
-
Ich weiß nicht ob ich auf einer falschen Fährte bin, aber beim
BastelnEntwicklen eines EPG-Handlers sind mir da Ungereimtheiten aufgefallen.Normalerweise würde ich ein Sequenz
- BeginSegmentTransfer()
- HandleEvent() (und alle anderen Set* Aufrufe)
- EndSegmentTransfer()
erwarten.
Geloggt habe ich mit isyslog jeweils den Start und das Ende von Begin/EndSegmentTransfer() und Aufrufe von HandleEvent(). Ich gehe davon aus, dass isyslog die Meldungen in der der Reihenfolge schreibt wie sie auftreten (also nicht zeitlich umsortiert) . Das sieht dann so aus:
2021-12-09T10:49:24.837602+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-1-1061-10355 hr-fernsehen HD
2021-12-09T10:49:24.837634+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont 2021-12-09T10:49:24.837666+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT Start handler.cpp(152) idle 2021-12-09T10:49:24.837698+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT End handler.cpp(162) idle
2021-12-09T10:49:24.837731+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-1-1101-28108 hr-fernsehen
2021-12-09T10:49:24.837767+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont 2021-12-09T10:49:24.837799+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-1-1101-28108
2021-12-09T10:49:24.837832+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-1-1101-28108
2021-12-09T10:49:24.837877+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT Start handler.cpp(152) modified
2021-12-09T10:49:24.837910+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT End handler.cpp(162) modified
Es gibt aber auch Sequenzen bei denen die Reihenfolge nicht eingehalten wird wenn es mehrere Threads für die EIT-Verarbeitung gibt:
.... vdr: [31152] device 1 section handler thread started (pid=31146, tid=31152, prio=low)
.... vdr: [31155] device 2 section handler thread started (pid=31146, tid=31155, prio=low)
2021-12-09T10:49:24.837943+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-1-1011-11110 ZDF HD
2021-12-09T10:49:24.837995+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
2021-12-09T10:49:24.838037+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-1-1011-11110
2021-12-09T10:49:24.838275+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-1-1011-11110
2021-12-09T10:49:24.838341+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-1-1011-11110
2021-12-09T10:49:24.838475+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-1-1011-11110
2021-12-09T10:49:24.838579+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT Start handler.cpp(152) modified
2021-12-09T10:49:24.838613+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-133-15-38 HGTV
2021-12-09T10:49:24.838646+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
2021-12-09T10:49:24.838678+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT End handler.cpp(162) modified
2021-12-09T10:49:24.838757+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-133-15-38
2021-12-09T10:49:24.838791+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-133-15-38.....
2021-12-09T10:49:24.839083+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-133-15-38
2021-12-09T10:49:24.839115+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-133-15-38
2021-12-09T10:49:24.839147+01:00 devel vdr: [31155] xmltv4vdr: END_SEGMENT Start handler.cpp(152) modified
2021-12-09T10:49:24.839179+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-1-1011-11130 zdf_neo HD
2021-12-09T10:49:24.839212+01:00 devel vdr: [31155] xmltv4vdr: END_SEGMENT End handler.cpp(162) modified
2021-12-09T10:49:24.839244+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
2021-12-09T10:49:24.839278+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-1-1011-11130
2021-12-09T10:49:24.839311+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-1-1011-11130
2021-12-09T10:49:24.839343+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT Start handler.cpp(152) modified
2021-12-09T10:49:24.839375+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT End handler.cpp(162) modified
Und da kommt dann auch öfter mein EPG-Handler aus dem Tritt:
2021-12-09T10:49:24.936886+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-133-15-39 ShopLC HD
2021-12-09T10:49:24.936919+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
2021-12-09T10:49:24.936959+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-133-15-39
2021-12-09T10:49:24.936994+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-133-15-39
2021-12-09T10:49:24.937026+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-133-15-39
2021-12-09T10:49:24.937058+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-133-15-39
2021-12-09T10:49:24.937094+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-133-15-39
2021-12-09T10:49:24.937127+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-133-15-39
2021-12-09T10:49:24.937160+01:00 devel vdr: [31155] xmltv4vdr: END_SEGMENT Start handler.cpp(152) modified
2021-12-09T10:49:24.937193+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-1-1011-11110 ZDF HD
2021-12-09T10:49:24.937226+01:00 devel vdr: [31155] xmltv4vdr: END_SEGMENT End handler.cpp(162) modified
2021-12-09T10:49:24.937259+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
2021-12-09T10:49:24.937292+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT Start handler.cpp(152) idle
2021-12-09T10:49:24.937325+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-133-15-39 ShopLC HD
2021-12-09T10:49:24.937360+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
2021-12-09T10:49:24.937392+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT End handler.cpp(162) idle
2021-12-09T10:49:24.937425+01:00 devel vdr: [31155] xmltv4vdr: END_SEGMENT Start handler.cpp(152) idle
2021-12-09T10:49:24.937460+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-1-1011-11130 zdf_neo HD
2021-12-09T10:49:24.937494+01:00 devel vdr: [31155] xmltv4vdr: END_SEGMENT End handler.cpp(162) idle
2021-12-09T10:49:24.937526+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
2021-12-09T10:49:24.937559+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-1-1011-11130
2021-12-09T10:49:24.937592+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-1-1011-11130
2021-12-09T10:49:24.937627+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-1-1011-11130
2021-12-09T10:49:24.937659+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-1-1011-11130
2021-12-09T10:49:24.937691+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-1-1011-11130
2021-12-09T10:49:24.937723+01:00 devel vdr: [31152] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-1-1011-11130
2021-12-09T10:49:24.937755+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-133-15-33 Genius family
2021-12-09T10:49:24.937788+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT Start handler.cpp(152) modified
2021-12-09T10:49:24.937820+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
2021-12-09T10:49:24.937852+01:00 devel vdr: [31152] xmltv4vdr: END_SEGMENT End handler.cpp(162) modified
2021-12-09T10:49:24.937886+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-133-15-33
2021-12-09T10:49:24.937919+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-133-15-33
2021-12-09T10:49:24.937951+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent Start handler.cpp(248) S19.2E-133-15-33
2021-12-09T10:49:24.937984+01:00 devel vdr: [31155] xmltv4vdr: HandeleEvent End handler.cpp(430) S19.2E-133-15-33
2021-12-09T10:49:24.938016+01:00 devel vdr: [31155] xmltv4vdr: END_SEGMENT Start handler.cpp(152) modified
2021-12-09T10:49:24.938048+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-1-1011-11130 zdf_neo HD
2021-12-09T10:49:24.938081+01:00 devel vdr: [31155] xmltv4vdr: END_SEGMENT End handler.cpp(162) modified
2021-12-09T10:49:24.938113+01:00 devel vdr: [31152] xmltv4vdr: ERROR sqlite3 E19: BEGIN -> 1 cannot start a transaction within a transaction
2021-12-09T10:49:24.938151+01:00 devel vdr: [31152] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) abort
2021-12-09T10:49:24.938184+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT Start handler.cpp(120) S19.2E-133-15-37 Nicer Dicer TV
2021-12-09T10:49:24.938217+01:00 devel vdr: [31155] xmltv4vdr: BEGIN_SEGMENT End handler.cpp(140) cont
Bräuchte man dann da nicht jeweils eine eigene cEPGHandler-Instanz pro section handler Thread um den thread local storage sauber zu trennen?
Evtl. kommt da auch der VDR mit der Verwaltung seiner EIT-Daten durcheinander?
-
Hallo wirbel ,
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.
das klingt interessant.
Ich mache das, wie sicher viele Andere auch, mit einem restart vom vdr, mit allen Konsequenzen.
das Menü des VDR bekomme dazu ich über das control Plugin.
Das heißt, das vdr-Menü selbst wird nicht aktualisiert?
Wäre es möglich, dieses Plugin mal zur Verfügung zu stellen?
Viele Grüße
kamel5
-
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.
Probiert es bitte mal hiermit (ungetestet):
Diff
Alles anzeigen--- eit.c 2021/04/28 20:44:56 5.3 +++ eit.c 2021/12/09 12:31:11 @@ -432,9 +432,9 @@ EpgHandlers.DropOutdated(pSchedule, SegmentStart, SegmentEnd, Tid, getVersionNumber()); } } + EpgHandlers.EndSegmentTransfer(Modified); SchedulesStateKey.Remove(Modified); ChannelsStateKey.Remove(ChannelsModified); - EpgHandlers.EndSegmentTransfer(Modified); } // --- cTDT ------------------------------------------------------------------
-
Wäre es möglich, dieses Plugin mal zur Verfügung zu stellen?
Ist es schon lange, https://www.gen2vdr.de/wirbel/easyvdr/index2.html
-
Ist es schon lange, https://www.gen2vdr.de/wirbel/easyvdr/index2.html
Danke, das kannte ich noch nicht.
Grüße
kamel5
-
Probiert es bitte mal hiermit (ungetestet):
Uii, das ging ja flott!
Ich hab's eingebaut und werde berichtenEdit: sieht bisher so aus, als wäre das die Ursache gewesen
-
Allerdings ist der EPG-Scan ausgeschaltet.
Ich kann bestätigen, ohne EPG Scan kein Leak.
Mit diesem Skript und täglichem Aufruf 3 Tage lang getestet:
Bash#!/bin/bash MEM=`/usr/bin/top -b -n 1 | grep -w vdr | head -1` DATE=`date +%F` echo $DATE $MEM >> /root/vdr_memtest
Produktiver VDR mit EPG Scan, jeden Tag 150 MB bis 200 MB zusätzlich:
Code2021-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
Test Server ohne EPG Scan, absolut konstanter Speicherverbrauch:
Code2021-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
VDR und Plugins Versionen für beide Server, alles aus yavdr 0.7 Repository:
Codevdr (2.4.7/2.4.7) - The Video Disk Recorder conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu epg2vdr (1.1.118-GIT) - epg2vdr plugin epgsearch (2.4.1) - search the EPG for repeats and more epgsearchonly (0.0.1) - Direct access to epgsearch's search menu live (3.1.3) - Live Interactive VDR Environment markad (3.0.18) - Mark advertisements quickepgsearch (0.0.1) - Quick search for broadcasts satip (2.4.1) - SAT>IP Devices streamdev-server (0.6.1-git) - VDR Streaming Server
-
Wow. Die Frage ist ob kls da eine Idee hat was da beim EPG-Scan schief geht. Allerdings wurde dann ja vermutlich auf dem Test-Server auch nie großartig gezappt und Worst-Case kein Sender getunt. Also wird gar keine EPG aktualisiert, richtig?
Ich bin gespannt was der Test mit der reduzierten channels.conf zeigt. Wenn die Theorie stimmt sollte dann, trotz aktivem EPG-Scan, die Steigung der Geraden kleiner sein.
-
Allerdings wurde dann ja vermutlich auf dem Test-Server auch nie großartig gezappt und Worst-Case kein Sender getunt. Also wird gar keine EPG aktualisiert, richtig?
Nein, ich nutze den Testserver manchmal als Überlauf. Er hat aktuell auf 6 Kanälen EPG Daten, die durch Aufnahmen auf dem Kanal entstanden sind. Programmiert wurden die Aufnahmen über Live vom produktivem Server aus mit der remote Timer Funktion.
Edit: Ich hatte heute nochmals eine Aufnahme auf dem Testserver laufen. Das war wohl ein neuer Kanal, es gab eine minimale Änderung vom Speicherverbrauch (130 Bytes):
Ich lasse den Test weiterlaufen und werde nach ein paar Tagen nochmals die Ergebnisse posten.
-
Uii, das ging ja flott!
Ich hab's eingebaut und werde berichtenEdit: sieht bisher so aus, als wäre das die Ursache gewesen
Was genau meist du damit? Dass dein EPG Handler nicht mehr durcheinander kommt, oder die Ursache für das Speicherleck?
-
Ich meine damit, dass mein EPG Handler nicht mehr durcheinander kommt.
Ich glaube nicht, dass die Vertauschung der Reihenfolge das Speicherleck beseitigt, auch wenn es anfangs so aussah, als würden die beiden Phänomene zusammen hängen.
Schaden kann es aber auch nicht mal zu testen, ob der Patch Auswirkungen auf das Speicherleck hat ....
-
Okay, danke für die Aufklärung. Ich werde dieses Wochenende den Test mit der reduzierten channels.conf vornehmen. Bin auch sehr gespannt. Auf jeden Fall hätten wir dann schonmal einen roten Faden.
-
Ich glaube nicht, dass die Vertauschung der Reihenfolge das Speicherleck beseitigt
Das glaube ich auch nicht, da ich keinen EPG-Handler verwende und dennoch das Speicherleck-Problem habe.
-
Kanalliste ist auf 56 Kanäle gekürzt, von vormals ~500 Kanälen. Plugins wie im ersten Post wieder aktiviert, die Deaktivierung hat keinerlei Auswirkungen gehabt.
10.12.21, 16:45, 93416 kB
-
Ich stelle folgende Frage in den Raum:
.. warum MUSS der vdr ( Core ) immer laufen ?
Schau jemand ununterbrochen fern ? -
Ich stelle folgende Frage in den Raum:
.. warum MUSS der vdr ( Core ) immer laufen ?
Schau jemand ununterbrochen fern ?Ja, in meiner Verwendung laufen bis zu 8 Tuner pro Server permanent (24h*356) und liefern insgesamt so knapp 130 Radio-Streams an ein internes System aus. Die Kisten auf denen der VDR läuft haben aber relativ viel Speicher, so daß selbst bei monatelangem Dauerlauf kein echter Ausfall durch den Speicherverbrauch verursacht wurde. Restart des VDR erfolgt höchstens mal nach größeren Änderungen an der Kanaltabelle, falls manueller Eingriff nötig ist.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!