Arch Linux

Vrob

Mitglied

NFS Übertragungen nur stoßweise

Hallöchen,

ich frickle derzeit ein bisschen an meinem neuen Server rum, der eben auch Dateien
bereit stellen soll. Auf dem Server läuft ein Ubuntu Server 8.10 als Client fungiert (u.a.)
natürlich mein Arch-Desktop.
Mir ist jetzt aufgefallen, dass die Übertragungsraten über NFS sehr ungleichmäßig, quasi
stoßweise sind.

Beide Peers besitzen GBit onboard NICs (Desktop: Realtek 8168, Server: Via Velocity),
der Switch zwischen ihnen ist jedoch nur ein 100Mbit/Switch. Das Problem tritt auch auf,
wenn ich nicht die Via Velocity, sondern die ebenfalls vorhandene Via Rhine NIC (100 MBit)
nehme.

Was ich beobachte ist, dass die Übertragungen immer wieder auf fast 40-50 MB/s (mitunter
sogar 230 MB/s) spiken, aber Dolphin dann meldet, die Übetragungsgeschwindigkeit würde
auf ein paar hundert kb/s sinken und zwischendurch sogar gänzlich aufhören.
Tatsache ist jedoch, dass die Übertragungs-LEDs am Switch permanent wie irre flackern und
ebenso die Festplatte des Servers arbeitet.

Eine interessante Beobachtung zeigt auch die CPU-Last während des Transfers:
Solange die Geschwindigkeit hochspiked, geht die Last auf dem Server auf 0% (naja, ein
paar Prozent sinds schon, aber die sind durch die diversen Hintergrunddienste erklärbar).
Wenn mir mein System meldet, die Übertragung wäre angehalten, steigt die Last auf ca. 20-30%,
was mir eher realistisch erscheint.

Meine Vermutung ist, dass die Daten zunächst nicht direkt übertragen werden, sondern erst
in irgendeinem Cache landen und dann gemächlich mit 100MBit/s abgesendet werden.
Lasse ich mir die durchschnittliche Geschwindigkeit über den Transfer anzeigen, komme ich
bei genügen großen Volumina (>1 GB) auch auf einen Mittelwert von ca. 10 MB/s, was man
in einem 100 mbits LAN ohne tolle NICs durchaus erwarten würde.

Prinzipiell wäre das ja jetzt kein Problem, aber leider kommen einige Anwendungen damit
nicht klar und blockieren einfach während der tatsächlichen Übertragung. Außerdem
fühlt sich die Übertragung nicht wirklich "rund" an.

Die diversen Logs auf Server und Client (dmesg, /var/log/{daemon.log, messages, error.log}) zeigen
nichts verdächtiges. Ich habe schon diverse rsize, wsize-Paare probiert, jedoch ohne Ergebnis.

Der Server läuft auf jfs, aber auch wenn ich die Datenpartition auf xfs ändere, zeigt sich das
Problem davon unbeeindruckt, weshalb ich von einem Clientseitigen Problem ausgehe.

Ein kurzer Test mit dem Ubuntu-PC meiner Mutter zeigte dort auch wesentlich "ruhigere" Transfers.
Zwischendurch gabs zwar einige Schwankungen, aber die lagen durchaus im Rahmen, zumal die
Kiste eh etwas langsam ist

Sodele,
ich hoffe ihr könnt mir da ein wenig helfen

Vrob

tomprogrammer

Mitglied

Re: NFS Übertragungen nur stoßweise

Ich habe auch per Samba von WinXP auf mein Archlinux ca. 2GB übertragen. Die Trafficanzeige in Arch hat aber auch deutliche Schwankungen (100 KB/s bis 5MB/s, häufig flatternd) und sogar zweisekündige "Aussetzter" gezeigt.

Ich bin auch auf eine Erklärung/Lösung gespannt.

Thomas

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Vrob, dein beobachtetes Verhalten bzgl. der Peaks / "Aussetzer" ist richtig und "normal". Während
des Transfers einer großen Menge am Stück entstehen zu unterschiedlichen Zeiten unterschiedliche
Flaschenhälse am Client und am Server. Generell ist der Flaschenhals bei 100baseTx sicher das Netzwerk, jede andere Komponente (Ram-Durchsatz, HD-Durchsatz) ist i.d.R. schneller.
Beim Kopiervorgang am Client werden Daten zuerst in den IO-Cache befördert (Erscheinung: Durchsatz ist wesentlich höher als das Netzwerk es hergibt). Im Idealfall kann die Anwendung frühzeitig weiterarbeiten. Bei großen Dateien ist der "schnelle" Cache irgendwann voll, dann muß auf die Abarbeitung durch den Flaschenhals Netz-Transfer gewartet werden (Erscheinung: 0-Byte Transfer). Serverseitig ist es ähnlich, wobei beim Empfangen dort der Flaschenhals eigentlich immer das Netzwerk ist, die Daten werden aber vom Filesystem gecached weggeschrieben. Wenn am Server die HD-IO nun sowieso hoch ist kann es aber auch sein das der Netztransfer nicht mit optimaler Geschwindigkeit verarbeitet werden kann.
Durchschnittlich (das deckt sich ja mit deinen Erfahrung) "pendelt" sich die Rate aber auf das langsamste Medium ein - in einem 100baseTx ist das eben das Netzwerk. Dabei egal, ob die Übertragung nun synchron oder asynchron erfolgt (Stichwörter!)

Man kann das sehr gut mit top sehen: Für einen Fileserver ist die CPU-Leistung meist nicht wesentlich relevant, eher die Komponenten IO-Controller/HDs/Netzwerk. Wenn du Client/Server bei einem solchen Transfer am mit top beobachtest wirst du sehen, das die CPU-Last bei (us,sy und ni) wenig ist, was das idle aber "auffrisst" ist der hohe Wert bei Wait(wa). Die CPU würde/könnte also "weiterrechnen", muß aber auf Daten warten (entweder HD-IO oder Net-IO).

