[0.5 alpha] ... Ist träge

henfri · 15. Juli 2012

Hallo,

ich habe beim Browsen in den Aufnahmen das Problem, dass der VDR sehr träge reagiert. Eben so, dass man die Taste nochmal drückt (Reaktionszeiten von 2-5 Sekunden).

Ich muss dazu sagen, dass die Aufnahmen per NFS eingebunden sind -das war aber früher auch schon der Fall und sollte ja z.B. bei einem "zurück" nicht für eine Verzögerung sorgen. Auch liest der VDR die Verzeichnisse ja eigentlich beim start oder ".update" ein und nicht, wenn man durch die Verzeichnisse browst, oder?

Also mal "top" angeworfen:

Code

top - 21:35:05 up 15 min,  1 user,  load average: 2.61, 2.33, 1.45
Tasks: 125 total,   1 running, 124 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.3%sy,  0.0%ni, 98.5%id,  0.3%wa,  0.0%hi,  0.7%si,  0.0%st
Mem:   1792892k total,   694540k used,  1098352k free,    37008k buffers
Swap:  1832956k total,        0k used,  1832956k free,   247412k cached


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1095 vdr       10 -10 1823m 219m  20m S    2 12.5   1:40.45 vdr
 1563 root      20   0     0    0    0 D    0  0.0   0:00.75 kdvb-ad-1-fe-0
    1 root      20   0 24716 2544 1268 S    0  0.1   0:01.92 init
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      20   0     0    0    0 S    0  0.0   0:00.02 ksoftirqd/0
    6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0
    7 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0
    8 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1
   10 root      20   0     0    0    0 S    0  0.0   0:00.00 ksoftirqd/1
   11 root      20   0     0    0    0 S    0  0.0   0:00.66 kworker/0:1
   12 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/1
   13 root       0 -20     0    0    0 S    0  0.0   0:00.00 cpuset
   14 root       0 -20     0    0    0 S    0  0.0   0:00.00 khelper
   15 root      20   0     0    0    0 S    0  0.0   0:00.00 kdevtmpfs
   16 root       0 -20     0    0    0 S    0  0.0   0:00.00 netns

Alles anzeigen

Sieht ja erstmal gut aus: Der VDR braucht kaum CPU und softhddevice ist nichtmals zu sehen.
Aber load average: 2.61, 2.33, 1.45?!

Wie kann das kommen? Wie kann der Load Average so hoch sein, wenn kein "Schuldiger" weiter unten zu sehen ist?

Gruß,
Hendrik

henfri · 16. Juli 2012

Bin ich der Einzige?

Keine_Ahnung · 16. Juli 2012

Wie läuft denn die Steuerung über "svdrpsend hitk <tastenname>"? Nicht das einfach nur deine Fernbedienung träge reagiert.

cu

nc17 · 16. Juli 2012

Wie schnell ist dein Netzwerk, bzw was ist wie angebunden ? Könnte ein Geschwindigkeitsproblem des Netzwerks bzw Servers sein.

henfri · 23. Juli 2012

Hallo,

