Blockaden durch epg2vdr (oder scraper2vdr)

Ist deine Hardware (CPU, HDD) tatsächlich sooooo alt?

Ich habe hier wirklich keine neue HW (siehe Signatur), aber zu broken videostream kam es hier noch nie wenn epgd & co am Werkeln sind.

Hohe CPU-Auslastung schon (wg. Maria-DB/MySQL).

Hier selbst auf einem Raspi kein Problem.

Auf die Platte werden auch nur die EPG Bilder für den Skin geschrieben - oder um welches Dateien geht es?

Liegt es wirklich am File IO? Wie performant ist das Filesystem? Was ist es für ein Filesystem, ein lokales?

Grüße

Jörg

Fortsetzung von hier ....

Es kann natürlich auch der externe Sql-Server sein. Aber gerade bei Remove old symlinks gibt es keinen Datenbankzugriff, nur auf Disk / Filestats.

Was sagt den time ls -Rl /var/cache/vdr/epgimages | wc .

Du könntest einmal probeweise /var/cache/vdr/epgimages in eine ramdisk (tmpfs) mounten und dann die Updatezeiten vergleichen (z.B. so für 1GB:sudo mount -t tmpfs -o size=1024M tmpfs /var/cache/vdr/epgimages. Die erforderliche "Size" kannst du vorher mit du -h /var/cache/vdr/epgimagesausfindig machen.

Helmut

Hab das bei mir auch mals ausprobiert. Die Daten liegen auf einer SSD.

time ls -Rl /var/cache/vdr/epgimages | wc
252193 2632038 23179723

real    0m4,321s
user    0m2,319s
sys     0m2,326s

für ca 2,5 GB wohlgemerkt:

du -h /var/cache/vdr/epgimages

2,5G /var/cache/vdr/epgimages

ls ist da arg langsam - ich würde da find nutzen: find /var/cache/vdr/epgimages/ -type f -name "*.jpg"

250k Bilder dürften doch etwas viel sein - ich würde die Bilder mal abräumen (sudo find /var/cache/vdr/epgimages -name "*.jpg" -delete) und schauen, was dann tatsächlich noch von epg2vdr und scraper2vdr vom Server neu geladen bzw. an Symlinks angelegt wird.

Falls sich deine Antwort auf meinen Post bezieht: ich habe/spüre keinerlei Probleme (mehr) mit epgd & co.

Wollte nur Fourty 2 einen zusätzlichen Vergleichswert geben.

Prinzipiell hast du aber natürlich recht: find ist viel, viel schneller:

real    0m0,921s
user    0m0,406s
sys     0m0,309s

Der Diskzugriff bei Fourty2 ist wirklich sehr langsam und erklärt die langen Updatezeiten. Es sollte mind. um den Faktor 10 bis 20 schneller gehen.

Quote from seahawk1986

250k Bilder dürften doch etwas viel sein

Bei Fourty2 sind es nur ca. 7500 "echte" Bilddateien, diese liegen unter /var/cache/vdr/epgimages/images.

Aber unter/var/cache/vdr/epgimages/werden dann über 400000 Symlinks mit EventId und lfn(?) angelegt die auf diese Bilder verweisen, das sind durchschnittlich fast 60 Symlinks auf jede Bilddatei.

Da der Inhalt von /var/cache/vdr/epgimages beim VDR-Start immer komplett mit der Datenbank abgeglichen wird, wäre eine Ramdisk vielleicht überhaupt die bessere und schnellere Lösung. Es ist nur die Frage wie groß diese sein muß. Wenn die Datenmenge wie bei davie2000 bis zu 2,5GB sein kann, müsste die Ramdisk dann schon eher für 5GB ausgelegt werden (sofern genug RAM vorhanden).

Helmut

Das time ls -Rl /var/cache/vdr/epgimages | wc war natürlich kein Speedtest sondern nur dazu gedacht, um ein Gefühl dafür zu bekommen, wie schnell dis Disk oder das ganze System bei Fourty 2 ist. Ein df /var und df -i /varkönnte noch den "Fülltstand" der Disk/Partition zeigen. Es scheint aber eher so zu sein, dass dieser langsame Diskzugriff den VDR blockiert.

Helmut

Das Verzeichnis /var/cache/vdr/epgimages nur in einer Ramdisk zu halten ist vielleicht auch nicht so gut, wenn das Einlesen aus der externen Datenbank 9 Minuten dauert.

Es gibt die Setupoption "LoadImages", damit kann das kopieren der Bilddateien aus der DB auf die Festplatte überhaupt unterbunden werden. Ich denke, dass dann die Bilder immer direkt aus der Datenbank geholt werden.

Im Sourcecode habe ich auch keine Referenzen auf die Symlinks gefunden. Wofür werden sie überhaupt benötigt?

Vielleicht weiss horchi mehr darüber, und auch warum sich bei dir so viele offensichtlich unnötige Symlinks ansammeln.
Helmut

Quote from Fourty2

Denke, die Links werden vom VDR über die Skins (hier skinnopacity) aufgerufen.

Da hast du recht. Dass die EPG Bilder und Symlinks unter /var/cache/vdr/epgimages liegen dürfte Standard sein (oder ein gewachsener defacto Standard).

Und dass sich mit epg2vdr viele unnötige Symlinks ansammeln ebenso :).

Eine Suche hier im Forum zeigt, dass es das Problem schon länger gibt. Abhilfe scheint aber nur ein regelmäßges manuelles Leeren des Cache-Verzeichnis zu sein und dieses auf einer schnellen Platte zu betreiben. davie2000 hat das löschen einmal so gelöst:

/var/cache/epgd u.a. - wie sinnvoll bereinigen?

Wenn die Bilder nicht mehr gibt, sollten die unnötigen Symlinks von vdr2epg automatisch entfernt werden.

Helmut

Quote from Fourty2

....

Das wird auch hier einmal im Monat bereinigt. "rm" ..

(Und läuft 24/7 auf einem anderen Rechner)

Stefan

Wie bereinigst Du das, Stephan?

Quote from Fourty2

aber es gibt keine Routine, die Altes entfernt

cUpdate::cleanupPictures() sollte das eigentlich machen, aber das scheint nur dann ausgeführt zu werden, wenn man mittels svdrpsend plug epg2vdr update (oder reload) einen Abgleich anstößt.