NFS Server Performance sehr schlecht???

Ice

Well-Known Member
Hi Leute,

ich habe hier ein recht heftiges Problem mit der Performance meines NFS Servers unter FreeBSD.
Ich habe im Gigabit Lan nur etwa die Hälfte der Schreibgeschwindigkeit wie mit Linux als NFS-Server.
Um Hardware-Probleme auszuschließen habe ich jetzt auch mal beide OS auf der gleichen Maschine installiert.
In beiden Systemen habe ich lokal, wenn ich z.B. mit
Code:
dd if=/dev/zero of=/tmp/testfile bs=512K count=2000
auf die Platte schreibe die gleiche Performance von ca. 60MB/s.
Wenn ich nun per NFS auf die Systeme schreibe, dann erhalte ich unter

Linux: ca. 43MB/s
FreeBSD: ca. 20MB/s

Habt ihr eine Idee, woran das liegen könnte?

Ich habe beide Systeme zum Testen nackt installiert. Keine Firewall oder sonst was aktiv.

Die NFS-Shares sind folgendermaßen freigegeben:

Linux:
/tmp 192.168.1.1/255.255.255.255(rw,async,no_root_squash)

FreeBSD:
/tmp -maproot=root -network 192.168.1.0 -mask 255.255.255.0

Gemountet werden die Daten jeweils mit

LINUX:/tmp /mnt/test nfs rw,tcp,intr,noauto 0 0

bzw.

FREEBSD:/tmp /mnt/test nfs rw,tcp,intr,noauto 0 0

Habe ich irgendwas bei der Konfiguration des FreeBSD NFS-Servers falsch gemacht?
Wäre für jeden Tip dankbar.

Gruß,

Ice
 
Zuletzt bearbeitet:
Das klingt für mich irgendwie nach dem Performanceproblem mit dem gerade alle kämpfen und dessen Ursache noch niemand gefunden hat.

Yamagi hat einmal angedeutet er habe einen Verdacht. Ich bin gespannt.
 
Das Problem besteht sowohl unter 6.2 wie auch unter 6.3.
Und komischerweise wie beschrieben eben nur übers Netz.

Arrgh, ich will aber keinen Linux-NFS aufsetzen.... ;)

Gruß,

Ice
 
Hi,

schreib doch mal, was sysctl hierfür ausspuckt:

net.inet.tcp.recvspace
net.inet.tcp.sendspace
kern.ipc.maxsockbuf
net.inet.tcp.rfc1323
kern.ipc.nmbclusters
 
Hi Troll,

hier die Infos:

net.inet.tcp.recvspace: 65536
net.inet.tcp.sendspace: 32768
kern.ipc.maxsockbuf: 262144
net.inet.tcp.rfc1323: 1
kern.ipc.nmbclusters: 25600

Gruß,

Ice
 
Probier mal:

net.inet.tcp.sendspace: 65536
kern.ipc.nmbclusters: 32768

Ich hoffe, du lässt nfs über tcp laufen. Sonst wird sich nüscht ändern...
 
Hi Troll,

wie Du am Client-mount sehn kannst
FREEBSD:/tmp /mnt/test nfs rw,tcp,intr,noauto 0 0
benutze ich NFS tatsächlich über TCP.

Ich habe die sysctl-Werte mal so gesetzt, wie von Dir empfohlen. Geändert hat sich leider absolut nichts.
;'(

Gruß,

Ice
 
Intel Pro 1000XT Server Adapter

Ich habe die Karte auch schon mal gegen eine Intel Pro 1000MT ausgetauscht.

Gruß,

Ice
 
Hatte die sysctl-Einstellungen zunächst nur auf dem Server gemacht.
Habe das jetzt mal auch auf dem Client nachgezogen.
Ergebnis leider unverändert.

Gruß,

Ice
 
Mounte mal mit diversen rsize und wsize Parametern von 8kB ueber 16kB bis 32kB.

Schlussendlich kannst du noch vfs.nfsrv.async=1 setzen (auf dem Server), womit du die gleiche Schreib-Performance wie unter Linux kriegen wirst. Danach dann bitte wieder auf 0 stellen.
 
Hi MrFixit,

ähm, das versteh ich jetzt nicht so ganz. Wenn ich mit dem Eintrag
vfs.nfsrv.async=1
doch die gleiche Performance kriegen kann wie mit Linux, wieso soll ich es dann wieder zurücksetzen? Was sind die Schattenseiten?

Ich werd das auf jeden Fallmal ausprobieren.

Gruß,

Ice
 
ähm, das versteh ich jetzt nicht so ganz. Wenn ich mit dem Eintrag
vfs.nfsrv.async=1
doch die gleiche Performance kriegen kann wie mit Linux, wieso soll ich es dann wieder zurücksetzen? Was sind die Schattenseiten?
Diese Option sorgt dafür, das der Server alles aufnimmt, auch das was er nich intern verarbeiten kann. Ein Monstercache quasi. Bei kleinen Dateitransfers ist das ne Prima Sache, aber wehe du schiebst mal was dickes auf dn Server. Dann kannst nur noch zugucken wie der SWAP anschwillt :)
 