sorry, ich komme erst jetzt wieder dazu.
Also über svdrpsend reagiert er auch träge.
Das Netzwerk ist WLAN, also eher langsam. Aber warum meinst du, dass das ein Problem sein kann? Ich habe ja keine Client-Server Lösung (Einige Aufnahmen liegen auf dem Server, aber er ist auch träge wenn ich einfach nur TV gucke.

Im Log ist mir jetzt aufgefallen:

Code

Jul 23 20:30:16 vdr-wohnzimmer vdr: [1222] XVDR: Recordings state changed (219)
Jul 23 20:30:16 vdr-wohnzimmer vdr: [1222] XVDR: Requesting clients to reload recordings list
Jul 23 20:30:16 vdr-wohnzimmer vdr: [2181] ERROR: skipped 62 bytes to sync on start of TS packet
Jul 23 20:30:17 vdr-wohnzimmer vdr: [2172] ERROR: 7132 ring buffer overflows (1340629 bytes dropped)
Jul 23 20:30:19 vdr-wohnzimmer vdr: [2171] ERROR: skipped 187 bytes to sync on start of TS packet
Jul 23 20:30:19 vdr-wohnzimmer vdr: [2172] ERROR: 8105 ring buffer overflows (1523491 bytes dropped)
Jul 23 20:30:19 vdr-wohnzimmer vdr: [2181] ERROR: skipped 126 bytes to sync on start of TS packet
Jul 23 20:30:20 vdr-wohnzimmer vdr: [1083] changing pids of channel 290 from 401+401=2:402=deu@3:0:0 to 501+501=2:502=deu@3:0:0
Jul 23 20:30:22 vdr-wohnzimmer vdr: [2181] ERROR: skipped 187 bytes to sync on start of TS packet

Wie kann ich denn testweise mal XVDR deaktivieren? Das ist recht aktiv im Log...

Gruß,
Hendrik

Keine_Ahnung · 23. Juli 2012

in der order.conf (/etc/vdr/plugins oder /lib/vdr/plugins) ein
---
-xvdr
---

Aber diese ring buffer overflows sind evtl. die Ursache, so was mag der VDR gar nicht. Dann wird er meist richtig wackelig.

Was sagt denn femon über den Empfang?

Wobei ich eher vermute das sie nur ne Folge eines übermäßig hohen Auslastung sind, entweder dein System ist generell ausgelastet oder nen Thread im VDR blockiert.

Also auch mal nen schneller Blick mit "top" ob da was auffälliges (VDR CPU Auslastung nahe 100%, oder ähnliches) ist.

cu

henfri · 24. Juli 2012

Hallo,

danke für die Antwort.
Top hatte ich oben ja schon gepostet. Load von > 2 ist ja nicht normal...
Das Gleiche jetzt auch wieder. Aber der VDR braucht kaum Resourcen. (ca 20%, naja, immerhin...)
Ich muss nochmal nachlesen, was Load bedeutet. Denn die CPU ist ja nicht voll ausgelastet. Und ich hab ja noch die zweite, die sich langweilt.
Empfang ist wunderbar. BER=0.
Gerade hat es ca. 7s gedauert, bis sich das Menü geöffnet hat.
Im Log kommen dabei viele Zeilen wie vdr-wohnzimmer vdr: [2174] buffer usage: 80% (tid=2207)
und jetzt auch
ERROR: 2956 ring buffer overflows (555541 bytes dropped)
ERROR: skipped 187 bytes to sync on start of TS packet

Gruß,
Hendrik

Keine_Ahnung · 24. Juli 2012

Seltsam, deaktiviere mal verdächtige Plugins. Erstmal das böse (wenn vorhanden) und dann radio oder femon. Die griffeln da unter Umständen auch rein.

cu

seahawk1986 · 24. Juli 2012

Zitat von henfri

Wie kann das kommen? Wie kann der Load Average so hoch sein, wenn kein "Schuldiger" weiter unten zu sehen ist?

Wie sieht die Audioausgabe bei dir aus? Hast du schon mal im WFE auf ein einziges Ausgabegerät umgestellt?

gda · 24. Juli 2012

Zitat von seahawk1986

Wie sieht die Audioausgabe bei dir aus? Hast du schon mal im WFE auf ein einziges Ausgabegerät umgestellt?

Ist schon fast eine logische Schlussfolgerung. Wenn kein Prozess die CPU-Last verursacht, dann muss es der Kernel sein, oder eben ein Kernel-Treiber.

Gerald

vdr_rossi · 26. Juli 2012

In meiner Konstellation (yavdr 0.5 alpha, headless als vm auf ESXi) habe ich nach länger uptime gleiches beobachtet.
Die Aufnahmen, verwaltet über VDRAdmin-AM 3.6.9 wurden teilweise erst nach sehr langer Wartezeit angezeigt.
Auflistung auf Dateiebene war ebenfalls nicht möglich. Habe Anfang der Woche mal komplett Updates durchlaufen lassen,
danach neu gestartet. Bis jetzt läuft alles flüssig (>4 Tagen uptime). Vorher war mit top, wie oben auch geschrieben
keine hohe CPU Last von irgendwas zu sehen... Audio steht auf analog, dürfte beim headless Betrieb nichts aus machen ?

Bei mir steht es weiter unter Beobachtung.

Die Clients haben per NFS den Pfad /srv/vdr/video.00 eingebunden, da war keine Verzögerung zu merken.

*Mein Fehlerteufel war hier versteckt.

Munter bleiben, Rossi

henfri · 30. Juli 2012

Hallo,
vielmals Sorry, dass ich mich erst jetzt melde. Ich hatte jetzt erst Zeit mich zu kümmern.

Zitat von gda

Ist schon fast eine logische Schlussfolgerung. Wenn kein Prozess die CPU-Last verursacht, dann muss es der Kernel sein, oder eben ein Kernel-Treiber.

Ich habe jetzt gerade auf ein Audio-Gerät umgestellt. Vorher waren "Alle Audio-Geräte".
Der Load Average ist nun auf 0.5 (Dualcore Athlon (4850e oder so). Weiterhin recht hoch, wie ich finde. Aber deutlich besser!

Ich habe zudem mal die Logs durchsucht, zum Thema Audio:

Code

Jul 30 03:55:23 vdr-wohnzimmer vdr: audio/alsa: broken driver 0 state 'RUNNING'

Kann das ein Hinweis sein?

Wie auch immer: Einen Workaround haben wir jetzt. Was können wir tun, um das Problem einzugrenzen, um es zu beheben?

Gruß,
Hendrik

henfri · 30. Juli 2012

Hm, gerade wieder Load=1.8.

Währenddessen im log:

Code

Jul 30 19:01:00 vdr-wohnzimmer vdr: [12393] timer 1 (46 2011-2211 'Tipp's~Jumper') set to event Son 05.08.2012 20:15-22:05 'Jumper'
Jul 30 19:01:00 vdr-wohnzimmer vdr: [12393] timer 1 (1213 2011-2211 'Tipp's~Jumper') set to event Son 05.08.2012 20:15-22:05 'Jumper'
Jul 30 19:01:09 vdr-wohnzimmer vdr: [12301] ...no deleted recording found, trying to delete an old recording...
Jul 30 19:01:09 vdr-wohnzimmer vdr: [12301] ...no old recording found, giving up
Jul 30 19:01:09 vdr-wohnzimmer vdr: [12301] info: 51 Timer-Konflikt(e)! Erster am 30.07 20:58. Anzeigen?
Jul 30 19:01:09 vdr-wohnzimmer vdr: [12790] Text2Skin: message display update thread started (pid=12301, tid=12790)
Jul 30 19:01:17 vdr-wohnzimmer vdr: [12790] Text2Skin: message display update thread ended (pid=12301, tid=12790)
Jul 30 19:01:17 vdr-wohnzimmer vdr: [12393] EPGSearch: timer conflict check finished
Jul 30 19:01:18 vdr-wohnzimmer vdr: [12301] warning: Platte beinahe voll!
Jul 30 19:01:18 vdr-wohnzimmer vdr: [12791] Text2Skin: message display update thread started (pid=12301, tid=12791)
Jul 30 19:01:21 vdr-wohnzimmer vdr: video: slow down video, duping frame
Jul 30 19:01:21 vdr-wohnzimmer vdr: video: 25:24:20.419  +31 1109 240/\ms  29 v-buf
Jul 30 19:01:24 vdr-wohnzimmer vdr: [12791] Text2Skin: message display update thread ended (pid=12301, tid=12791)
Jul 30 19:01:27 vdr-wohnzimmer vdr: [12365] frontend 0/0 timed out while tuning to channel 300, tp 211223
Jul 30 19:01:48 vdr-wohnzimmer vdr: [12365] frontend 0/0 timed out while tuning to channel 305, tp 211259
Jul 30 19:03:24 vdr-wohnzimmer vdr: [12641] low disk space (485 MB, limit is 512 MB)
Jul 30 19:03:24 vdr-wohnzimmer vdr: [12641] recording to '/srv/vdr/video.00/Star_Trek_÷_Das_nächste_Jahrhundert/2012-07-30.18.08.836-0.rec/00002.ts'
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12301] ...no deleted recording found, trying to delete an old recording...
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12301] ...no old recording found, giving up
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12301] warning: Platte beinahe voll!
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12798] Text2Skin: message display update thread started (pid=12301, tid=12798)
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12798] Text2Skin: message display update thread ended (pid=12301, tid=12798)
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12301] [softhddev]Clear:
Jul 30 19:03:27 vdr-wohnzimmer vdr: audio/alsa: using device 'default'
Jul 30 19:03:27 vdr-wohnzimmer vdr: audio/alsa: start delay 336ms
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12301] [softhddev]GrabImage: 0, 1, 80, 729x480
Jul 30 19:03:27 vdr-wohnzimmer vdr: video: slow down video, duping frame
Jul 30 19:03:27 vdr-wohnzimmer vdr: video: decoder buffer empty, duping frame (36297/86112) 0 v-buf
Jul 30 19:03:27 vdr-wohnzimmer vdr: video: --:--:--.---   +0    0 240/\ms   0 v-buf
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12301] [softhddev]Clear:
Jul 30 19:03:27 vdr-wohnzimmer vdr: audio/alsa: using device 'default'
Jul 30 19:03:27 vdr-wohnzimmer vdr: audio/alsa: start delay 336ms
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12799] Text2Skin: replayInfo display update thread started (pid=12301, tid=12799)
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12799] Text2Skin: replayInfo display update thread ended (pid=12301, tid=12799)
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12800] Text2Skin: replayInfo display update thread started (pid=12301, tid=12800)
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12800] Text2Skin: replayInfo display update thread ended (pid=12301, tid=12800)
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12301] [softhddev]Clear:
Jul 30 19:03:27 vdr-wohnzimmer vdr: audio/alsa: using device 'default'
Jul 30 19:03:27 vdr-wohnzimmer vdr: audio/alsa: start delay 336ms
Jul 30 19:03:27 vdr-wohnzimmer vdr: [12801] Text2Skin: menu display update thread started (pid=12301, tid=12801)
Jul 30 19:03:27 vdr-wohnzimmer vdr: video: decoder buffer empty, duping frame (36325/86112) 0 v-buf
Jul 30 19:03:27 vdr-wohnzimmer vdr: video: slow down video, duping frame
Jul 30 19:03:27 vdr-wohnzimmer vdr: video: 25:29:25.439 +216  954 240/\ms  14 v-buf
Jul 30 19:03:28 vdr-wohnzimmer vdr: video: slow down video, duping frame
Jul 30 19:03:28 vdr-wohnzimmer vdr: video/vdpau: missed frame (1065/86130)
Jul 30 19:03:28 vdr-wohnzimmer vdr: video: slow down video, duping frame
Jul 30 19:03:28 vdr-wohnzimmer vdr: video: 25:29:25.999 +226 1100 240/\ms  25 v-buf
Jul 30 19:03:28 vdr-wohnzimmer vdr: video: slow down video, duping frame
Jul 30 19:03:28 vdr-wohnzimmer vdr: video/vdpau: missed frame (1066/86134)
Jul 30 19:03:28 vdr-wohnzimmer vdr: video: slow down video, duping frame
Jul 30 19:03:28 vdr-wohnzimmer vdr: video: 25:29:26.079 +156 1118 240/\ms  27 v-buf
Jul 30 19:03:28 vdr-wohnzimmer vdr: [12301] [softhddev]GrabImage: 0, 1, 80, 729x480
Jul 30 19:03:28 vdr-wohnzimmer vdr: video: slow down video, duping frame
Jul 30 19:03:28 vdr-wohnzimmer vdr: video/vdpau: missed frame (1067/86138)