Bei NFS solltest du v.a. ein paar "Eckdaten" abklopfen:
a) Erfolgt die Verbindung über TCP oder UDP?
b) Zeigen sich im Netz hohe Fehlerraten (bei UDP ob Fragmentierungsfehler vorliegen)?
c) Einigen sich alle Komponenten(Netzkarten, Switches) auf einen gemeinsamen Nenner, bei dir im Idealfall 100baseTx-FD, also FullDuplex?

Zu a) Poste doch mal für einen NFS-Share vom Client und Server:
Client: cat /proc/mounts (Den Block für einen NFS-Mount)
Server: exportfs -v (für die gleiche Freigabe)

Zu b) Klopfe die Ausgaben von:
netstat -s und ifconfig sowohl am Server als auch am Client auf Errors, Drops, Failure oder Fragementierungsfehler ab. Evtl. mal posten/anhängen nach einigen "Problemtransfers"

Zu c) Kannst du an Server/Client mit dem Befehl:
mii-tool (Im Paket net-tools) feststellen, auch mal mit: mii-tool -v schauen/posten.

Man kann bei NFS etliches an Performance (je nach Einsatzzweck) einstellen, verbessern/verschlechtern. Ein bißchen Lese/Stöberstoff (ist ein bißchen veraltet, vieles berücksichtigt den 2.6er Kernel nicht, aber prinzipiell weiter gültig):
http://nfs.sourceforge.net/
http://nfs.sourceforge.net/nfs-howto/

@tomprogrammer: Zu Samba kann ich wenig sagen, manches von oben würde auch für dich relevant sein. evtl. mal in den Dokus auf www.samba.org schauen, es gibt (AFAIK auch in Deutsch) auch etliche OpenBooks zu Samba. IMHO is NFS halt generell wesentlich performanter, "freundlicher" als SMB/Cifs.

tomprogrammer

Mitglied

Re: NFS Übertragungen nur stoßweise

Ok, danke für deine ausführliche Schilderung.

Mich interessiert jetzt noch wie ich den Festplattendurchsatz bestimmen kann.
Die Platte werkelt jetzt schon über acht Jahre in meinem Rechner, weswegen ich keine allzuhohe Schreib/Leserate erwarte. Aber sie tut (immer noch) guten Dienst
Der Befehl hdparm -Tt /dev/sdx zeigt mir ja nur die Leserate. Außerdem ist mir der Unterschied zwischen 'cached read' und 'buffered read' nicht wirklich klar.

Ich werde jetzt mal testen, welche Performanceunterschiede zwischen NFS und Samba herrschen. Für Datentransfers zwischen Linux nutzte ich ja NFS, aber beim Datenaustausch mit WinXP muss ich auf Samba zurückgreifen.

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Mich interessiert jetzt noch wie ich den Festplattendurchsatz bestimmen kann.

Der Befehl hdparm -Tt /dev/sdx zeigt mir ja nur die Leserate. Außerdem ist mir der Unterschied zwischen 'cached read' und 'buffered read' nicht wirklich klar.

Bei hdparm: der Wert bei -T ist gemessen mit Cache, also wie Kernel+FS+HD dir i.d.. Daten ausliefern.
Zum realen Messen eben nur der HD ist der Wert von -t relevant.

Andere Tools zum Messen:
dd (aufpasssen, manpage lesen!) oder bonnie++

tomprogrammer

Mitglied

Re: NFS Übertragungen nur stoßweise

Danke, bonnie++ gibt mir alle Informationen die mich interessieren.

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

Ok, hier sind die Daten:

Zu a) Poste doch mal für einen NFS-Share vom Client und Server:
Client: cat /proc/mounts (Den Block für einen NFS-Mount)
Server: exportfs -v (für die gleiche Freigabe)

Vom Client:

epiasrv:/srv/data /mnt nfs rw,vers=3,rsize=262144,wsize=262144,namlen=255,soft,nointr,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.6.20,mountvers=3,mountproto=tcp,addr=192.168.6.20 0 0

Vom Server:

/srv/data       192.168.6.0/24(rw,async,wdelay,no_root_squash,no_subtree_check)

Zu b) Klopfe die Ausgaben von:
netstat -s und ifconfig sowohl am Server als auch am Client auf Errors, Drops, Failure oder Fragementierungsfehler ab. Evtl. mal posten/anhängen nach einigen "Problemtransfers"

Beide Outputs sagen nichts von Fehlern o.ä.

Zu c) Kannst du an Server/Client mit dem Befehl:
mii-tool (Im Paket net-tools) feststellen, auch mal mit: mii-tool -v schauen/posten.

Die Ausgaben von Server und Client unterscheiden sich nur in der Vendorzeile,
daher hier mal die vom Client:

eth0: negotiated 100baseTx-FD flow-control, link ok
  product info: vendor 00:07:32, model 17 rev 2
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

Also ich würde das so interpretieren: Alles OK!

Nichtsdestotrotz finde ich dieses Verhalten ein wenig... irritierend, aber ich nehme an,
man kann dagegen nicht besonders viel tun, oder? Gerade auf dem Server möchte ich
Lastspitzen eigentlich vermeiden.

Grüße,
Vrob

tomprogrammer

Mitglied

Re: NFS Übertragungen nur stoßweise

Wie bekomme ich denn Informationen über die Fragmentierungsfehler von gesendeten Paketen? Irgendwie hat das doch mit ping funktioniert, vermute ich.

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Hi Vrob,

