SOLVED: VDR lahmt - Festplatten Geschwindigkeit?

Gurky · 28. August 2006

Hallo,

ich habe hier in meinem VDR eine Samsung Festplatte (IDE) unter UDMA5 an einem VIA EPIA ME6000 Board laufen:

>hdparm -i /dev/hda
...
Model=SAMSUNG SP1614N
...

Die Platte ist sicherlich nicht optimal eingestellt, aber ganz quer liege ich auch nicht:

>hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 312581808, start = 0

Seit ein paar Tagen (nach mehreren Monaten ohne Veränderung) zickt der Rechner (friert ein, Aufnahmen brechen ab etc.). Meinem Eindruck nach ist es die Festplatte. hdparm bringt folgende Werte:

>hdparm -Tt /dev/hda

/dev/hda:
Timing cached reads: 204 MB in 2.01 seconds = 101.37 MB/sec
Timing buffered disk reads: 92 MB in 3.03 seconds = 30.32 MB/sec

Sind die Werte okay?

Was spucken Eure VDRs so aus, wenn Ihr

hdparm -Tt

macht?

Gruß
Gurky

Wicky · 28. August 2006

Hallo Gurky,
hier ein paar Infos von meiner Platte (Chipsatz VIA KT266A)

Model=SAMSUNG SP1614N,

/dev/hda:
Timing cached reads: 1156 MB in 2.00 seconds = 577.96 MB/sec
Timing buffered disk reads: 154 MB in 3.00 seconds = 51.26 MB/sec

/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 312581808, start = 0

UDMA-Modus=4, mehr brauch ich nicht.

Gruß
Wicky

Wicky · 28. August 2006

...und dann noch (P3, Chipsat i810)

Model=SAMSUNG SP2514N,

/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30401/255/63, sectors = 488397168, start = 0

/dev/hda:
Timing cached reads: 432 MB in 2.01 seconds = 214.80 MB/sec
Timing buffered disk reads: 94 MB in 3.02 seconds = 31.14 MB/sec

UDMA-Modus=3 !!! Mehr kann das Board nicht !!

Gruß
Wicky

PS: Ich glaube nicht, das deine Festplatte das Problem ist. Die cached reads sind schon viel zu niedrig. Mein alter P3 schafft ja doppelt so viel !!!

tr500 · 28. August 2006

Hallo Gurky

Hier mal auch Infos
Laptop

Zitat

Timing cached reads: 668 MB in 2.00 seconds = 333.96 MB/sec
Timing buffered disk reads: 52 MB in 3.05 seconds = 17.04 MB/sec

VDR

Zitat

Timing cached reads: 228 MB in 2.00 seconds = 113.99 MB/sec
Timing buffered disk reads: 64 MB in 3.01 seconds = 21.28 MB/sec

Wie du Siehst sind die Werte genauso "schlecht" wie Deine also können wir die HD ausschliessen. Denn mein VDR läuft ohne Prob.
Gibt das Log was her?

Gruß Tom

Gurky · 28. August 2006

Hallo,

vielen Dank an die schnellen Antworter!!!

Zitat

Original von tr500

VDR

Wie du Siehst sind die Werte genauso "schlecht" wie Deine also können wir die HD ausschliessen. Denn mein VDR läuft ohne Prob.

Meine Festplatte findet sich schon irgendwo ganz unten im Leistungsspektrum wieder - ich denke auch, sie sollte mehr bringen.

Das syslog sagt beim 'Hängen'

...
Aug 27 12:10:30 vdr vdr: [5057] ERROR: 33624 ring buffer overflows (6321312 byte
s dropped)
...

CPU ist auf 10% und auch sonst sieht alles ganz anständig aus.

Gruß
Gurky

tr500 · 28. August 2006

Kannst du mal etwas mehr log posten.
Was macht vdr kurz vorm aufhängen?
Kann man den Fehler reproduzieren?

Gruß Tom

Gurky · 28. August 2006

Zitat

Original von tr500
Kannst du mal etwas mehr log posten.
Was macht vdr kurz vorm aufhängen?
Kann man den Fehler reproduzieren?

Hallo,

der Fehler ist reproduzierbar; über den VDR Fernsehen funktioniert; eine Aufnahme manchmal; spätestens bei zwei Aktionen (Programm aufzeichnen + Aufnahmen schauen oder zwei Aufnahmen - was früher problemlos ging) kommt es zu Hängern in Ton und Bild und Aussetzern. Aber auch schon bei nur einer Aktion läßt sich der VDR nur träge bedienen.

Femon liefert Signale > 68%.