Alles anzeigen

Die Platte ist fast voll... Mag das der Grund (in diesem Fall) sein? Warum geht dadurch die Load hoch?

Gruß,
Hendrik

henfri · 31. Juli 2012

Hallo,

ich habe den Verdacht, dass die Platte zu langsam ist (DMA Modus?).
Hier habe ich einen Thread dazu aufgemacht:
DMA aktivieren

Gruß,
Hendrik

DocViper · 1. August 2012

Code

low disk space (485 MB, limit is 512 MB)

Würde sagen deine Platte ist knallvoll !
Eventuell bei der Partionierung was schief gegangen ?

Aktuelle Updates sind eingespielt ?
Text2Skin macht gelegentlich Probleme in letzter Zeit. Eventuel mal auf eines der VDR Default Skins umstellen und testen.

henfri · 2. August 2012

Hallo,

alle Updates sind drin.
Ich hatte gedacht, die Video Platte sei voll. Aber Tatsache, es ist /.

Da muss ich mal gucken...

Code

df -h
Dateisystem                     Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda6                         28G     26G  458M   99% /
udev                             867M    4,0K  867M    1% /dev
tmpfs                            351M    640K  350M    1% /run
none                             5,0M       0  5,0M    0% /run/lock
none                             876M       0  876M    0% /run/shm
HomeServer.local:/srv/video       57G     13G   41G   24% /media/Video/HomeServer
HomeServer.local:/srv/audio      5,5T    2,4T  3,2T   43% /media/Musik/HomeServer
HomeServer.local:/srv/picture    5,5T    2,4T  3,2T   43% /media/Bilder/HomeServer
HomeServer.local:/srv/share/vdr  5,5T    2,4T  3,2T   43% /srv/vdr/video.00/HomeServer


