Anzahl der nfs-Daemons auf SuSE-Server

rijo · 4. Februar 2006

Hallo,

das Videoverzeichnis meines VDR habe ich über nfs an einen SuSE Server angebunden. Da ich mit dem Datendurchsatz zur Zeit nicht zufrieden bin, war ich auch schon auf der Suche :]. Bei diesem Beitrag über Datenaustausch via NFS (pdf) wird auf der letzten Seite erklärt wie groß die Anzahl der nfs-Daemons sein sollte (bei SuSE sind wohl 4 Standardeinstellung). D. h. zumindest einer sollte so gut wie nie gebraucht werden.
Nun ratet mal wies bei meinem Server aussieht.

Code

~ # ps auxww | grep nfsd
root     19870  0.1  0.0     0    0 ?        SW   Jan04  79:09 [nfsd]
root     19871  0.1  0.0     0    0 ?        SW   Jan04  78:52 [nfsd]
root     19872  0.1  0.0     0    0 ?        SW   Jan04  78:05 [nfsd]
root     19873  0.1  0.0     0    0 ?        SW   Jan04  74:20 [nfsd]
root     12837  0.0  0.0  1456  244 pts/0    R    08:41   0:00 grep nfsd
~ #

Da ist die Auslastung ziemlich gleich hoch. Die sind wohl zu wenige.
So, jetzt weiß ich nicht mehr weiter. Ich finde nicht raus wo man die Anzahl der nfs-Deamons bei SuSE ändern kann. (Habe die nfs-utils laufen). Hat wer nen Tipp?

Viele Grüße,
rijo

KdF · 4. Februar 2006

Hi rijo,

schau mal in /etc/conf.d/nfs

Das ist unter Gentoo das entsprechende config-file.
Unter SuSE wird es ein ähnliches file geben.

Viele Grüße
Rolf

rijo · 4. Februar 2006

Habe leider kein Verzeichni /etc/conf.d/nfs.
Aber ich habe ne /etc/sysconfig/nfs und da steht ein USE_KERNEL_NFSD_NUMBER="4" drin. Das könnte es sein.

rijo

andreash · 4. Februar 2006

Zitat
Original von rijo
Hallo,

das Videoverzeichnis meines VDR habe ich über nfs an einen SuSE Server angebunden. Da ich mit dem Datendurchsatz zur Zeit nicht zufrieden bin, war ich auch schon auf der Suche :]. Bei diesem Beitrag über Datenaustausch via NFS (pdf) wird auf der letzten Seite erklärt wie groß die Anzahl der nfs-Daemons sein sollte (bei SuSE sind wohl 4 Standardeinstellung). D. h. zumindest einer sollte so gut wie nie gebraucht werden.
Nun ratet mal wies bei meinem Server aussieht.
Code
~ # ps auxww | grep nfsd
root     19870  0.1  0.0     0    0 ?        SW   Jan04  79:09 [nfsd]
root     19871  0.1  0.0     0    0 ?        SW   Jan04  78:52 [nfsd]
root     19872  0.1  0.0     0    0 ?        SW   Jan04  78:05 [nfsd]
root     19873  0.1  0.0     0    0 ?        SW   Jan04  74:20 [nfsd]
root     12837  0.0  0.0  1456  244 pts/0    R    08:41   0:00 grep nfsd
~ #
Da ist die Auslastung ziemlich gleich hoch. Die sind wohl zu wenige.

Hi Rijo,

was verstehst du unter "mit dem Datendurchsatz zur Zeit nicht zufrieden'?`
Bei einem Server und einem Client sollten 4 nfsds schon ausreichend sein. Bei mir laufen (historisch) acht, und auch die sind alle gleichmaessig ausgelastet. Ich denke eher, dass das System fuer eine gleichmaesige Auslastung sorgt.

Wie hast du denn die mangelhafte Performance gemessen? Welche mount-Optionen hast du verwendet?

Andreas

rijo · 4. Februar 2006

Hallo Andreas,