soweit würde ich auch sagen alles ok, also keine Fehler o.ä. was ich sehe.
Vorteilhaft für Performance ist das TCP statt UDP genutzt wird (in "guten" Umgebungen das beste).
Auch würde nur bei UDP ein evtl. Fragementierungsproblem eine nennenswerte Rolle spielen.

Zwei Ansatzpunkte sehe ich doch:
a) du exportierst deine NFS-exports mit async. Das würde ich mal auf den (mittlerweile) Default-Wert
sync stellen, also async aus den exports raus. Nach meinen Test sorgt async zwar für einen etwas
besseren Durchsatz (bei mir getestet ca. 200-300kb/s), beim Transfer sehe ich aber deutlich größere
Schwankungen im durchschnittlichen Datendurchsatz.

b) größeren Cache bei den In/Output Queues der Netzwerk-Sockets
Mit:

cat /proc/sys/net/core/rmem_default
cat /proc/sys/net/core/wmem_default

kannst du die momentanen Werte sehen. Bei 2.4er Kernel waren die 64k, beim 2.6 AFAIK 128k (oder
dynamisch bestimmt?).
Erhöhen dieser Caches am NFS-Server zeigt bei mir eine deutlich geringere Server-Last (weniger wait, mehr idle bei top). Ich habe sie aktuell auf 256k

echo 262144 > /proc/sys/net/core/rmem_default
echo 262144 > /proc/sys/net/core/rmem_max
echo 262144 > /proc/sys/net/core/wmem_default
echo 262144 > /proc/sys/net/core/wmem_max

Eine weitere Möglichkeit (je nach dem wieviele Clients/User/NFS-Zugriffe in der Umgebung vorkommen) ist die Erhöhung der Anzahl der nfsd-Instanzen. Per defualt sind das momentan 8, ich starte hier 16.
Wird geregelt über /etc/conf.d/nfs -> NFSD_OPTS=
Weiterhin mounte ich an den Clients so, daß nur nfsv3 als Protokoll genutzt wird von den Client-Prozessen, ich habe keine Clients die damit nicht zurechtkommen.
MOUNTD_OPTS="--no-nfs-version 1 --no-nfs-version 2"
auch in der etc/conf.d/nfs

Dein Hauptproblem war/ist ja eher scheinbar das "Stocken" wenn bei der Übertragung der Übergang vom Schreiben in den Client-FS-Cache zum "realen" Kopieren übers Netzwerk passiert. Bzw. scheinbar
Durchsatzschwankungen gen Null während des Transfers.
Das allerdings sollte Clients (die ja zum Abschluß des Transfers auf die Rückmeldung von Daemons und Kernel warten sollten) nicht aus dem Tritt bringen. Gibt es Progs/Tools die dir da besonders Probleme machen? Ich sage mal: ein cp, ein dd oder die Kopieraktionen von mc oder thunar haben da keinerlei Probleme mit.

Ich finde eine gute Kombination zum Testen des Durchsatzes auch während der Verbindung ist:
eine große Datei (größer als der Gesamt-Ram) nehmen (oder erzeugen z.B. mit:
dd if=/dev/zero of=/tmp/bigfile bs=1m count=2000)
Solch eine Datei dann auf den NFS-Mount kopieren oder auch lesen:

dd if=/tmp/bigfile bs=64k | pv > /mnt/data/bigfile
(/mnt/data halt nur einen eigenen Mountpoint ersetzen)

Man sieht durch pv (//Edit: pv ist ein Paket aus community) sehr gut:
a) den anfänglichen "Peek" wenn der Client-FS-Cache erstmal gefüllt wird
b) die "Stockung", wenn dieser Cache "voll" ist und erstmal durch das Ethernet "abgearbeitet" wird.
c) Die "Angleichung" des Transfers an den Durchsatz des Flaschenhalses (also Netzwerk bei 10/100MB). Während dieses Transfers schwankt die Durchsatzrate auch, das liegt aber dann IMHO an den Disk-IO-Dingen, auch ist die Schwankung gering (bei mir geht es z.B. nie unter 5Mb/s) und sollte sich im Sekunden/Millisekunden-Bereich bewegen. Der Hauptanteil sollte sich bei 100Mbit-FD um die 10-11 MB/s bewegen was auch die von dd gemeldete Durchschnitts-Transferrate sein sollte.

Bei allen Veränderungen an exports, /proc Werten usw. solltest du zwischen den Tests am Client die nfs-mounts aushängen und am Server den nfsd und portmap neu starten damit die Tests saubere
Ausgangsbedingungen haben.

Beitrag geändert von GerBra (12.11.2008 14:26:19)

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Wie bekomme ich denn Informationen über die Fragmentierungsfehler von gesendeten Paketen? Irgendwie hat das doch mit ping funktioniert, vermute ich.

netstat -s zeigt das i.d.R.
Fragmentierte Pakete sind auch nichts per se böses, lediglich bei UDP muß halt der komplette RPC-Transfer wiederholt werden bei Errors durch Fragmentierung (da verbindungsloser Transfer),
bei TCP langt es das betroffene Paket neu zu senden.

Nur generelle Fragmentierung ist schlecht, verringert den Datendurchsatz, wenn Pakete von den am Transfer beteiligten Devices in unterscheidliche Größen gepackt werden.
Ethernet-Default ist eine MTU von 1500. Wenn beim Transfer ein device jetzt eine kleinere MTU hat dann
entstehen dort Fragmente (die entweder so transportiert werden oder verworfen und neu angefordert werden). Jedesmal kostet dieser Vorgang Zeit oder verhindert eine erfolgreiche Datenübertragung sogar.

