jbd2 immer wieder auf 99.99%

  • habe auf dem ubuntu server mdadm mit ext4 und 4 platten.
    jetzt hab ich das problem dass aufnahmen die in HD ausgestrahlt werden immer wieder ruckler und aussetzer drin haben, die noch dazu den vdr unbedienbar machen.


    Code
    Apr 28 21:54:06 ubuntu vdr: [1723] buffer usage: 70% (tid=1752)
    Apr 28 21:54:06 ubuntu vdr: [1723] buffer usage: 80% (tid=1752)
    Apr 28 21:54:07 ubuntu vdr: [1723] buffer usage: 90% (tid=1752)
    Apr 28 21:54:07 ubuntu vdr: [1723] buffer usage: 100% (tid=1752)
    Apr 28 21:54:07 ubuntu vdr: [1723] ERROR: 1 ring buffer overflow (1 bytes dropped)
    Apr 28 21:54:11 ubuntu vdr: [1703] ERROR: 18683 ring buffer overflows (3512404 bytes dropped)
    Apr 28 21:54:13 ubuntu vdr: [1723] ERROR: 23794 ring buffer overflows (4473272 bytes dropped)
    Apr 28 21:54:17 ubuntu vdr: [1703] ERROR: 16862 ring buffer overflows (3170056 bytes dropped)


    damit ist jede aufnahme zerstoert, was sehr aergerlich ist. ich habe schon empfangstoerungen dafuer verantwortlich gemacht. nachdem aber aufnahmen von einem anderen vdr zu genau den selben ausfaellen an der selben stelle in der aufnahme fuehrten und der empfang immer 1a war habe ich mal den server unter die lupe genommen.


    und hier zeigt sich mit IOSTAT das jbd2 und nfsd auf 99.99% gehen wenn der ruckler auftritt. am einfachsten mit einer pausierten sendung zu ueberpruefen. wenn das bild stehen bleibt sehe ich kurz darauf dass jbd2 und dann auch nfsd die komplette io braucht.


    smart zeigt auch keine probleme, und es gibt auch keine verdaechtigen meldungen im syslog und messages.
    das einzige was vielleicht nicht 100% optimal ist, ist dass es 3 samsung platten sind und eine western digital. allesamt sind natuerlich keine serverplatten. aber von der performance ist ja jede einzelne in der lage mind 5 hd streams aufzuzeichnen.


    wer hat eine idee wie ich das in den griff bekomme? das system ist am aktuellen stand. ubuntu 11.10
    cpu ist auch kein thema ist ein dual core intel mit 2.4ghz, der >95% auf 1.6ghz laeuft (laut cpuinfo)


    soll ich von ext4 auf xfs gehen? oder journaling deaktivieren?


    bin euch fuer jede hilfe echt dankbar - wenn ich nicht bald draufkomme schmeiss ich den ganzen mist raus *ggg*

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300

  • Bevor du der Kiste das fliegen beibringst, wäre testweises Abschalten des Journals m.E. einen Versuch wert.
    Danach könnte man mal nach den Parametern sehen, mit denen das ext4 läuft, vielleicht kann man da was optimieren (bin ich aber nicht allzu firm drin). Ähnliches gilt für nfs (kenn ich ich mich aber noch weniger aus).
    Dann wär da noch mdadm: bei vier Platten gehe ich mal von RAID5 aus (?) Vielleicht ungünstige stripe-size?


    Wenn nötig, könnte ich das bei mir mal gegentesten, hab auch vier Samsungs mit ext4 im md-Raid unter Ubuntu (bis jetzt allerdings mit Samba statt nfs, aber das sollte ja eher noch schlimmere Ergebnisse verursachen) - normalerweise nehm ich auf lokale Platte auf und nutze das Raid nur als Archiv.


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • es ist ein raid5. hab ich vergessen dazuzuschreiben. optimiert hab ich garnix, ueberall die standardparameter verwendet, also sowohl bei mdadm als auch bei nfs als auch ext4. dachte dass ich daimt erstmal am sichersten fahre.
    habe dann auch das raid mal mit noatime gemountet, das brachte aber auch keine besserung.


    die plattenperformance duerfte soweit auch passen. mit hdparm gemessen ergeben sich 85-110mb/s je nach platte.


    ich werde jetzt mal alles auf externe platte umsichern und dann das journaling abdrehen und dann mal mit xfs formatieren und sehen ob das was bringt.


    edit: hab vergessen wie langsam usb2 ist. der ist da jetzt die naechsten 15h beschaeftigt :(

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300

    Einmal editiert, zuletzt von izeman ()

  • ueberall die standardparameter verwendet, also sowohl bei mdadm als auch bei nfs als auch ext4. dachte dass ich daimt erstmal am sichersten fahre.


    Das ist gut, damit haben wir eine "saubere" Ausgangsposition und müssen nicht nach kaputtoptimierten Einstellungen suchen (ich dachte da z.B. an die Möglichkeit, nicht nur die Metadaten, sondern auch die Nutzdaten komplett durch's Journal zu schleusen...)


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • Mist, da hab ich gr0ß getönt, dass ich ne ähnliche Konstellation hab - und jetzt muß ich feststellen, dass ich doch nur ext3 hab, kann mich gar nicht erinnern, dass ich das fs mal neu gemacht hab (war definitiv mal ext4) - man sollte Bastelsysteme sich nicht in den "Produktivbetrieb" einschleichen lassen...
    Trotzdem beschreib ich mal, wie ich (mit Mühe und womöglich eher zufällig) deine Symptome nachvollziehen konnte (irgendwie muss ich ja deine 15-Stunden-Zwangspause überbrücken)


    Keinerlei Fehlermeldungen, keine Pufferüberläufe (obwohl markad ja auch noch dazwischenfunkt).
    Zweite Aufnahme überlappend/parallel dazu:

    Code
    Apr 29 19:19:58 yavdr1 vdr: [1451] channel 101 (Das Erste HD) event Son 29.04.2012 19:20-20:00 (VPS: 29.04 19:20) 'Weltspiegel' status 2
    Apr 29 19:19:59 yavdr1 vdr: [1116] switching device 1 to channel 101
    Apr 29 19:19:59 yavdr1 vdr: [1116] timer 46 (101 1920-2000 VPS 'Video-Archiv~Temp~Weltspiegel~Auslandskorrespondenten berichten - Moderation: Ute Brucker') start
    <...>
    Apr 29 19:19:59 yavdr1 vdr: [1116] recording to '/srv/vdr/video.00/Video-Archiv/Temp/Weltspiegel/Auslandskorrespondenten_berichten_-_Moderation:_Ute_Brucker/2012-04-29.19.20.101-0.rec/00001.ts'
    Apr 29 19:19:59 yavdr1 vdr: [8207] recording thread started (pid=1116, tid=8207)
    Apr 29 19:19:59 yavdr1 vdr: [1116] markad: no logo found for Video-Archiv~Temp~Weltspiegel~Auslandskorrespondenten berichten - Moderation: Ute Brucker


    Einige Minuten lang keine besonderen Vorkommnisse, dann funkt versehentlich ein Autotimer dazwischen (allerdings nicht in HD und nur auf lokale Platte), und siehe da:


    Das Merkwürdige daran: dieser timer nimmt zu der Zeit noch gar nicht auf, sondern schaltet nur schonmal auf den passenden Kanal - könne also zufällige Koinzidenz sein (vielleicht hab ich da auch grad per FB irgendwas am vdr gemacht).
    Danach fängt sich das Ganze wieder, allerdings nähert sich die erste Testaufnahme da auch schon dem Ende.

    Code
    Apr 29 19:28:35 yavdr1 vdr: [1116] timer 47 (102 1910-1928 VPS 'Video-Archiv~Temp~Berlin direkt') stop
    <...>
    Apr 29 19:29:33 yavdr1 vdr: [1116] replay /srv/vdr/video.00/Video-Archiv/Temp/Weltspiegel/Auslandskorrespondenten_berichten_-_Moderation:_Ute_Brucker/2012-04-29.19.20.101-0.rec
    <...>
    Apr 29 19:29:33 yavdr1 vdr: [8240] dvbplayer thread started (pid=1116, tid=8240)


    Bei der Wiedergabe gibt's genau einmal einen kurzen Aussetzer, entsprechend den o.g. Bufferproblemen (im Log die oben schon auftauchenden "skipped 187 Bytes to sync..." gefolgt von einigen "TS continuity errors").
    Auf dem Server keinerlei Auffälligkeiten (top lief mit, aber ich hab nicht permanent drauf geschaut), Hauptverbraucher war samba (etwa 5-25% CPU), gefolgt von kblockd und md_d127_raid5 (meist 1-2%). IO hab ich leider nicht verfolgt.
    Fazit: ich kann die Symptome zwar auch provozieren, aber bei mir deutet alles daraufhin, dass sie vom Client (vdr) verursacht werden - ist halt nur ein Atömchen, das schon bei OSD-Aktivitäten ins ruckeln kommt. BTW: Server ist auch nur ein Atom, Netz nur 100Mb, also um Hardwäre-Schwächeleien brauchen wir uns bei dir keine Gedanken zu machen. Und dass nfs mehr Probleme macht als smb, würd mich überraschen. Bleibt die Frage nach ext4 (hab grad nicht den Mut, das mal eben zu konvertieren).


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

  • danke dass du dir so viel muehe machst um zu helfen.
    leider haben diese buffer probleme wirklich viel unterschiedliche ursachen. das kann am client liegen der aus dem tritt kommt, das kann an der dvb karte liegen (zb meine tt6400) oder eben auch wie ich jetzt 100% sicher geklaert habe am server.


    also: wie gesagt auf der lokalen platte hatte ich null probleme. da aber mehrere vdr clients auf die selben daten zugreifen geht nur das nas als video0.


    ich habe also alles mal gesichert auf eine usb2 platte. dann nfs mount auf diese platte umgestellt und siehe da: alles geht wunderbar. aber das ist eben nur eine platte und zu klein, und auch ein wenig unsicher. da ist mir raid5 lieber.


    also hab ich das raid neu formatiert. mit xfs. da problem ist ein wenig spaeter aufgetreten aber es war immer noch da.
    dann hab ich das komplette raid mal neu aufgesetzt und wieder mit ext4 formatiert. hat nichts gebracht.


    dann kam mir die idee mit zfs. ruck zuck aufgesetzt und fertig. problem geloest. aktuell spiele ich mit 25-30mb/s das backup von der usb platte retour, nehme 4 hd programme parallel auf und schaue eines davon. kein problem.


    und demnach lasse ich das jetzt auch so :)

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300

  • und demnach lasse ich das jetzt auch so :)

    Warmduscher ;)


    Wer alkoholfreies Bier trinkt, wählt auch kompetenzfreie Politiker [frei nach Volker Pispers]

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!