mount
/dev/sda6 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/srv/vdr/video.00 on /srv/share/vdr type none (rw,bind)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
HomeServer.local:/srv/video on /media/Video/HomeServer type nfs (rw,soft,intr,addr=192.168.178.3)
HomeServer.local:/srv/audio on /media/Musik/HomeServer type nfs (rw,soft,intr,addr=192.168.178.3)
HomeServer.local:/srv/picture on /media/Bilder/HomeServer type nfs (rw,soft,intr,addr=192.168.178.3)
HomeServer.local:/srv/share/vdr on /srv/vdr/video.00/HomeServer type nfs (rw,soft,intr,addr=192.168.178.3)
root@vdr-wohnzimmer:~#
root@vdr-wohnzimmer:~# fdisk -l


Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 Köpfe, 63 Sektoren/Spur, 7296 Zylinder, zusammen 117210240 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x0001f490


   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *        2048    55275485    27636719   83  Linux
/dev/sda2        55275518   117209087    30966785    5  Erweiterte
/dev/sda5       113543168   117209087     1832960   82  Linux Swap / Solaris
/dev/sda6        55275520   113543167    29133824   83  Linux


Partitionstabelleneinträge sind nicht in Platten-Reihenfolge

Alles anzeigen

Updates sind alle drin.

VDR-Default Skin: Wird morgen probiert.

