Ich versuche, die Ursache für die schlechte NFS-Leistung zwischen zwei Xen-VMs (Client und Server) zu ermitteln, die auf demselben Host ausgeführt werden. Insbesondere ist die Geschwindigkeit, mit der ich eine 1 GB große Datei auf dem Client sequenziell lesen kann, viel niedriger als erwartet, basierend auf der gemessenen Netzwerkverbindungsgeschwindigkeit zwischen den beiden VMs und der gemessenen Geschwindigkeit beim Lesen der Datei direkt auf dem Server. Die VMs führen Ubuntu 9.04 aus und der Server verwendet das Paket nfs-kernel-server.
Laut verschiedenen NFS-Tuning-Ressourcen kann das Ändern der Anzahl der NFSD-Threads (in meinem Fall Kernel-Threads) die Leistung beeinträchtigen. Normalerweise wird empfohlen, die Anzahl auf stark genutzten Servern vom Standardwert 8 zu erhöhen. Was ich in meiner aktuellen Konfiguration finde:
RPCNFSDCOUNT=8: (Standard): 13,5–30 Sekunden zum Caten einer 1-GB-Datei auf dem Client, also 35–80 MB/Sek.
RPCNFSDCOUNT=16: 18 s zum Verarbeiten der Datei, 60 MB/s
RPCNFSDCOUNT=1: 8-9 Sekundenum die Datei zu caten (!!?!) 125MB/s
RPCNFSDCOUNT=2: 87 s zum Caten der Datei 12 MB/s
Ich sollte erwähnen, dass sich die Datei, die ich exportiere, auf einer RevoDrive-SSD befindet, die auf dem Server mit Xens PCI-Passthrough gemountet ist; auf dem Server kann ich die Datei in weniger als Sekunden (> 250 MB/s) caten. Ich lösche vor jedem Test Caches auf dem Client.
Ich möchte den Server nicht wirklich mit nur einem Thread konfiguriert lassen, da ich vermute, dass das bei mehreren Clients nicht so gut funktioniert, aber vielleicht verstehe ich das falsch. Ich habe die Tests ein paar Mal wiederholt (und dabei die Serverkonfiguration zwischendurch geändert) und die Ergebnisse sind ziemlich konsistent. Meine Frage ist also:Warum ist die Leistung mit 1 Thread am besten?
Ich habe versucht, noch ein paar andere Dinge zu ändern, allerdings mit wenig oder gar keinem Effekt:
Erhöhen der Werte von /proc/sys/net/ipv4/ipfrag_low_thresh und /proc/sys/net/ipv4/ipfrag_high_thresh von den Standardwerten 192K,256K auf 512K,1M
Erhöhen des Wertes von /proc/sys/net/core/rmem_default und /proc/sys/net/core/rmem_max von 128 KB auf 1 MB
Mounten mit den Client-Optionen rsize=32768, wsize=32768
Aus der Ausgabe von sar -d entnehme ich, dass die tatsächlichen Lesegrößen an das zugrunde liegende Gerät eher klein sind (<100 Bytes), was aber beim lokalen Lesen der Datei auf dem Client kein Problem darstellt.
Das RevoDrive stellt tatsächlich zwei „SATA“-Geräte /dev/sda und /dev/sdb bereit, dann nimmt dmraid ein über sie verteiltes fakeRAID-0 auf, das ich in /mnt/ssd gemountet und dann per Bind-Mount in /export/ssd gemountet habe. Ich habe lokale Tests an meiner Datei an beiden Orten durchgeführt und sehe die oben erwähnte gute Leistung. Wenn in Antworten/Kommentaren weitere Details verlangt werden, werde ich sie hinzufügen.
Antwort1
Wenn eine Client-Anforderung eingeht, wird sie an einen der Threads übergeben und die übrigen Threads werden aufgefordert, Read-Ahead-Operationen durchzuführen. Der schnellste Weg, eine Datei zu lesen, besteht darin, dies von einem Thread nacheinander tun zu lassen. Für eine Datei ist das also übertrieben und die Threads machen sich im Grunde selbst mehr Arbeit. Aber was für einen Client gilt, der eine Datei liest, muss nicht unbedingt auch für die Bereitstellung in der realen Welt gelten. Bleiben Sie also bei der Formel, bei der die Anzahl der Threads und die Anzahl der Read-Ahead-Operationen auf Bandbreiten-/CPU-Spezifikationen basieren.