vdradmin-am lahmt um die wette

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

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...

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.

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

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...

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:

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

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?

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

mal so als idee - amair koennte ja "webserver daemon" und "epg scan / autotimer daemon"
trennen, dann sollte das allgemein wesentlich flotter laufen, oder? so wirds ja bei kommerziellen
produkten meistens auch gemacht

-- randy

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.

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