Ein bekanntes Problem ist das z.B. bei DSL (also PPP over Ethernet). Hier müssen TCP-Pakete inkl. Header in ein PPP-Paket "eingepackt" werden. Wenn beide Devices jetzt eine MTU von 1500 haben, dann
entstehen durch den PPP-Header bei großen Paketen automatsich Fragemente. So werden z.B.
manche Webseiten nicht angezeigt o.ä. Deshalb setzt man bei PPPoE die MTU für das Ethernet-Device meist auf 1492, so passt das wieder in die MTU von 1500 des ppp-Devices....

Ob man im LAN bzw. beim Transfer so ein Problem hat kann man wie gesagt mit netstat -s sehen, auch ifconfig sollte hohe Werte bei den Fehler-Modi bei RX/TX haben.
Oft langt aber schon ein:
tracepath zielrechner
Im Lan sollte pmtu immer bei 1500 liegen, eine mtu-Änderung (z.B. auf 1492) sollte lediglich auf Routern erfolgen.

Beitrag geändert von GerBra (12.11.2008 14:16:07)

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

Hallo GerBra,

erstmal danke, dass du so ausführliche Beiträge schreibst

Ich kann die von dir beschriebenen Schritte jetzt ziemlich gut nachvollziehen:

Top zeigt das ziemlich genau an: Während der "Stockphase" ist zunächst der idle beinahe 99%, anschließend geht der wait-Wert hoch. Sind die Daten dann angekommen, steigt moderat der sys-Wert und kcryptd (Festplatte ist verschlüsselt) rutscht nach oben. Dank Hardwarebeschleunigung ist das aber ein Klacks

Ich habe auch die von dir vorgeschlagenen Tipps ausgeführt, aber leider mit mäßigem Erfolg.
Das Erhöhen des Caches hat knapp 1 MB/s erhöhte Geschwindigkeit gebracht, aber sonst
hat sich nicht viel geändert.
Die mountd Optionen waren bei mir schon als Standard eingetragen

Leider gehen die wenigsten Programme bei mir so sorglos mit dem Stocken um:
mc ist direkt gecrashed nachdem der Cache das erste mal voll war,
pv scheint auch so seine Probleme damit zu haben: Die gesamte Anzeige (der Laufbalken, Zeit und Geschwindigkeit) stoppen ebenso und bewegen sich erst wieder, wenn Daten gecached werden,
dolphin bzw. KDE scheint während eines Kopiervorgangs zwar nicht zu blocken, aber ist subjektiv weniger responsiv.

In den wenigen Phasen, in denen die Ansicht aktualisiert wird (insbesondere bei Dolphin funktioniert das), geht die Rate auch auf ein paar kb/s runter, sie bleibt nicht durchweg über 5 MB/s wie bei dir.

Grüße,
Vrob

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Leider gehen die wenigsten Programme bei mir so sorglos mit dem Stocken um:
mc ist direkt gecrashed nachdem der Cache das erste mal voll war,
pv scheint auch so seine Probleme damit zu haben: Die gesamte Anzeige (der Laufbalken, Zeit und Geschwindigkeit) stoppen ebenso und bewegen sich erst wieder, wenn Daten gecached werden,
dolphin bzw. KDE scheint während eines Kopiervorgangs zwar nicht zu blocken, aber ist subjektiv weniger responsiv.
In den wenigen Phasen, in denen die Ansicht aktualisiert wird (insbesondere bei Dolphin funktioniert das), geht die Rate auch auf ein paar kb/s runter, sie bleibt nicht durchweg über 5 MB/s wie bei dir.

Hm, evtl. doch noch ein Problem mit den NICs bzw. dem Switch....
Teste doch mal ein wenig die generelle Netzwerk-Performance, unabhängig von NFS. Installiere mal die
Tools iptraf und iperf. Weiterhin hänge ich mal das Tool netio an, hatte ich aus den im Netz verfügbaren Sourcen kompiliert(i686).

iptraf (als root laufen lassen) ist ein Traffic-Monitor (zu vielen Zwecken sehr hilfreich). Starte diesen mal am Client oder Server und gehe in die Option "Detailed interface statistics", dann eth0. Damit kannst
du links unten Input/Output-Durchsatz messen, was aktuell interessiert wäre Total rates. Bei den nachfogenden Tests dies mal im Auge behalten, ob dort während die Tests laufen Durchsatzeinbrüche nachvollziehbar wären.

Die Tests:
a) iperf
Am Server: iperf -s
Am Client:

iperf -t30 -c dein_server
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec    338 MBytes  94.6 Mbits/sec
(Im iptraf fenster sollte total rate beim Transfer immer zwischen 11000-12000 kb/s liegen)

iperf -t30 -c dein_server -d
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-30.0 sec    318 MBytes  88.9 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.1 sec    304 MBytes  84.5 Mbits/sec
(Transfer in beide Richtungen, bei iptraf sollte total rate zw. 20000-21000 kb/s liegen, also volle FullDuplex Sättigung)

b) netio
Netio testest per Default Transfers mit unterschiedlichen Paketgrößen
Am Server: /tmp/netio -s
Am Client:

/tmp/netio -t dein_server

Packet size  1k bytes:  11513 KByte/s Tx,  11441 KByte/s Rx.
Packet size  2k bytes:  11509 KByte/s Tx,  11439 KByte/s Rx.
Packet size  4k bytes:  11508 KByte/s Tx,  11456 KByte/s Rx.
Packet size  8k bytes:  11510 KByte/s Tx,  11451 KByte/s Rx.
Packet size 16k bytes:  11498 KByte/s Tx,  11457 KByte/s Rx.
Packet size 32k bytes:  11492 KByte/s Tx,  11367 KByte/s Rx.

Auch hier sollte total rate bei iptraf immer zwischen 11000-12000 kb/s liegen. Und bei den Ergebnissen sollte bei den unterschiedlichen Paketgrößen keine groben Unterschiede in der Transferrate liegen.