Die Auslastung scheint auch noch okay zu sein. Was mich nur wundert sind die vielen vdr-Prozesse. Insgesamt meldet ps -ea | grep vdr 16x einen vdr-Prozess.

'top' liefert folgendes Ergebnis
top - 23:12:12 up 4 min, 1 user, load average: 1.57, 1.44, 0.65
Tasks: 69 total, 2 running, 67 sleeping, 0 stopped, 0 zombie
Cpu(s): 27.2% us, 15.2% sy, 0.7% ni, 47.0% id, 0.0% wa, 1.7% hi, 8.3% si
Mem: 224240k total, 194136k used, 30104k free, 7192k buffers
Swap: 506008k total, 0k used, 506008k free, 62752k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4400 vdr 16 0 101m 52m 5092 S 11.2 24.0 0:10.31 vdr
4409 vdr 15 0 101m 52m 5092 S 4.9 24.0 0:04.47 vdr
4428 vdr 15 0 101m 52m 5092 S 4.6 24.0 0:04.38 vdr
4408 vdr 15 0 101m 52m 5092 S 3.6 24.0 0:02.68 vdr
4419 vdr 15 0 101m 52m 5092 S 3.3 24.0 0:03.33 vdr
4427 vdr 15 0 101m 52m 5092 S 3.3 24.0 0:02.99 vdr

Ich glaube der interessante Teil aus den Logs ist folgender. Davor ist alles im grünen Bereich. Danach kommt eigentlich keine andere Meldung mehr. Die erste Log-Meldung kommt immer mal wieder spontan bei einer Aufnahme; die zweite kann ich durch Festplattenbelastung provozieren.

Aug 27 12:09:41 vdr vdr: [5057] buffer usage: 70% (tid=5066)
Aug 27 12:09:41 vdr vdr: [5057] buffer usage: 80% (tid=5066)
Aug 27 12:09:42 vdr vdr: [5057] buffer usage: 90% (tid=5066)
Aug 27 12:09:42 vdr vdr: [5057] buffer usage: 100% (tid=5066)
Aug 27 12:09:42 vdr vdr: [5057] ERROR: 1 ring buffer overflow (65 bytes dropped)
Aug 27 12:09:48 vdr vdr: [5057] ERROR: 28999 ring buffer overflows (5451812 byte
s dropped)

Aug 28 22:53:48 vdr vdr: [11841] PES packet shortened to 7142 bytes (expected: 7694 bytes)
Aug 28 22:53:48 vdr vdr: [11831] PES packet shortened to 4850 bytes (expected: 5390 bytes)
Aug 28 22:53:48 vdr vdr: [11841] PES packet shortened to 4850 bytes (expected: 5390 bytes)
Aug 28 22:53:48 vdr vdr: [11821] buffer usage: 90% (tid=11820)
Aug 28 22:53:48 vdr vdr: [11876] PES packet shortened to 4850 bytes (expected: 5390 bytes)
Aug 28 22:53:48 vdr vdr: [11841] PES packet shortened to 7142 bytes (expected: 7694 bytes)
Aug 28 22:53:48 vdr vdr: [11841] PES packet shortened to 1958 bytes (expected: 2318 bytes)

Vielen Dank für die Mühe,
Gruß
Gurky

Urig · 29. August 2006

Die Konfiguration kommt mir durchaus bekannt vor:

Samsung SV1203N auf ME6000:

Code

Timing cached reads:   240 MB in  2.03 seconds = 118.12 MB/sec
 Timing buffered disk reads:   94 MB in  3.00 seconds =  31.31 MB/sec

Ich hatte mal ähnliche Probleme mit meinem System, dabei ist die CPU-Last beim Plattenzugriff manchmal sehr hoch gewesen, und gleichzeitig brach die Datenrate deutlich ein. Bei mehreren konkurrierenden Aufnahmen oder gleichzeitigem Schneiden war dann das Limit erreicht. Als Ursache konnte ich schließlich das Dateisystem ausmachen: Da lange Zeit ständig aufgenommen und gelöscht wurde, bei gleichzeitig ständig hohem Füllstand der Platte, war die Fragmentierung des Dateisystems explodiert: Der regelmäßig genutzte Teil der Platte bestand überwiegend aus winzigen Fragmenten. Nachdem ich alle Daten ausgelagert und das Dateisystem erneuert hatte, war die Performance (zb. beim Schneiden) erstaunlich viel besser.

Zur Langzeit-Überwachung der Systemaktivität war mir "vmstat 1" eine gute Hilfe, da man sowohl I/O (Festplatten-) Aktivität als auch CPU-Last beobachten und protokollieren kann.

