vdradmin-am lahmt um die wette

  • Hallo nochmals!


    Habt ihr auch diese enorm langen Wartezeiten? Nutze debian testing und vdradmin-am von e-toby bezogen. Großartig habe ich nichts an den Standardeinstellungen verändert. Jedenfalls, wenn ich http://myvdr:8001 aufrufe und dann zum Beispiel auf Zeitleiste oder sonstwohin klicke, dann kann es gut und gerne schonmal 20 Sekunden dauern. Eben sogar mal eine Minute.


    Es ist ein 800MHz Rechner - also eigentlich auch keine Krücke.


    Grüße!

  • Hiho,


    Mein vdradmind antwortet recht flott. Ich sehe da mehrere Möglichkeiten:


    1. Der Rechner, auf dem vdradmind läuft, ist anderweitig beschäftigt. Mach mal ein uptime. Wenn die letzten drei Zahlen deutlich über 1 liegen, solltest du dir Gedanken machen, ob wirklich alles, was auf dem Rechner läuft, nötig ist.


    2. Du hast ein Netzwerkproblem. Mach mal einen ping myvdr.
    2a) Dauert es lange, bis die pings wirklich starten? Dann klappts mit der Namensauflösung nicht.
    2b) Die Antwortzeiten sollten kurz sein. Alles über 0,200 ms ist im lokalen Netz eigentlich nicht tolerabel. Und es dürfen auch keine Pakete verloren gehen.


    Wenns das alles nicht ist, müssen andere helfen ;)

    Hardware: Compaq Presario mit Athlon 750, Technotrend/Hauppauge Pinnacle PCTV 300i DVB-T + PAL, Audio onboard VIA 82xx.
    Software: Gentoo Linux, Kernel 2.6.27-gentoo-r8, vdr-1.6.0_p2-r2

  • Dieses Verhalten kann ich auf meinem schwächeren System (siehe Signatur: vdr1) auch beobachten.


    Und es liegt bei mir definitiv nicht an Netzwerkploblemen oder an im Hintergrund laufenden Diensten.


    Wenn ich das Verhalten mittels top beobachte nimmt vdradmind beim Zugriff auch die CPU ziemlich in Beschlag.
    Auf dem schnelleren System kommt die Antwort von vdradmin sehr flott.


    IMHO steht es auch mit der Größe der erzeugten Liste in Zusammenhang, egal ob Timer, Aufnahmen, Was läuft jetzt...

    VDR1: AMD Duron-1300, 512mb RAM, Nexus-S rev2.1, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    VDR2: Athlon XP-M-2600+, 512mb RAM, TT Prem 1.3 DVB-S, Skystar2, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    Extern: Activy300, Gen2VDR V2

  • Das Problem hatte ich auch, bis ich jedlichen Mist entfernt habe.


    Beim Hochladen von VDRAdmin werden die ganzen EPG.data und die Channels eingelesen.


    Einfach, die verschl.Sender und alles überflüssige löschen und dann sollte es in max. 5 Sek da sein.

    1. VDR (Server)
    Dell Optiplex GX110 - PIII 800 MHz - 196MB RAM - Technotrend 2.3 modded DVB-S FF- Hauppauge DVB-S budged - DVD-Brenner Nec ND-1300A - 250GB Hitachi Festplatte
    LinVDR 7.0 / Kernel 2.6.15 / Marc Twain Patch Mai 2005 / Tarandor Lib Patch 13.3.2006 / Cody Patch 1.4.0


    2. VDR (Test-Client) ASUS Board - CPU 400 Mhz - 196 MB RAM - DXR3-EM8300 Hollywood Karte - CD-ROM - 10 GB Festplatte
    LinVDR 7.0 / Kernel 2.6.14 / Marc Twain Patch Mai 2005 / Tarandor Patch / Cody Patch 1.3.37

    Edited once, last by do1omo ().

  • Hi,


    auf meinem plattenlosen 600er C3 laeuft das normal schnell... unter 2 Sekunden im Normalfall. Allerdings DVB-T und damit nicht so irre viele Sender...


    Distri ist Gentoo mit selbst dazugebautem vdradmin-am, weil original im Portage nur der vdradmin aus der Steinzeit dabei ist.


    Viele Gruesse,


    Jan

    Hardware: ASRock AM2NF3-VSTA + AMD Sempron 3200+ (1,8 GHz, meist 1,0 GHz) mit Fujitsu Siemens DVB-C FF (ohne Kabelsignal), 2 x TechniSat AirStar 2 DVB-T PCI und Terratec Cinergy T2 DVB-T USB 2.0 (als IR-Empfaenger ohne Antenne), Pollin 27x4 LCD, 1 GB DDR2, diskless, /video ueber NFS
    Software: Gentoo Linux 64 Bit (Kernel 2.6.24) mit VDR 1.4.7 aus den ebuilds mit einigen manuellen Anpassungen und wenigen Plugins (femon, dvd, remote, lcdproc)

  • Quote

    Original von JanR
    auf meinem plattenlosen 600er C3 laeuft das normal schnell... unter 2 Sekunden im Normalfall. Allerdings DVB-T und damit nicht so irre viele Sender...


    Zweiter Bremsklotz: Viele Autotimer - die Suche danach dauert...

    LG
    Jochen


    Rpi4 headless mit MLD 5.4 als Server via satip-Plugin hinter einem Telestar Digibit Twin, ein Rpi3 als Streamdev-Client mit MLD 5.4

    Rpi3 auch hinter Telestar Digibit Twin und mit MLD 5.4

  • Quote

    Original von taraquedo
    Es ist ein 800MHz Rechner - also eigentlich auch keine Krücke.


    Ich habe einen ähnlich schnellen Rechner und vdradmin-am ist bei mir auch nicht allzu schnell. Ich habe mal in den Code reingeguckt und diesen (auf Anhieb) noch nicht so ganz durchschaut, aber es sieht mir so aus, dass vdradmin-am unnötig häufig intern EPG-Daten zwischen Perl-Arrays und -Hashes hin- und herkopiert und sortiert.


    Mal sehen, vielleicht kann man daran etwas drehen.

  • Ein kleines Problem dürfte es im mainloop von vdradmind.pl geben.


    Der Aufruf von UptoDate(1) in Zeile 437 (vdradmind.pl v3.4.6.beta2), erzwingt immer die Aktualsierung des Cache, d.h. der Configparameter CACHE_TIMEOUT kommt nicht zum Tragen.


    Die folgende Änderung brachte mir doch deutliche Besserung, ich werde das Problem Andreas mailen.


    Folgender Codeabschnitt ist betroffen:

    Code
    if (!$Client) {
        UptoDate(0);  <-- in Zeile 437 UptoDate(1) durch UptoDate(0) ersetzen
        next;
    }


    <edit>
    Eintrag in VDR-Developer Bugtracking: http://www.vdr-developer.org/mantisbt/view.php?id=48

    VDR1: AMD Duron-1300, 512mb RAM, Nexus-S rev2.1, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    VDR2: Athlon XP-M-2600+, 512mb RAM, TT Prem 1.3 DVB-S, Skystar2, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    Extern: Activy300, Gen2VDR V2

    Edited once, last by geeg07 ().

  • Hi,


    ich denke nicht, dass Dein Patch viel bewirkt, da der betreffende Codeblock nur ausgeführt wird, wenn $Client nicht gesetzt ist. D.h. wenn accept() auf einen Timeout läuft. Der Timeout ist so gesetzt, wie Ihr in der vdradmind.conf AT_TIMEOUT gesetzt habt.
    Also: der Block wird nicht ausgeführt, wenn Ihr einen Link in der Weboberfläche klickt, sondern nur wenn sich der VDRAdmin-AM langweilt.


    Vermutlich habt ihr AT_TIMEOUT niedrig gewählt, damit der AutoTimer immer auf aktuelle EPG-Daten zugreifen kann. Das ist mit dieser Änderung nicht mehr der Fall, da eine Aktualisierung nur noch wie bei CACHE_TIMEOUT eingestellt stattfindet.
    Natürlich entlastet das euer System, aber dann könnt ihr genausogut AT_TIMEOUT höher stellen ;)


    Sollte ich mich irren, lasse ich mich gerne eines besseren belehren.


    EDIT:
    Nur Interesse halber: was habt ihr für AT_TIMEOUT gesetzt?


    Gruß,
    Andreas

  • Quote

    Original von amair
    Nur Interesse halber: was habt ihr für AT_TIMEOUT gesetzt?


    Den Wert habe ich nie geändert, also:


    AT_TIMEOUT = 10


    Fakt ist, dass es (subjektiv) besser ist seit ich den Aufruf geändert habe.
    Ich habe das Verhalten sicher nicht in allen Konsequenzen getestet.
    Es tritt auch erst nach einiger Zeit auf, wenn vdradmin länger läuft.


    Werde jetzt einmal AT_TIMEOUT höher stellen, auf den Original-Aufruf von Uptodate() zurückstellen und testen.


    Welche Einheit ist AT_TIMEOUT eigentlich, Minuten?

    VDR1: AMD Duron-1300, 512mb RAM, Nexus-S rev2.1, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    VDR2: Athlon XP-M-2600+, 512mb RAM, TT Prem 1.3 DVB-S, Skystar2, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    Extern: Activy300, Gen2VDR V2

  • Quote

    Original von JanR
    Distri ist Gentoo mit selbst dazugebautem vdradmin-am, weil original im Portage nur der vdradmin aus der Steinzeit dabei ist.


    Dies stimmt so nicht, wenn du da Portage Overlay von gentoo.de nutzt ist dort auch das neuste vdradmin-am ebuild zu finden.
    Gruss,
    Mattheus

  • Hi,


    Quote

    Original von geeg07


    Den Wert habe ich nie geändert, also:


    AT_TIMEOUT = 10


    Default ist aber 120.


    Quote

    Fakt ist, dass es (subjektiv) besser ist seit ich den Aufruf geändert habe.
    Ich habe das Verhalten sicher nicht in allen Konsequenzen getestet.
    Es tritt auch erst nach einiger Zeit auf, wenn vdradmin länger läuft.


    Getestet habe ich es auch nicht, war nur ein Code-Review.
    Aber wenn es erst nach einiger Zeit auftritt, ist das Problem evtl. woanders zu suchen.


    Quote

    Werde jetzt einmal AT_TIMEOUT höher stellen, auf den Original-Aufruf von Uptodate() zurückstellen und testen.


    Welche Einheit ist AT_TIMEOUT eigentlich, Minuten?


    Ja, in Minuten.


    Gruß,
    Andreas

  • Hi,


    Quote

    Original von randy
    mal so als idee - amair koennte ja "webserver daemon" und "epg scan / autotimer daemon" trennen, dann sollte das allgemein wesentlich flotter laufen, oder?


    Gut, den AutoTimer-Check könnte man auslagern oder parallelisieren.
    Aber wieso den EPG-Scan auslagern?
    Irgendwie müssen die Daten ja dann doch wieder zum WebServer Daemon kommen, oder?
    Gut, kann man mit einer MySQL-DB machen, aber das wollt ihr doch auch nicht (sonst würdet ihr doch XXV einsetzen)...


    Quote

    so wirds ja bei kommerziellen produkten meistens auch gemacht :)


    Und die wären?


    Gruß,
    Andreas

  • weil viele timer aka autotimer vdradmin langsam macht?
    wo liegt das problem, diese separat zu handeln? und jede groessere applikation
    hat normalerweise einen eigenen "frontend daemon", z.b. trendmicro iwss,
    cisco mars ids, vdr ;) (verschiedene arbeitsthreads).


    aber war ja kein "du musst". wenn dir die geschwindigkeit langt, bei mir ist
    vdradmin unbrauchbar weil manche seiten gar nicht oder erst nach minuten
    geladen sind.



    -- randy

  • Quote

    Original von amair
    Hi,



    Default ist aber 120.


    Stimmt ;)
    Habe nun nochmal alles überprüft.
    Anscheinend habe ich einmal ein Backup gemacht, nachdem ich einiges getestet habe und vergessen die vdramin.conf wieder zurückzukopieren. Das backup dürfte ich dann auch einmal eingespielt haben.


    In meiner conf war auch CACHE_TIMEOUT = 10 was das Verhalten natürlich noch exterm verschlimmert.


    vdradmind.pl habe ich auch noch etwas analysiert, dort liegt das Problem nicht!


    Gut würde ich allerdings die Idee von Randy finden, den Autotimer-Check auszulagern, das ist nämlich der Part auf den man warten muss, wenn es der Zufall so will.


    Sorry für die Fehlmeldung und meine ungenaue Prüfung.

    VDR1: AMD Duron-1300, 512mb RAM, Nexus-S rev2.1, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    VDR2: Athlon XP-M-2600+, 512mb RAM, TT Prem 1.3 DVB-S, Skystar2, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    Extern: Activy300, Gen2VDR V2

  • Hi,


    Quote

    Original von geeg07
    Gut würde ich allerdings die Idee von Randy finden, den Autotimer-Check auszulagern, das ist nämlich der Part auf den man warten muss, wenn es der Zufall so will.


    Daran dachte ich auch schon. Mal schau'n wie und wann ich das lösen werde.


    Quote

    Sorry für die Fehlmeldung und meine ungenaue Prüfung.


    Kein Problem!
    Wenn sich nur alle Bug-Reporter mit dem Source-Code beschäftigen würden...


    Gruß,
    Andreas

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!