Zum Switch nochmal: evtl. kannst du dir testweise einen anderen Switch leihen, evtl. sogar einen GigaByte-Switch (die kosten ja auch nix mehr). Wobei das eher zum Testen wäre ob bei veränderter Hardware diese Einbrüche/Stockungen auch passieren.

Anbei das Tool netio, zum benutzen halt ausführbar machen
Gepackt als Zip.

Beitrag geändert von GerBra (12.11.2008 19:35:52)

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

Hallöchen,

also ich habe mal deine Tests ausgeführt, danke nochmal:

Eins vorweg: Iptraf lief während der Tests und zeigte keine Einbrüche der Verbindungsgeschwindigkeit.

iperf

$  iperf -t30 -c 192.168.6.20                                    
------------------------------------------------------------                             
Client connecting to 192.168.6.20, TCP port 5001                                         
TCP window size: 16.0 KByte (default)                                                    
------------------------------------------------------------                             
[  3] local 192.168.6.5 port 45490 connected with 192.168.6.20 port 5001                 
[ ID] Interval       Transfer     Bandwidth                                              
[  3]  0.0-30.1 sec    339 MBytes  94.6 Mbits/sec

$  iperf -t30 -c 192.168.6.20 -d                                 
------------------------------------------------------------                             
Server listening on TCP port 5001                                                        
TCP window size: 85.3 KByte (default)                                                    
------------------------------------------------------------                             
------------------------------------------------------------                             
Client connecting to 192.168.6.20, TCP port 5001                                         
TCP window size: 23.6 KByte (default)                                                    
------------------------------------------------------------                             
[  6] local 192.168.6.5 port 45510 connected with 192.168.6.20 port 5001                 
[  5] local 192.168.6.5 port 5001 connected with 192.168.6.20 port 45040                 
[ ID] Interval       Transfer     Bandwidth                                              
[  6]  0.0-30.0 sec    316 MBytes  88.4 Mbits/sec                                        
[ ID] Interval       Transfer     Bandwidth                                              
[  5]  0.0-30.2 sec    308 MBytes  85.7 Mbits/sec

netio

$  ./netio -t 192.168.6.20

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  11510 KByte/s Tx,  11456 KByte/s Rx.
Packet size  2k bytes:  11518 KByte/s Tx,  11427 KByte/s Rx.
Packet size  4k bytes:  11510 KByte/s Tx,  11455 KByte/s Rx.
Packet size  8k bytes:  11510 KByte/s Tx,  11461 KByte/s Rx.
Packet size 16k bytes:  11472 KByte/s Tx,  11457 KByte/s Rx.
Packet size 32k bytes:  11519 KByte/s Tx,  11384 KByte/s Rx.
Done.

Sieht für mich alles normal aus.
Ich werde mir dann mal morgen irgendwie hier im Haus einen Switch besorgen und schauen,
ob das was ändert.

Grüße,
Vrob

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Sieht für mich alles normal aus.
Ich werde mir dann mal morgen irgendwie hier im Haus einen Switch besorgen und schauen,
ob das was ändert.

Glaube ich auch nicht, muß also nicht losstürzen
Das wäre eher dann ein Versuch wert, wenn obige Tests z.B. eine AUffälligkeit gezeigt hätten.

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

Sieht für mich alles normal aus.
Ich werde mir dann mal morgen irgendwie hier im Haus einen Switch besorgen und schauen,
ob das was ändert.

Glaube ich auch nicht, muß also nicht losstürzen

Meine Familie wirds schon überleben, mal 5 Minuten ohne Inet zu sein

Grüße,
Vrob

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Meine Familie wirds schon überleben, mal 5 Minuten ohne Inet zu sein

Du Tyrann! Aber an solchen Aussagen sieht man, wer die Pantoffeln anhatt

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

So, hier das versprochene, leicht verspätete Update.

Ich habe mir jetzt einen Gigabit-Switch gekauft und den zwischen
PC und Server gehangen. Leder waren die Ergebnisse mit NFS
ziemlich ernüchternd.
Im Grunde war dasselbe Verhalten zu beobachten:
Erst schneller Transfer, dann sinkt die Rate auf knapp 2 MB/s
(das ist ja schonmal ein Fortschritt...) und mittelt sich langfristig
bei ca. 11 MB/s ein.
Nicht unbedingt das, was ich von Gigabit erwartet hätte

Gut, es waren relativ alte CAT5 Kabel im Spiel, aber ein kurzer
Test mit Samba zeigte konstante Raten von 35 MB/s, was schon-
mal ganz annehmbar ist.

Irgendwo ist also der Wurm bei NFS drin. Letztendlich kann
ich mich aber auch mit Samba anfreunden, da ich sowieso
ein heterogenes Netzwerk habe und eh nicht um die Einrichtung
von Samba herumgekommen wäre.
Ich dachte nur eben, NFS könnte einen Geschwindigkeits-
vorteil bringen

Grüße,
Vrob

fs4000

Mitglied

Re: NFS Übertragungen nur stoßweise

Wir hatten in der Schule auch mit ganz ähnlichen Problemen zu kämpfen. Ein SuSE-Server sollte 17 Clientrechner per Netzwerk mit einem speziellen SuSE-System booten. Wenn man sich die Netzauslastung auf dem Server angeschaut hat, war er immer nur zeitweise voll ausgelastet.
Ich kann ja mal fragen, ob da irgendein Problem gefunden wurde.

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Im Grunde war dasselbe Verhalten zu beobachten:
Erst schneller Transfer, dann sinkt die Rate auf knapp 2 MB/s
(das ist ja schonmal ein Fortschritt...) und mittelt sich langfristig
bei ca. 11 MB/s ein.
Nicht unbedingt das, was ich von Gigabit erwartet hätte