Als Ursache kommen natürlich auch andere Plattenprobleme in Frage, vielleicht hängt er an schwach gewordenen Sektoren. Ein großer Selbsttest mit smartmontools schadet sicher nicht.

Schließlich wären auch Probleme mit zu hohen Sat-Datenraten möglich, das wäre dann aber deutlich senderabhängig. (ARD/ZDF) Typisch dafür ist auch ein träges OSD.

Gruß,

Udo

Wicky · 29. August 2006

Hallo zusammen,

....mir kommt da gerade in den Kopf, das es sich auch um Probleme mit einem PCI-Bus handeln könnte, der es aus unbekannten Gründen nicht mag, wenn man ihn stresst.

Stress entsteht hier durch
a) DVB-Karte
b) IDE-Kontroller

Urigs Vermutung hört sich ebenfalls schlüssig an. Um abzugrenen, ob es sich um PCI-BUS-STRESS handelt oder HD-Fragmentierung, könntest du einmal nur die HD anderweitig stressen (nicht übers Netztwerk, denn dann belastest du auch den PCI-Bus)
und dann noch mit aktiviertem DVB-Device. Aber das Ergebnis des Tests kennst du ja leider schon.

HD-Stress-Test:
Meine Idee: Kopiere mehre Verzeichnisse in parallelen Prozessen von A noch B.

Gruß
Wicky

P.S. Aber das IDE-Kabel hast du schon einmal ausgetauscht. Wäre eventuell ärgerlich wenn nicht !!

tr500 · 29. August 2006

Hallo Gurky
kannst du mal das komplette Log als Anhang posten. Hätts gern mal gesehen.

Hast du in vergangener Zeit irgendwas geändert, egal was ??
(Auch wenn es unwichtig erscheint,hatte ich mit diesem Umstand auch die meisten Probleme)

Gruß Tom

Gurky · 29. August 2006

Hallo tr500, hallo Urig, hallo alle,

ich habe mal die Syslogs mit den beiden Fehlern angehängt.

Nebenbei kopiere ich gerade meine Videodaten weg um die Partition mal neu aufzusetzen.

Nach dem 'Last Known Good Point' hatte ich noch ein apt-get update. Dabei kam u.a. vdr_1.4.1-1ctvdr4_i386.deb rein. Vielleicht war die Version doch zu experimental?

Ich habe mal die Aufzeichnungen aus den letzten Tagen überprüft und es scheint so zu sein, dass keine Aufzeichnung über das erste Teilstück 001.vdr hinauskommt und exakt bei 2GB abbricht!

Ich will das mal überprüfen.

Vielen Dank soweit,
ciao Gurky

AmTraX · 29. August 2006

Ich hatte auch schonmal ähnliche probleme, die darauf zurückzuführen waren, dass die festplatte nicht im dma modus lief, worauf auch die extrem niedrigen transferraten zurückzuführen wären.

Gurky · 29. August 2006

Zitat

Original von AmTraX
Ich hatte auch schonmal ähnliche probleme, die darauf zurückzuführen waren, dass die festplatte nicht im dma modus lief, worauf auch die extrem niedrigen transferraten zurückzuführen wären.

Leider nein .. siehe oben - danke

hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 312581808, start = 0

Wicky · 29. August 2006

Gurky

...in meinen Augen läßt sich im Log kein Hinweis in Richtung HD finden.

Ich vermute eher, dass eine lib vom VDR verwendet wird, die er lieber nicht verwenden sollte, oder dass du irgendwelche Problem mit deiner DVB-Karte hast, oder dass der VDR die PIDs auf Werte ändert, die bei deinem VDR keinen Sinn machen.

Gruß
Wicky

Gurky · 29. August 2006

Hallo Wicky,

danke für die Mühe!

Ich wollte jetzt nochmal eine Aufzeichnung > 2GB testen und Urigs Tipp umsetzen. Und dann gebe ich nochmal Rückmeldung.

Vielleicht kam der Wurm wirklich mit der neuen vdr Version rein.

Ciao,
Gurky

Urig · 30. August 2006

So weit ich das Logfile verstehe, hast du eine FF-Karte im System.

Auszug aus Log 1:

