Linux-Netzwerke: Leistung von NFS-Systemen steigern

NFS muss nicht langsam sein. Mit kleine Änderungen an den Voreinstellungen, die bei den meisten Linux-Distributionen übrigens recht konservativ justiert sind, kann ein Leistungsschub erreicht werden. Diese Anpassungen lassen sich sowohl an den NFS-Servern als auch an den Clients vornehmen.

Auf der Serverseite muss sichergestellt werden, dass ausreichend NFS-Kernel-Threads vorhanden sind, damit die Verbindungen der Clients abgewickelt werden können. Ob die voreingestellte Anzahl ausreicht, kann festgestellt werden, indem man sich mit nfsstat auf dem NFS-Client die RPC-Statistik anschaut:


# nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
3409166    330        0

Im Code ist zu sehen, dass der retrans-Wert recht hoch liegt. Das bedeutet, dass seit dem letzten Neustart häufig erneute Übertragungen nötig waren. Das ist ein klarer Anhaltspunkt dafür, dass die Anzahl der verfügbaren NFS-Kernel-Threads auf dem Server nicht ausreicht, um die Anfragen dieses Clients zu bewältigen. Die voreingestellte Anzahl an Threads für rpc.nfsd liegt normalerweise bei acht Threads.

Um rpc.nfsd anzuweisen, mehr Kernel-Threads zu verwenden, muss ihm die Anzahl der Threads als Argument übergeben werden. Dafür gibt es normalerweise in den meisten Distributionen eine Konfigurationsdatei wie /etc/sysconfig/nfs. Auf einem Mandriva-Linux-System wird das Konfigurationselement RPCNFSDCOUNT in /etc/sysconfig/nfs verwendet, um die Anzahl der Kernel-Threads zu bestimmen, die rpc.nfsd übergeben werden. Es empfiehlt sich, die zu erhöhende Zahl der Threads bei einem leicht beanspruchten Server auf 16, bei einem stark beanspruchten System auf bis zu 32 oder 64 zu setzen.

Jetzt prüft man erneut die Werte mit nfsstat, um festzustellen, ob die Anzahl an Kernel-Threads nun ausreicht oder nicht. Liegt der retrans-Wert bei 0, ist die Anzahl ausreichend. Muss der Client aber noch immer Dateien erneut übertragen, ist es angebracht die Zahl der Threads weiter zu erhöhen.

Clientseitig sollten entfernte NFS-Laufwerke mit den folgenden Optionen gemountet werden:


rsize=32768,wsize=32768,intr,noatime

Standardmäßig werden die meisten Clients NFS-Dateisysteme mit einer Lese-Schreibblock-Größe von 8 KByte mounten. Der oben aufgeführte Befehl vergrößert den Lese-Schreibblock auf 32 KByte. Er stellt zudem sicher, dass NFS-Operationen unterbrochen werden können, wenn etwas klemmt. Ebenso sorgt er dafür, dass die atime von Dateien, auf die auf entfernten NFS-Dateisystemen zugriffen wird, nicht laufend aktualisiert wird.

Wenn NFS-Dateisysteme über /etc/fstab gemountet werden, sollten die Änderungen dort vorgenommen werden. Andernfalls muss man sie in allen Konfigurationsdateien des gewählten Automounters durchführen. Im Fall von amd sähe die Datei /etc/amd.net folgendermaßen aus:

Werden die Voreinstellungen von NFS-Servern und -Clients richtig angepasst, kann das das NFS schneller und reaktionsfreudiger machen. Das gilt besonders dann, wenn die NFS-Dateisysteme stark beansprucht sind.

ZDNet.de Redaktion

Recent Posts

Salesforce: Mit Einstein GPT zurück auf die Überholspur?

Salesforce forciert den Ausbau seiner Industry Clouds. Mit ihrem Prozesswissen könnten deutsche IT-Dienstleister davon profitieren.

20 Stunden ago

Neue Backdoor: Bedrohung durch Malvertising-Kampagne mit MadMxShell

Bisher unbekannter Bedrohungsakteur versucht über gefälschte IP Scanner Software-Domänen Zugriff auf IT-Umgebungen zu erlangen.

2 Tagen ago

BSI-Studie: Wie KI die Bedrohungslandschaft verändert

Der Bericht zeigt bereits nutzbare Angriffsanwendungen und bewertet die Risiken, die davon ausgehen.

3 Tagen ago

KI-Wandel: Welche Berufe sich am stärksten verändern

Deutsche sehen Finanzwesen und IT im Zentrum der KI-Transformation. Justiz und Militär hingegen werden deutlich…

3 Tagen ago

Wie ein Unternehmen, das Sie noch nicht kennen, eine Revolution in der Cloud-Speicherung anführt

Cubbit ist das weltweit erste Unternehmen, das Cloud-Objektspeicher anbietet. Es wurde 2016 gegründet und bedient…

3 Tagen ago

Dirty Stream: Microsoft entdeckt neuartige Angriffe auf Android-Apps

Unbefugte können Schadcode einschleusen und ausführen. Auslöser ist eine fehlerhafte Implementierung einer Android-Funktion.

3 Tagen ago