Dieses beobachtete Verhalten ist wie gesagt IMHO vollkommen normal und pendelt sich im Mittel eben doch bei der max. Übertragungsrate ein. Den größten Vorteil des anfänglichen "schnellen" Transfers haben Vorgänge aus dem nomalen Alltag (außer du würdest immer/nur "große" Dateien kopieren)

Allerdings ist 11Mb/s (und auch die 35Mb/s später beim SMB/Cifs) für Gigabyte-Ethernet ja nicht berauschend, wobei das viele Ursachen (und bei GigaByte eben auch die Festplatten) sein können.

Noch mal ein Test. Dieser misst den Transfer ohne den Einfluß von HD-IO und Filesystems auf beiden Seiten, also auch ohne das Caching. Du brauchst auf beiden Systemen das Paket gnu-netcat.
Auf beiden Seiten mußt du kein root sein.
Am Server:

netcat -t -p 6666 -l > /dev/null

Am Client:

dd if=/dev/zero | pv | netcat dein_rechner 6666

Hier werden jetzt "Daten" nur von/nach Pseudo-Devices gelesen/geschrieben, IO spielt also zu keiner Zeit eine Rolle. Abbrechen am Client mit STRG+C, damit beendet sich auch der lauschende netcat am Server.
Außerdem lohnt es sich ggf. auch mal den Spieß umzudrehen, also den Listener am Client zu starten.
Du solltest hier konstant und von Anfang an die maximal mögliche Transferrate haben.

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

Soso,

was ich mit dem von dir gequoteten Text sagen wollte, war eigentlich nur, dass sich das Problem durch einen neuen Switch nicht wirklich in Luft aufgelöst hat

Dann habe ich auch mal die von dir vorgeschlagenen Tests ausgeführt:

Vom Client auf den Server: ~ 85 MB/s
Vom Server auf den Client: ~ 35 MB/s

Das ist ja doch ein recht großer Unterschied, aber andererseits ist auch der Via C7 Prozessor recht schwachbrüstig. Ebenso ist die Via Velocity sicherlich nicht die High-End-Server NIC, aber ob diese beiden Faktoren derart entscheidenen Einfluss auf die Performance haben, kann ich nicht sagen.

Was mir aber noch interessantes aufgefallen ist:
Trotz Gigabit Switch erhalte ich am Client folgende mii-tool Ausgabe:

$ mii-tool -v eth0
eth0: negotiated 100baseTx-FD flow-control, link ok
  product info: vendor 00:07:32, model 17 rev 2
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

Eigentlich hätte ich hier 1000baseT-FD erwartet, so wie das auch am Server der Fall ist.

Ebenso zeigt mir iperf folgendes an:

$  iperf -t30 -c 192.168.6.20                                                                                                                                     
------------------------------------------------------------                                                                                                                              
Client connecting to 192.168.6.20, TCP port 5001                                                                                                                                          
TCP window size: 16.0 KByte (default)                                                                                                                                                     
------------------------------------------------------------                                                                                                                              
[  3] local 192.168.6.5 port 60323 connected with 192.168.6.20 port 5001                                                                                                                  
[ ID] Interval       Transfer     Bandwidth                                                                                                                                               
[  3]  0.0-30.0 sec  3.29 GBytes    941 Mbits/sec

Hier erstmal angesichts eines mit Pflaster geflickten, mehrere Jahre alten Cat5-Kabels und der
low budget Netzwerkkarten kein übermäßig ernüchterndes Ergebnis.

Aber das hier macht mich ein bisschen stutzig:

$ iperf -t30 -c 192.168.6.20 -d                                                                                                                                  
------------------------------------------------------------                                                                                                                              
Server listening on TCP port 5001                                                                                                                                                         
TCP window size: 85.3 KByte (default)                                                                                                                                                     
------------------------------------------------------------                                                                                                                              
------------------------------------------------------------                                                                                                                              
Client connecting to 192.168.6.20, TCP port 5001                                                                                                                                          
TCP window size: 16.0 KByte (default)                                                                                                                                                     
------------------------------------------------------------                                                                                                                              
[  5] local 192.168.6.5 port 60329 connected with 192.168.6.20 port 5001                                                                                                                  
[  4] local 192.168.6.5 port 5001 connected with 192.168.6.20 port 52567
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-30.0 sec  1.80 GBytes    515 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.0 sec  1.24 GBytes    355 Mbits/sec

Bei Full-Duplex hätte ich jetzt eigentlich ~950 MBit/s in beide Richtungen erwartet, so wie 100 Mbit Ethernet auch der Fall ist. Der Switch unterstützt das laut Verpackung auch

Ein bisschen seltsam finde ich auch, dass ich im Vergleich zwischen netcat und SMB/cifs über die Hälfte an Performance verliere. Die Festplatten beider Systeme sind zwar 256 Bit verschlüsselt, aber der Client liest für Performancetests ja aus /dev/zero und der Cryptoprozessor des Epia Boards im Server leistet auch beste Dienste:

dd if=/dev/zero of=foo.dat bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1,0 GB) copied, 12,6015 s, 83,2 MB/s

Allerdings sagt top während eines Transfers über Samba, dass hauptsächlich auf IO gewartet wird (~40-50% wai).

Grüße,
Vrob

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

Nachtrag: Der Switch zeigt interessanterweise auch für den Client eine Gigabit-Verbindung an (erkennbar an der LED Farbe).

Schönen Sonntagabend wünschend,
Vrob

GerBra

Mitglied

Re: NFS Übertragungen nur stoßweise

Zur "Falschmeldung" von mii-tool: Das dürfte ein Programm-Fehler sein (Suche nach "mii-tool 1000base") zeigt da einiges. Ein weiteres Tool ist ethtool, dieses sollte auch mit NICs in 1000base keine Probleme haben.