@marzl

Danke für die Erklärung.

@All

Ich habe jetzt auch schon die Schattenseiten des Linux-NFS-Servers gefunden. Wenn ich dort Daten hinschaufle ist für die Zeit des Transfers der Server NICHT mehr zu erreichen. Ich kann das System nicht mal mehr pingen!!! :eek:

Das kann doch alles nicht normal sein, oder?!

Gruß,

Ice

EDIT:

Und bei größeren Datenmengen bricht die Performance nach ca. 500MB übertragenen daten auf einmal auf ca. 50% ein.
Die Übertragung beginnt mit 44MB/s und bricht dann auf 20-25MB/s ein.
 
Zuletzt bearbeitet:
Das sieht so aus als würde Linux genau das machen was vfs.nfsrv.async=1 unter FreeBSD macht. Ich denke eine schnellere Platte oder ein Raid5 könnte das ganze ohne faule Tricks beschleunigen.
 
@Kamikaze

Ja, den Verdacht hatte ich jetzt auch, dass Linux das so macht.
Ein RAID5? Ich habe in dem Server ein RAID5 mit 7+1 Platten an einem 3ware-Controller hängen. Auf das RAID5 ist die Schreibperformance am allerschlechtesten, was auch Sinn macht. Ein RAID5 ist halt im Schreibzugriff extrem langsam.

Seltsam ist nur, dass sich die Performance per NFS nur minimal verändert, wenn ich statt dem RAID5 auf eine RAID0 aus 3 Platten schreibe.

NFS:
RAID5: ca. 18MB/s
RAID0: ca. 24MB/s
Einzelplatte: ca. 24MB/s

Lokal habe ich auf dem RAID0 fast die 3fache Schreibgeschwindigkeit wie auf dem RAID5.

Lokal:
RAID5: ca. 30MB/s
RAID0: ca. 90MB/s
Einzelplatte: ca. 55MB/s

Irgendwie ist das sehr mysteriös.

Gruß,

Ice
 
Klingt als würde der Linux NFS-Server das gleiche tun wie der FreeBSD mit vfs.nfsrv.async=1. Meine Festplatte schafft auch nur zwischen 22 und 35 Mb/s (je nach dem wie weit außen die Parititon liegt). Ich denke eine schneller Platte oder ein Raid5 könnten das beschleunigen.
 
@Kamikaze

Verstehe ich jetzt nicht. Wieso RAID5? Mit RAID5 kann ich doch nichts beschleunigen? Du meinst RAID0, oder?!

Außerdem sind doch die Platten ganz offensichtlich deutlich schneller als das, was per NFS über's Netz kommt.

Ich hab unter Linux mal den Swap beobachtet während der NFS-Transfer lief - da ist zumindest nichts aufgelaufen.


Gruß,

Ice
 
Ihr vergesst das Systemdesign. Gerade bei älteren Maschinen hängen die Plattencontroller nicht selten direkt oder indirekt am gleichen PCI-Bus wie die Netzwerkkarte. Wenn auf der Last anliegt, belastet dies den PCI-Bus, was den Controller wieder bremst. Das System sammelt die Daten irgendwo im Cache und sobald der voll ist, gibts Probleme.
Der 3Ware wird bei dir wohl am PCI hängen. Oder am PCI-X, aber das nimmt sich nicht so viel. Die Netzwerkkarte auch. Bleibt die Frage, woran der Onboard-Controller hängt...
 
@Ice
Raid5 ist auch schneller, weil keine Platte alle Daten erhält. Wenn das bei dir nicht der Fall ist, gibt es einen Engpass.
 
@Yamagi

Damit hast Du natürlich vollkommen recht. Aus dem Thema mit dem Systemdesign ist das ganze erst erwacht, denn der Server lief vormals auf einem älteren System mit PCI 2.1. Da war die Performance auf dem 3ware (PCI) noch viel schlechter.
Jetzt habe ich das System in ein neueres System mit PCI 2.2 umgezogen und die Performance ist allein dadurch schon um einiges besser geworden.

Gruß,

Ice
 
Etwas offtopic: Mit einem 7.0/32Bit habe ich derzeit dauerhafte Datenraten per NFS vom ca. 40 bis 55MB/s. Client ist dabei ein FreeBSD 6.3.
 
Hi j_t,

ich finde das gar nicht offtopic.
was hast Du an Hardware (Festplatten) dahinter hängen?
Einzelplatte? RAID?
Hast Du mal lokal getestet, was Du für Raten hast?

Werde 7.0RC auf jeden Fall auch mal testen.

Gruß,

Ice
 
Zurück
Oben