[sage] Jemand Erfahrungen mit NFS ueber 10 Gbit/s?

[Wolfgang Stief]

Hallo Admins!

On 2007-02-09 08:36 +0100, Wolfgang Stief wrote:
> [...ueber Durchsatz-Probleme mit NFS ueber 10GBE...]

Zunaechst danke allen, die Vorschlaege und Ideen geliefert haben. Neben 
den Reaktionen in der Liste bekam ich auch allerlei Mails direkt in die 
Inbox.

For the impatient: Wir konnten das Problem am Freitag nicht mehr loesen, 
was aber weniger an den Vorschlaegen als vielmehr an der Zeit lag. 
Leider muessen die beiden 10GBE-Karten am Montag beim Distributor sein, 
weshalb die FR abend noch in die Post gingen. Wir koennen im Moment also 
nicht weiter testen.

Damit aber alle was davon haben, moechte ich im folgenden kurz auf ein 
paar Dinge eingehen, die mir vorgeschlagen wurden. Vielleicht hilfts dem 
einen oder anderen ja bei der eigenen Fehlersuche.

Folgende Parameter hatten wir schon eingestellt, BEVOR ich das Problem 
in der Liste schilderte:

   ip_squeues_fanout = 1
   ip_squeues_bind = 0
   tcp_recv_hiwat = 393216
   tcp_xmit_hiwat = 393216
   Jumbo Frames enabled

Und das waren die genauen Messwerte:

   NFSv4 mit wsize,rsize=1m -> max. 140 MB/s
   FTP mit tcpwindow=256k -> max. 240 MB/s
   zfs send .. | zfs receive -> 170 MB/s
   netperf -> ca. 800 MB/s


Ein erster Einwand war, doch mal nach Fehlern zu schauen, sowohl in 
Logfiles als auch mit netstat. War alles sauber. FTP haben wir von /tmp 
gelesen bzw. geschrieben, das ist bei Solaris physikalisches RAM (und 
das war mit 16GB gross genug :-)

Von Sun kam der Hinweis, die maximal parallelen NFS-Connects 
hochzusetzen. Brachte in erster Iteration auch nichts, fuer tiefere 
Recherche war zuwenig Zeit. Das Manual dazu:

   http://docs.sun.com/app/docs/doc/817-0404/6mg74vsae?a=view

Ausserdem kam von Sun der Hinweis, auf etwaige Unvertraeglichkeiten 
zwischen asynchronem ZFS und synchronem NFS. Erklaert wird das in einem 
Blog:

   http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine

Einen Check auf UFS anstatt ZFS als Basis im Fileserver konnten wir 
leider nicht mehr durchfuehren.

Aus einer anderen Richtung kam der Hinweis, sich doch mal das 
Bandbreitenprodukt genauer anzuschauen. Da rein faellt dann auch die TCP 
Window-Groesse. Dazu habe ich auch drei recht brauchbare Artikel im Web 
gefunden:

   http://www.kehlet.cx/articles/99.html
   http://www.psc.edu/networking/projects/tcptune/
   http://www.informit.com/articles/article.asp?p=99812&seqNum=4&rl=1

Nach wie vor bin ich der Meinung, dass der Hund zum groessten Teil 
(wahrscheinlich aber nicht ausschliesslich) hier begraben liegt. Erste 
Versuche bringen leicht verbesserte Ergebnisse, fuer eine genauere 
Untersuchung fehlte auch hier leider die Zeit. Benedikt hatte da gestern 
abend ja eine aehnliche Vermutung.

Und diese Offload-Geschichte ist in der Tat kein CRC sondern ein von 
Gert richtig vermutetes "TCP FCS offload".


Sofern wir bei naechster Gelegenheit wieder passende Hardware und Zeit 
im Haus haben, werden wir an dem Phaenomen ganz sicher weiter suchen und 
weiter lernen. Als wir vor 5 Jahren mit Benchmarks von Storage-Systemen 
anfingen, sind wir auch in allerlei Anfaengerfehler gelaufen :-)


Gruesse aus Muenchen
wolfgang


-- 
stief at guug.de                                   http://www.guug.de/
GPG: www.chaes.de/id.html        http://www.guug.de/lokal/muenchen/