Ich finde die Diskrepanz im Durchsatz beim letzten Test (wenn also der Server Daten liefert, und der Client nur ACK-Pakete dazu liefert) schon relevant. CPU sollte dabei keine Rolle spielen, beim netcat-Test sollten beide Systeme eigentlich ca. 75% vor sich hin idlen, die %wa sollte bei 0 sein.
Eher könnte die Ursache die NIC selbst sein, Kabel (cat5e sollte es schon sein), auch der PCI-Bus spielt eine Rolle. Beim realen Nutzen des Netzwerks kommt dann halt noch hinzu: das Zusammenspiel von NIC und HD-Controller (IRQ-Storm), dann CPU (und deine Verschlüsselung) und eben was die HDs an Durchsatz bieten, plus Overhead durch Filesystem/Netzwerk-Protokoll und eben wie gut diese einzelnen Komponenten halt ins Gesamtsystem ("Mainboard" allgemein) passen. Nicht umsonst haben z.B. Serverboards oder Server-Hardware ihren hohen Preis gegenüber Lidl-Rechnern

Das die ~35 MB/s am Server nicht durch CPU/Ramdurchsatz herrühren kannst du z.B. mit:
dd if=/dev/zero of=/dev/null
überprüfen, das wäre dann ein Anhalt für den Ram-Durchsatz und sollte wesentlich über den 35 liegen bzw. auch wesentlich über dem Maximum bei 1000base-Ethernet.

Das beim iperf-Duplex Test so schlechte Werte rauskommen ist auch klar: die 355 Mbits/sec entsprechen dem Test mit netcat - mehr kann der Server nicht liefern und das reduziert auch den Wert des Gegenparts.