Ich habe derweil mal auf xine umgestellt und das Frontend dann beendet
--> Wollt gerade schreiben, dass der Load dann auf 0.6 runter ging. Jetzt ist er aber wieder auf 1.6

Ok. Jetzt hab ich 's aber. Den VDR beendet und die Last geht runter auf 0.06!

Ich denke, der nächste Schritt ist die Platte (Speicherplatz), oder?

Gruß,
Hendrik

DocViper · 2. August 2012

ja, vermutlich war dein "homeserver" mal nicht verbunden und du hast aufnahmen in deinem lokalen videoverzeichnis - oder sonstwo liegen.

den homeserver mal unmounten und dort nachsehen

joe

henfri · 2. August 2012

Ja, das ist der Grund.. für die volle Platte jedenfalls.
Aber darf dadurch Load hoch gehen?

Warum stört der VDR sich daran?

Heute Abend wissen wir, ob es wirklich daran lag...

Gruß,
Hendrik

seahawk1986 · 2. August 2012

Zitat von henfri

Warum stört der VDR sich daran?

Vielleicht weil er nicht mehr wie geplant auf die Platte schreiben kann (EPG-Daten, Timer, Einstellungen usw.).

henfri · 2. August 2012

Moment, die Platte ist nicht voll (und war es auch nie)

Könnt ihr ein Tool empfehlen, das CPU-Load, Netzwerklast, IO auf der Platte und Co monitort und als Graphen aufbereitet? Am liebsten web-basiert. Dann könnte man mal versuchen Korelationen zu sehen.

Gruß,
Hendrik

[0.5 alpha] ... Ist träge

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema