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.