Diese Tests (ich finde es immer wieder schön das unter Unixen solche Tests teils durch Kombination mit Bordmittel möglich sind, bzw. das man Einzelkomponenten gut testen kann), diese Tests sind ja nur Hilfmittel (und: wer viel mißt mißt Mist...
Ausgang waren/sind ja Stockungen/Einbrüche beim Datentransfer (sind diese eigentlich, je nachdem wer beim Transfer Sender bzw. Empfänger ist, unterscheidlich?).
Aufgrund der Tests würde ich aber schon den Server als Verursacher sehen, und da halt der "miese" Durchsatz, der ggf. weitere Probleme beim Real-Transfer hochschaukelt.

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

Ok, das mit dem mii-tool Bug wusste ich nicht

Ich habe jetzt mal ein paar cat5e Kabel aufgetrieben, allerdings ziemlich billige und in der Länge hoffnungslos überdimensioniert (zumindest das Client <-> Switch). Die Transferraten sind dadurch seltsamerweise sogar um knapp 4 MB/s gesunken!

Bezüglich zu der IRQ-Problematik:

root@server $ cat /proc/interrupts
           CPU0
  0:         96   IO-APIC-edge      timer
  1:       1645   IO-APIC-edge      i8042
  8:          2   IO-APIC-edge      rtc0
  9:          0   IO-APIC-fasteoi   acpi
 14:         91   IO-APIC-edge      pata_via
 15:          0   IO-APIC-edge      pata_via
 20:          0   IO-APIC-fasteoi   uhci_hcd:usb1
 21:          0   IO-APIC-fasteoi   uhci_hcd:usb3
 22:          0   IO-APIC-fasteoi   uhci_hcd:usb2, ehci_hcd:usb4
 28:    7836888   IO-APIC-fasteoi   eth0
221:     255261   PCI-MSI-edge      ahci
222:          0   PCI-MSI-edge      aerdrv
223:          0   PCI-MSI-edge      aerdrv
NMI:          0   Non-maskable interrupts
LOC:      55688   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

Ich weiß jetzt nicht, ob dir das weiterhilft, da ich mich selber mit IRQs überhaupt nicht auskenne. Der Wert ist nach einigen Tests gemessen worden (s.u.). Der eth0 counter rattert wie verrückt bei Datentransfer.
Wie gesagt, Durchsatz der HDD ist laut dd eigentlich ziemlich gut (knapp 85 MB/s schreibend), da kommt also nur das Zusammenspiel mit anderen Komponenten in Frage.

Ich habe mal ein bisschen mit Samba & NFS rumgespielt. Die Tests sind sicherlich nicht so aussagekräftig, wie das, was du mir immer anbietest, aber immerhin etwas:

Samba
* Server schreibt auf Client: ~ 20 MB/s
* Client schreibt auf Server: ~ 30 MB/s

NFS
* Server auf Client: ~ 75 MB/s
* Client auf Server: ~ 12 MB/s stark stockend

Als Test diente eine 1 GB große Datei, zwischen den Tests habe ich die entsprechenden Dienste jeweils neugestartet.

Außerdem habe ich die Rollen mal vertauscht und iperf auf dem Client als Server laufen lassen und ... naja ... auf dem Server als Client. Ich hoffe das war nicht zu verquast

$ iperf -t30 -c 192.168.6.5
------------------------------------------------------------
Client connecting to 192.168.6.5, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.6.20 port 45719 connected with 192.168.6.5 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec  2.84 GBytes    814 Mbits/sec

Das Duplex-Verhalten hat sich aber nicht geändert. Sehr seltsam.

Grüße,
Vrob

Beitrag geändert von Vrob (17.11.2008 20:55:09)

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

So,

ich bins nochmal.

Also ich bin leider immer noch nicht wirklich weiter mit meinem Problem.
Ich habe jetzt mal das System auf der CF Karte installiert, sodass die HDD vollständig als Storage Space benutzt werden kann.
Testweise habe ich die HDD auch unverschlüsselt freigegeben.

Leider alles ohne Änderung.

Die Schreibgeschwindigkeit ist immer noch miserabel.

Noch ein paar Symptome, die mir aufgefallen sind:

1. Während des Schreibens rödelt die HDD wie irre. Als würde ich tausende von kleinen Dateien transferieren, dabei benutze ich für die Transfertests eine 5GB große Datei, die aus /dev/zero kommt

2. Ich habe knapp 10 Instanzen von nfsd beim Schreiben, die in top um die oberste Stelle kämpfen. Was mich erst recht stutzig macht: die load average geht zum Teil auf 7-8 hoch (!!), was ja eigentlich heißt, dass 7-8 Prozesse auf Resourcen warten. Ich bin mir nicht sicher, ob ich das Prinzip von NFS & Portmapper verstanden habe, aber so eine extreme load ist doch sicher nicht im Sinne des Erfinders?

Edit:
Beim Lesen geht die Load zwar auch relativ hoch (~4), aber die Geschwindigkeit ist konstant hoch.
Dafür geht beim lesenden Client die load auf gut 3 hoch und er wird unbenutzbar langsam.

MfG,
Vrob

Beitrag geändert von Vrob (19.11.2008 23:01:00)

Vrob

Mitglied

Re: NFS Übertragungen nur stoßweise

Hallöchen,

auch auf die Gefahr hin, dass ich langsam anfange, Selbstgespräche zu führen und hier für triple-Posts aus dem Forum gebannt werde, gibts hier nochmal ein Statusupdate:

Nach einiger Frickelei und vielen Testreihen bin ich, denke ich, soweit, den Server als Fehlerquelle auszuschließen.

Hier meine Tests:

NFS Server auf dem Laptop
Der Laptop ist von der Hardware durchaus in der Lage, Gigabit annäherungsweise auszulasten: C2D, 3 GB RAM, S-ATA Disk, Gigabit NIC.
Als OS läuft natürlich Arch64.

Desktop --> Laptop: 15-20 MBs
Laptop --> Desktop: 80-90 MBs

Obwohl also eine gänzlich andere Netzwerkkarte verbaut ist (sowohl Desktop als auch Laptop haben eine Realtek 8169 Karte, die mit dem r8169 Modul läuft), die Architektur anders ist und sogar eine andere Distri läuft, scheint sich das Verhalten nicht zu ändern.

Konkret heißt Keine Änderung hier, dass ich vom Desktop extrem miese Schreibraten auf die NFS-Shares habe, aber sehr gute Leseraten. Die allgemeine Netzperformance habe ich jeweils mit netcat gemessen. Sie ist vom Desktop sendend sehr hoch, vom jeweiligen Server zum Desktop sendend, aber recht niedrig (ca. 35 MB/s).

Switch getauscht
Ich habe zwei D-Link Green Ethernet DGS-1005D gekauft, um mein Netzwerk auf Gigabit umzurüsten. Nunja, hätte ja sein können, dass ich ein Montagsmodell erwischt habe. Also fix den zweiten ausgepackt und angeschlossen:
Keine Änderung.

Schreibtests mit kurzen CAT5e Kabeln
Durch Zufall konnte ich auch noch zwei sehr kurze (50cm) Cat5e Kabel, die explizit für Gigabit zugelassen sind, auftreiben.
Als Server kam wieder der Laptop zum Einsatz, Client ist nachwievor der Desktop.
Keine Änderung.

Ubuntu-Live CD
Um auch Fehler in den Arch NFS-Paketen auszuschließen habe ich mir schnell eine Ubuntu 8.10 64Bit Live-CD getoastet und meinen Desktop damit gebootet.
Zunächst wurde wieder auf den Laptop und dann auf den Ubuntu Server geschrieben bzw. gelesen.
Keine Änderung

Damit konnte ich schonmal sowohl Arch als auch den Server als Fehlerquelle ausschließen.

Nun noch der letzte, verwirrende Test:

NFS Server auf dem Desktop
Zu guter letzt baute ich schnell einen NFS-Server auf meinem Desktop-PC, da sich alle anderen Server bis jetzt gleich verhielten. Das legt natürlich die Vermutung nahe, dass das Problem irgendwo zwischen Stuhl vor dem Desktop und der Netzwerkkarte liegt Alle anderen Komponenten habe ich ja schon ausgetauscht.

Laptop schreibt auf den Desktop: 15 MBs-20 MBs (!!)
Server schreibt auf den Desktop: 15 MBs
Lesend vom Desktop (Laptop oder Server): 20 MBs

Was ich hier absolut nicht verstehe ist, dass es ja Tests gibt, die zeigen, dass der Desktop durchaus in der Lage ist, anständige Performance zu bringen:
Senden: netcat auf beliebige Peers
Empfangen: Daten über NFS lesen klappt mit voller Geschwindigkeit (z.T. 80 MB/s) von beliebigen Peers

Der Test, bei dem der Laptop-NFS-Client auf den Desktop-NFS-Server schreibt, darf man nicht so sehr für bare Münze nehmen, da auch der Laptop eine r8169 Karte hat und ich im Moment vermute, dass diese Karte ein Problem mit dem Schreiben auf NFS hat. Wenn ich nämlich vom Laptop auf den Ubuntu-Server schreibe, bekomme ich exakt dieselben Probleme.
Das erklärt aber noch nicht, warum auch der Ubuntu-Server so niedrige Schreibraten auf den Desktop bekommt.

Irgendwie bin ich einfach total verwirrt

Das Problem scheint scheinbar irgendwo bei den r8169 Karten im Zusammenhang mit NFS und Gigabit zu sein. Andererseits habe ich ja sehr gute Leseraten über NFS, während die Empfangsraten mit netcat nur ungefähr die Hälfte der Bandbreite zeigen.
Vielleicht bringt uns das ja mit der Fehlersuche weiter....

Schönen Abend wünschend,
Vrob