wg. "mit dem Datendurchsatz zur Zeit nicht zufrieden" - Nun ja, es war schon besser. Im normalen Betrieb wirkt sich das so aus, daß ich keinen Beitrag ohne Störungen ansehen kann, wenn gleichzeitig eine Aufnahme läuft. Früher gingen das. Da konnte ich sogar 2 Aufzeichnungen gleichzeitig laufen haben und hatte dann (wenn überhaupt) kaum Störungen. (ich glaube ich hatte damals noch nen ct-vdr laufen, aber das weiß ich nicht mehr so genau).

Das mit der Auslastung der nfs-Deamons habe ich aus dem genannten pdf.

Die Performance habe ich so gemessen:

Code

linvdr:~# time dd if=/dev/zero of=/vdrshare/video/testfile bs=16k count=16384
16384+0 records in
16384+0 records out


real    1m56.132s
user    0m0.012s
sys     0m3.932s
linvdr:~# time dd if=/vdrshare/video/testfile of=/dev/null bs=16k
16384+0 records in
16384+0 records out


real    0m39.433s
user    0m0.052s
sys     0m4.340s
linvdr:~#

Alles anzeigen

... und wenn ich richtig gerechnet habe gibt das 2,2Mbit/s schreibend und 6,5Mbit/s lesend. Dabei wundert mich eigentlich, daß ich fehlerfreie Aufnahmen hinbekomme. Habe auch schon andere Blockgrößen getestet - ähnliches Resultat.
[edit] falsch gerechnet: 17,6 MBit/s schreibend und 52 MBit/s lesend. Das ist doch eigentlich ok? Hmmm ...[/edit]

Gemountet habe ich so:

Code

fstab:
192.168.2.43:/media/raid01/vdr /vdrshare nfs defaults,auto 0 0
192.168.2.43:/media/raid01/musik /mnt/musik nfs defaults,auto 0 0

"video0" zeigt auf das Verzeichnis "/vdrshare/video" (symlink)

rijo

andreash · 4. Februar 2006

Code

[root@dvr video]# time dd if=/dev/zero of=/video/testfile bs=16k count=16384    16384+0 records in
16384+0 records out


real    0m33.888s
user    0m0.048s
sys     0m3.408s
[root@dvr video]# time dd if=/video/testfile of=/dev/null bs=16k
16384+0 records in
16384+0 records out


real    0m24.190s
user    0m0.072s
sys     0m1.536s

Alles anzeigen

34 Sekunden fuer 256MB schreiben= 7.5MB/s schreiben
24 Sekunden fuer 256MB lesen = 10.6MB/s lesen
Dabei duerfte der Cache eine nicht unwesentliche Rolle gespielt haben...

Hier mal meine mount-optionen:

Code

10.0.0.1:/video  /video         nfs     defaults,rsize=32768,wsize=32768,nfsvers=3

Wie gesagt, ich habe 8 nfsds laufen, denke aber nicht, dass das den grossen unterschied machen wuerde. Waehrend des Tests habe ich immer nur 2-3 aktive nfsds gesehen.

KdF · 4. Februar 2006

Hi rijo,

prüfe doch mal, ob deine Netzwerkkarte auf FullDuplex steht. Unter SuSE gibt es das Tool mii-diag (wenn ich mich nicht irre).
Außerdem kannst du mit der Option 'async' mounten, das sollte einiges an Performanz rausholen.

Viele Grüße
Rolf

rijo · 4. Februar 2006

Also:

Das Erhöhen der Anzahl ( 8 ) der nfs-Deamons hat von der Geschwindigkeit nichts gebracht. Ob sie unterschiedlich ausgelastet sind kann ich noch nicht sagen.

Das Ändern der Mount-Optionen ...

Code

192.168.2.43:/media/raid01/vdr /vdrshare nfs defaults,rw,async 0 0
bzw.
192.168.2.43:/media/raid01/vdr /vdrshare nfs defaults,rsize=32768,wsize=32768,nfsvers=3 0 0

... hat auch keinen Einfluß auf die Geschwindigkeit gehabt. (Habe natürlich jedesmal neu gemountet)

Am Server gibt mir mii-tool folgende Meldung

Code

~ # mii-tool
eth0: negotiated 100baseTx-FD, link ok

Nehme an FD heißt hier "full duplex"

Am VDR bekomme ich eine Fehlermeldung von mii-tool, aber von ethtool krieg ich was

Code

linvdr:~# mii-tool
SIOCGMIIPHY on 'eth0' failed: Operation not supported
no MII interfaces found
linvdr:~# ethtool eth0
Settings for eth0:


        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: d
linvdr:~#

Alles anzeigen

... so wie mir scheint beide Netzwerkkarten Full Duplex.

@Andreas
Dumme Frage? Welchen Cache meinst du?

rijo

andreash · 5. Februar 2006

Hi,

ich meinen den Betriebssystem-Cache. Linux verwendet allen freien Speicher als Disk-Cache. Weil 10MB/s lesen auf einem 100MBit Netz sind schon viel

Dein Netz sieht nach 100 FullDuplex aus, das waere ok. Ich habe noch Tests mit einem 600MHz Celeron gemacht, um zu sehen, ob es eventuell an der CPU des Epia liegt, aber die Werte sind identisch zu meinem 1300MHz System.

Zitat

Nun ja, es war schon besser. Im normalen Betrieb wirkt sich das so aus, daß ich keinen Beitrag ohne Störungen ansehen kann, wenn gleichzeitig eine Aufnahme läuft. Früher gingen das.