Aug 28 22:44:09 vdr vdr: [3785] timer 4 (2 2244-0144 '@TITLE EPISODE') start
Aug 28 22:44:09 vdr vdr: [10316] TS buffer on device 1 thread started (pid=10316, tid=10316)
Aug 28 22:44:30 vdr vdr: [3785] switching device 1 to channel 16
Aug 28 22:44:31 vdr vdr: [3785] timer 5 (16 2244-0144 '@TITLE EPISODE') start
Aug 28 22:44:54 vdr vdr: [3785] switching device 1 to channel 22
Aug 28 22:44:55 vdr vdr: [3785] timer 6 (22 2244-0144 '@TITLE EPISODE') start
Aug 28 22:44:55 vdr vdr: [3785] Title: 'ZDF.reporter' Subtitle: ''

Zu diesem Zeitpunkt nimmt die eine Karte also 3 Sendungen auf und versorgt zusätzlich den Ausgang mit Live-Signal mittels Transfer-Mode. Zusammen mit der hohen Datenrate von ZDF könnten dadurch schon die dann folgenden Überlastungserscheinungen erklärt sein. Meine FF-Karte hat auch schon gelegentliche Aussetzer, wenn ARD über die FF-Karte aufgenommen wird, und gleichzeitig per Transfer-Mode live angezeigt wird.

Auszug aus Log 2:

Aug 29 15:08:11 vdr vdr: [3855] connect from 127.0.0.1, port 2338 - accepted
Aug 29 15:09:12 vdr vdr: [3855] PANIC: watchdog timer expired - exiting!
Aug 29 15:09:12 vdr vdr: [3855] delete RadioAudio

Klassischer Tod durch SVDRP. Irgend jemand (VDRAdmin?) verbindet sich per SVDRP und hält/benutzt die Verbindung über eine Minute lang. Danach versucht VDR einen Neustart - bzw. sollte es jedenfalls. Im Log taucht aber nichts davon auf.? Statt dessen beginnen die Pufferüberläufe 2 Minuten später.

Gruß,

Udo

Gurky · 30. August 2006

Hallo Urig,

wann schläfst Du eigentlich?

Im ersten Fall habe ich den Aussetzer durch drei parallele Aufnahmen provoziert - stimmt. Hat aber bislang immer funktioniert - obwohl ich natürlich nicht die gesamte Transferrate angeschaut habe.

Der watchdog panic versuche ich heute noch mal nachzugehen. Ich habe heute morgen mal einen Testaufzeichnung gemacht. Die lief durch, brach aber auch in der Mitte mit PANIC watchdog ... ab und verursachte so einen vdr Neustart - diesmal aber ohne buffer overflow

Ich will mal nach und nach plugins und add-ons auf Eis legen und schauen was Ärger machen könnte.

Danke
ciao
Gurky

Gurky · 31. August 2006

Hallo,

ich habe mal die video Partition neu aufgesetzt - aber leider ohne Erfolg, Plugins nach und nach entfernt - auch nichts und auf die Version 1.4.2-1ctvdr2 geupgraded - auch ohne Erfolg.

Jetzt werde ich versuchen das System nachmal mit der 1.4.0 Version aufzusetzten und dann werde ich bei der Hardware weitersuchen.

Ciao
Gurky

SHF · 31. August 2006

Ich würde zum Test erstmal VDRAdmin deaktivieren.
Die EPG-Übertragung via SVDRP hat meinen Rechner immer zuverlässig abgeschossen. Nach dem ich VDRAdmin-AM so umgestellt habe, dass es die EPG-Daten direkt aus der Datei einliest, klappt es.

P.S. Meine Platte ist nicht schneller als deine (BX-Board -> UDMA2).

Gurky · 31. August 2006

Zitat
Original von Urig
Die Konfiguration kommt mir durchaus bekannt vor:

Samsung SV1203N auf ME6000:
Code
Timing cached reads:   240 MB in  2.03 seconds = 118.12 MB/sec
 Timing buffered disk reads:   94 MB in  3.00 seconds =  31.31 MB/sec
...

Da lange Zeit ständig aufgenommen und gelöscht wurde, bei gleichzeitig ständig hohem Füllstand der Platte, war die Fragmentierung des Dateisystems explodiert: Der regelmäßig genutzte Teil der Platte bestand überwiegend aus winzigen Fragmenten. Nachdem ich alle Daten ausgelagert und das Dateisystem erneuert hatte, war die Performance (zb. beim Schneiden) erstaunlich viel besser.
Alles anzeigen

Hallo Udo,

hab ich mal ausprobiert - hat's aber leider nicht gebracht aber einmal umkopieren ist bestimmt auch nicht schlecht was die Performance angeht!

Gruß
Gurky

SOLVED: VDR lahmt - Festplatten Geschwindigkeit?

Jetzt mitmachen!

Teilen