Hast du eventuell zwischendurch den VDR aktualisiert? Ich hatte auch Probleme, die der cUnbufferedFile-Patch behoben hat (http://www.linuxtv.org/piperma…2006-February/007674.html).

Ansonsten faellt mir nur noch ein, mal mit ifconfig oder netstat -i zu sehen, ob du Fehler auf den Interfaces hast (verlorene Pakete o.ae.). Wie sind die beiden PCs verbunden? Ueber einen Switch, oder direkt per Crossover-Kabel?

rijo · 5. Februar 2006

Hallo Andreas,

Cache: mit 512 MB Ram [edit](VDR)[/edit]sollte er noch genug Reserven für Cache haben.

Zitat

Hast du eventuell zwischendurch den VDR aktualisiert?

Oh ja, andauernd - Aber den habe ich in den letzten Tagen frisch aufgesetzt. Das Problem ist aber schon älter!
Das mit dem Patch klingt eigentlich nicht ganz nach meinem Problem. Es geht dabei doch um die soeben abgespielten Daten, welche durch den Patch noch etwas länger aufgehoben werden. Ich könnte es aber trotzdem mal ausprobieren. Außer, ist der Patch für meinen Softwarestand geeignet? Ich habe MarkTwain Patch - 1.3.24 und Cody Patch - 1.3.34 eingespielt. Der cUnbufferedFile-Patch nennt eine Version vdr-1.3.41 ????

Zitat

Wie sind die beiden PCs verbunden?

Das hatte ich auch schon ausprobiert, da ich seit einiger Zeit auch nen neuen Router habe. Ohne Router scheint es minimal besser zu sein. ca 3-4 Sekunden (bei 1'50'') für 256 MB.

ifconfig bringt mir:

Code

linvdr:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:40:63:D4:23:D3
          inet addr:192.168.2.40  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14357 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14112 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2885213 (2.7 MiB)  TX bytes:2100063 (2.0 MiB)
          Interrupt:10 Base address:0xec00


lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:294 errors:0 dropped:0 overruns:0 frame:0
          TX packets:294 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:317846 (310.3 KiB)  TX bytes:317846 (310.3 KiB)


linvdr:~#

Alles anzeigen

und netstat:

Code

linvdr:~# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:8000                  *:*                     LISTEN
tcp        0      0 *:sunrpc                *:*                     LISTEN
tcp        0      0 *:www                   *:*                     LISTEN
tcp        0      0 *:2001                  *:*                     LISTEN
tcp        0      0 *:2002                  *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 *:47867                 *:*                     LISTEN
tcp        0    132 localhost:ssh           localhost:2643          ESTABLISHED
udp        0      0 *:32768                 *:*
udp        0      0 *:4711                  *:*
udp        0      0 *:sunrpc                *:*
udp        0      0 *:1023                  *:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  6      [ ]         DGRAM                    1622   /dev/log
unix  2      [ ACC ]     STREAM     LISTENING     1707   /var/run/acpid.socket
unix  2      [ ]         DGRAM                    1951
unix  2      [ ]         DGRAM                    1939
unix  3      [ ]         STREAM     CONNECTED     1642
unix  3      [ ]         STREAM     CONNECTED     1641
unix  2      [ ]         DGRAM                    1639
unix  2      [ ]         DGRAM                    1621
linvdr:~#

Alles anzeigen

daran fällt mir nichts auf.

Zitat

um zu sehen, ob es eventuell an der CPU des Epia liegt

habe mal top laufen lassen, während eines Kopiervorgangs[edit](VDR-Rechner)[/edit]:

Code

17:49:36 up  1:41,  2 users,  load average: 0.12, 0.14, 0.09
41 processes: 39 sleeping, 2 running, 0 zombie, 0 stopped
CPU states:   0.2% user,   0.2% system,   0.0% nice,  99.6% idle
Mem:    482444K total,   103872K used,   378572K free,     6120K buffers
Swap:        0K total,        0K used,        0K free,    81900K cached


  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1506 root      16   0  1848  960   748 R     0.3  0.0   0:00 top
    1 root      16   0  2144  288   236 S     0.0  0.0   0:00 init
    2 root      34  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd/0
    3 root      10  -5     0    0     0 SW<   0.0  0.0   0:00 events/0
    4 root      12  -5     0    0     0 SW<   0.0  0.0   0:00 khelper
    5 root      11  -5     0    0     0 SW<   0.0  0.0   0:00 kthread
    7 root      10  -5     0    0     0 SW<   0.0  0.0   0:00 kblockd/0
    8 root      20  -5     0    0     0 SW<   0.0  0.0   0:00 kacpid
   84 root      10  -5     0    0     0 SW<   0.0  0.0   0:00 khubd
  132 root      20   0     0    0     0 SW    0.0  0.0   0:00 pdflush
  133 root      15   0     0    0     0 SW    0.0  0.0   0:00 pdflush
  135 root      11  -5     0    0     0 SW<   0.0  0.0   0:00 aio/0
  134 root      25   0     0    0     0 SW    0.0  0.0   0:00 kswapd0
  136 root      25   0     0    0     0 SW    0.0  0.0   0:00 jfsIO

Alles anzeigen

Der idle-Wert sprang so zwischen 99 und 60 hin und her, meist aber über 90 %.

rijo

knebb · 5. Februar 2006

Zitat

Original von rijo
Cache: mit 512 MB Ram sollte er noch genug Reserven für Cache haben.

Mein Server hat 1GB und das reicht bei den üblichen *vdr- Dateien auch nicht. Da ist dann die reine Plattenperformanz gefragt. Und wenn dann noch mehrere Clients auf die Kiste zugreifen....
Wie ist denn Dein Server sonst so ausgestattet und wieviele Sachen laufen gleichzeitig?

Zitat

Mem: 482444K total, 103872K used, 378572K free, 6120K buffers
Swap: 0K total, 0K used, 0K free, 81900K cached

Außerdem hast Du keinen Swap! Richte erst mal 1GB Swap (2xRAM) ein, dann sehen wir weiter.
Laß parallel dann mal vmstat 1 240 über vier Stunden mitprotokollieren. Das sind dann Aussagen.

rijo · 6. Februar 2006

knebb

Zitat

Außerdem hast Du keinen Swap!

... mein Fehler - das Top-Protokoll war vom VDR, nicht vom Server. Der VDR hat kein Swap weil er ohne Festplatte läuft. (Wäre ja für die Flash-Disk nicht so gesund.) Der Server hat relativ wenig RAM (256MB)+512MB Swap, OK.

Zitat

Mein Server hat 1GB und das reicht bei den üblichen *vdr- Dateien auch nicht.

Das Wäre ja schon fast ne halbe Stunde Filmmaterial? Willst du die VDR-Dateien am Stück cachen?
Die Plattenperformance sollte doch eigentlich durch den aktiven Raid 5 Controller gewährleistet sein (kein Software-Raid).
Habe aber trotzdem ausprobiert den Server mit zusätzlichen 512MB zu bestücken. Mehr konnte ich grad nicht organisieren. Auf eine erhöhung des Swap habe ich auch verzichtet, wollte ja nicht gleich neu Partitionieren.

Zum Vergleich habe ich auch noch das Kopieren von ner w2k-kiste probiert (dos-box). Da kam ich vorneweg schon mal auf 5,4 MB/s (bei einer 550 MB großen Datei). Nach dem Einsetzen des RAMs in den Server wurden das auf etwa 7,4 MB gesteigert.

Jetzt nochmal vom VDR aus probiert. Aber nix wars. Außer vielleicht 2-3 Prozent, mehr sind nicht drinn.

Zitat

Wie ist denn Dein Server sonst so ausgestattet und wieviele Sachen laufen gleichzeitig?

Asus K7V; Athlon 800MHz; 256MB; FastTrak S150 SX-M 64MB Cache (Raid5); 4xMaxtor 6B200M0; SuSE 9.0
Außer Samba und nfs läuft eigentlich nix drauf. Kein X, keine Server. Und wenn ich nen Film laufen habe ist die w2k-kiste aus. (Lärm) Dann greift auch kein anderer Client mehr auf den Server zu.

Zitat

Laß parallel dann mal vmstat 1 240 über vier Stunden mitprotokollieren.

am VDR (da hab ichs nicht drauf) oder am Server oder beiden?

rijo

1. Ergebnis: 1Gig Ram für den Server zum schnelleren kopieren.

knebb · 6. Februar 2006

Und was sacht vmstat?

Hauptsächlich Server, wenn Du dort den Flaschenhalt vermutest. Aber gleichzeitig auch den VDR, wenn möglich.

rijo · 6. Februar 2006

Zitat

Und was sacht vmstat?

Ähm, ja, das war noch meine Frage. Soll ichs auf dem VDR laufen lassen, da müsste ich noch sehen wie ichs drauf bekomme. Oder soll es auf dem Server laufen? Soll dabei eine Aufzeichnung laufen?

rijo

[edit]
ich sollte erst lesen

den Flaschenhals vermute ich aber eher am VDR. Dort hat sich ja die Speichererhöhung des Servers gar nicht ausgewirkt.

[/edit]

knebb · 6. Februar 2006

Zitat

Original von rijo
ich sollte erst lesen

Zitat

den Flaschenhals vermute ich aber eher am VDR. Dort hat sich ja die Speichererhöhung des Servers gar nicht ausgewirkt.

Eines nach dem anderen
Aufnahme starten, auf dem Server vmstat laufen lassen. Ausgabe hier posten. Dann sehen wir, wieviel der Server auf I/O wartet. ist doch der 2.6er Kernel auf dem Server, oder?

Danach die REINE NetzIO messen. Mit netio (heißt das so, weiß jetzt nicht genau...).
Und wenn beides paßt, auf dem VDR weitersuchen. Aber schön Schritt für Schritt.

Bei mir ist der Effekt, daß ich während des Schneidevorganges zwar Wiedergeben kann, aber nicht Schnittmarken setzen, das dauert ewig. Und der VDR ist mit 1Gigabit angeschlossen!

Habe mir allerdings noch nicht die Mühe gemacht, das zu optimieren. Hab' derzeit sowieso keine Zeit

rijo · 6. Februar 2006

Bevor ich jetzt 4 Stunden lang falsch protokoliere:
Vermute ich sollte vmstat mit der Option -a starten? 1 240 : dann läuft er doch nur 240 sekunden, mit sekündlicher Messung. Du meinst vermutlich sowas wie vmstat -a 60 240 ?

Zitat

ist doch der 2.6er Kernel auf dem Server, oder?

leider nein. Kernel 2.4.21-99. Damals gab's für meinen Controller nur dafür nen passendes modul.

"netio" finde ich leider nicht (geht auch was anderes?) könnte man beide Programme gleichzeitig laufen lassen? Oder bin ich jetzt wieder zu schnell

rijo

rijo · 15. Februar 2006

Hallo,

habe jetzt vmstat auf dem Server mitlaufen lassen.

Fall 1: Aufzeichnung (vmstat.rec.log im Anhang), hier ein Auszug

Code

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free  inact active   si   so    bi    bo   in    cs us sy id wa
 0  0    700   6172 502304 201184    0    0     0     0 1018    35  1  0 99  0
 0  0    700   6172 502304 201184    0    0     0   156 1047    20  0  1 99  0
 0  0    700   5980 502416 201188    0    0     0    32 1035    48  0  1 99  0
 1  0    700   5816 502540 201188    0    0     0     0 1113    37  0  1 99  0
 0  1    700   5968 504344 199272    0    0     0  4100 8479  1221  1 41 58  0
 0  1    700   5968 504344 199272    0    0     0  3144 1417    15  0  0 100  0
 0  1    700   5968 504344 199272    0    0     0  3000 1424    17  0  1 99  0
 0  2    700   5968 504344 199272    0    0     0     0 1432    13  0  1 99  0
 0  0    700   5912 504400 199272    0    0     0   104 1110    34  0  0 100  0
 1  0    700   6140 504768 198692    0    0     0     0 3144   380  0 12 88  0
 0  1    700   6036 504836 198692    0    0     0  2976 1411    24  0  1 99  0
 0  0    700   6036 504836 198692    0    0     0     4 1017    13  1  1 98  0
 0  0    700   6036 504836 198692    0    0     0     0 1008    11  0  0 100  0
 0  0    700   6036 504836 198692    0    0     0     0 1008    11  0  0 100  0
 0  0    700   5952 504904 198692    0    0     0    80 1085    52  0  1 99  0
 0  0    700   5952 504904 198692    0    0     0     0 1008    11  0  0 100  0
 0  0    700   5952 504904 198692    0    0     0     0 1008    11  0  1 99  0
 0  0    700   5952 504904 198692    0    0     0     0 1010    12  0  0 100  0
 0  0    700   5952 504904 198692    0    0     0     0 1008    11  0  0 100  0
 0  0    700   5948 504904 198692    0    0     0     0 1007    13  1  0 99  0
 0  2    700   5936 504916 198692    0    0     0   220 1250    25  0  0 100  0

Alles anzeigen

Fall 2: Aufzeichnung und Wiedergabe einer anderen Sendung (vmstat.recplay.log im Anhang), hier ein Auszug

Code

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free  inact active   si   so    bi    bo   in    cs us sy id wa
 1  0    700   5672 405716 297984    0    0     0     0 1580    80  0  3 97  0
 0  0    700   5672 405172 298528    0    0     0     0 1543    59  0  2 98  0
 0  0    700   5672 404692 299008    0    0     0     0 1366    51  1  2 97  0
 0  0    700   5672 404212 299488    0    0     0     0 1343    49  0  2 98  0
 1  2    700   6272 405260 298092    0    0     0  1528 3824   477  0 16 84  0
 0  1    700   6052 407180 296368    0    0     0  4160 6354   825  0 29 71  0
 0  1    700   5912 406700 296848    0    0     0  3204 1617    39  0  2 98  0
 0  1    700   5912 406700 296848    0    0     0  1400 1405    17  1  1 98  0
 0  0    700   5908 405740 297808    0    0     0    44 2291   153  0  5 95  0
 0  0    700   5908 404780 298768    0    0     0     0 1771    93  0  3 97  0
 0  0    700   5908 404300 299248    0    0     0     0 1365    50  0  3 97  0
 0  0    700   5884 403844 299728    0    0     0    28 1415    73  0  1 99  0
 0  0    700   5884 402884 300688    0    0     0     0 1767    98  0  4 96  0
 0  0    700   5884 402404 301168    0    0     0     0 1365    54  1  2 97  0
 0  0    700   5884 401924 301648    0    0     0     0 1395    51  0  2 98  0
 1  0    700   5884 401220 302352    0    0     0     0 1413    76  0  2 98  0
 0  0    700   5884 400484 303088    0    0     0     0 1710    79  0  3 97  0
 0  0    700   5860 400028 303568    0    0     0    28 1407    64  0  2 98  0
 0  1    700   6104 401548 301784    0    0     0  5288 7005   974  0 32 68  0
 0  1    700   6104 401548 301784    0    0     0  1892 1419    19  1  1 98  0
 0  0    700   6104 401068 302264    0    0     0    36 1911    91  0  4 96  0

Alles anzeigen

Fall 3: Aufzeichnung und Wiedergabe der gleichen Sendung (vmstat.recplay2.log im Anhang), hier ein Auszug

Code

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free  inact active   si   so    bi    bo   in    cs us sy id wa
 1  0    700   5356 373972 330156    0    0     0     0 2704   613  0  8 92  0
 0  0    700   5332 373228 330924    0    0     0    28 1751   189  0  3 97  0
 0  0    700   5332 372748 331404    0    0     0     0 1430   154  1  2 97  0
 0  0    700   6408 371712 331420    0    0     0    72 1534   167  0  3 97  0
 0  0    700   6408 371232 331900    0    0     0     0 1425   157  0  2 98  0
 0  0    700   6408 370272 332860    0    0     0     0 1833   188  0  4 96  0
 0  0    700   6408 369792 333340    0    0     0     0 1464   160  0  2 98  0
 0  0    700   6372 369348 333820    0    0     0    40 1458   187  0  2 98  0
 0  0    700   6372 368868 334300    0    0     0     0 1456   108  1  3 96  0
 0  0    700   6372 368388 334780    0    0     0     0 1383    77  0  2 98  0
 0  0    700   6364 367908 335264    0    0     0     0 1448    96  0  2 98  0
 0  0    700   6364 367428 335744    0    0     0     0 1448   179  0  2 98  0
 1  0    700   5360 369704 334576    0    0     0     0 6157   903  0 26 74  0
 0  3    700   6048 369764 333664    0    0     0  6320 2202   172  0  6 94  0
 0  3    700   6048 369764 333664    0    0     0   868 1413    15  1  1 98  0
 0  8    700   6328 369752 333184    0    0     0   728 1961   182  0  4 96  0
 0  0    700   5912 369096 334120    0    0     0   312 2909   994  0  7 93  0
 0  0    700   5912 367656 335560    0    0     0     0 2258   325  0  6 94  0
 0  0    700   5912 367176 336040    0    0     0     0 1450   101  0  2 98  0
 0  0    700   5912 367176 336040    0    0     0     0 1032    49  0  0 100  0
 0  0    700   5912 366216 337000    0    0     0     0 1757   162  0  3 97  0

Alles anzeigen

Beim Fall 3 traten im Abstand von einigen sekunden regelmäßig Fehler auf. Und zwar immer dann wenn der wert Blocks out hoch war. Beim 1. und 2. Fall sind mir keine Fehler aufgefallen.

rijo

knebb · 15. Februar 2006

Zitat

Original von rijo
habe jetzt vmstat auf dem Server mitlaufen lassen.

Schön, denn das ermöglicht ein paar Aussagen.
Zum einen wird klar, daß CPU-I/O-Waits (Spalte wa) durchgehend auf "0" sind. D.h. der Server wartet keinen Moment auf IO. D.h. die NFS-Daemons können alle angeforderten Daten so schnell wie es ihnen möglich ist, lesen und schreiben. [EDIT] Ach ne, Du hast ja einen 2.4er Kernel, da ist der Wert immer auf 0. Also leider keine Aussagekraft.[/EDIT]

Weiterhin in SwapIN und SwapOUT (si/so) auch stets auf "0", d.h. der Server ist nicht mit Swappen beschäftigt, hat wohl ausreichend RAM.

Zitat

Beim Fall 3 traten im Abstand von einigen sekunden regelmäßig Fehler auf. Und zwar immer dann wenn der wert Blocks out hoch war. Beim 1. und 2. Fall sind mir keine Fehler aufgefallen.

Tja, in der Tat schwierig. Entweder ist da kein Fehler oder der Server ist pauschal zu schwachbrüstig vom allgemeinen Durchsatz her.

Sagt denn das Logfile des VDRs zu diesen Zeitpunkten irgendwas?

Ich tendiere fast dahin, einen 2.6er Kernel draufzupacken und dann mal weitergehend zu prüfen (z.B. mit dem Parameter "-d").

rijo · 15. Februar 2006

Logread am VDR zeigt keine auffälligen Meldungen. Ab und zu Einträge wie

Code

Feb 15 18:30:45 linvdr user.debug vdr[2055]: buffer usage: 70% (tid=20492)
Feb 15 18:30:46 linvdr user.debug vdr[2055]: buffer usage: 80% (tid=20492)
Feb 15 18:30:46 linvdr user.debug vdr[2055]: buffer usage: 90% (tid=20492)
Feb 15 18:30:46 linvdr user.debug vdr[2055]: buffer usage: 30% (tid=20492)

... Die stehen allerdings nicht im zeitlichen Zusammenhang zu den Bildstörungen.

Wenn ich top am VDR laufen lasse scheint der Prozess "rpciod/0" immer nach oben zu springen. Der hat doch auch was mit nfs zu schaffen?

Code

linvdr:~# top
Unknown HZ value! (85) Assume 100.
 18:27:28 up  2:59,  1 user,  load average: 1.83, 1.76, 1.83
64 processes: 58 sleeping, 6 running, 0 zombie, 0 stopped
CPU states:  74.4% user,  13.4% system,   2.1% nice,  10.1% idle
Mem:    482444K total,   465996K used,    16448K free,     7340K buffers
Swap:        0K total,        0K used,        0K free,   381040K cached


  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 2061 root      20   0 78444  33M  3980 R    68.6  0.0  28:40 vdr
 1298 root      10  -5     0    0     0 SW<   6.7  0.0   2:38 rpciod/0
 2055 root      15   0 78444  33M  3980 S     4.9  0.0   6:07 vdr
 2056 root      15   0 78444  33M  3980 S     2.5  0.0   2:20 vdr
 2060 root      16   0 78444  33M  3980 R     2.1  0.0   5:17 vdr
 2087 root      16   0 78444  33M  3980 R     2.1  0.0   0:13 vdr
 2044 root      34  19 78444  33M  3980 R N   1.9  0.0   2:45 vdr
 2041 root      34  19 78444  33M  3980 R N   0.5  0.0   2:18 vdr
 2090 root      16   0  1852  964   748 R     0.5  0.0   0:01 top
 2088 root      15   0 78444  33M  3980 S     0.1  0.0   0:04 vdr
    1 root      16   0  2144  292   236 S     0.0  0.0   0:00 init
    2 root      34  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd/0
    3 root      10  -5     0    0     0 SW<   0.0  0.0   0:00 events/0
    4 root      12  -5     0    0     0 SW<   0.0  0.0   0:00 khelper

Alles anzeigen

rijo

knebb · 15. Februar 2006

Wie gesagt, inzwischen bald keine Ahnung.

rpcio ist der Prozess, der für NFS zuständig ist, ja. Wenn auf meinem AufnahmeVDR was läuft, liegt der eigentlich immer fast bei 0%

Es scheint wohl an irgendeiner Netzwerkeinstellung zu liegen. Laß doch parallel mal ein ping -f server laufen, ob es da Auffälligkeiten gibt. Das spürt Netzwerkfehler recht zuverlässig auf

Anzahl der nfs-Daemons auf SuSE-Server

Jetzt mitmachen!

Teilen