Problème de débit avec NFS ou comment l'optimiser?

Support Debian
#1

Bonjour à tous,

J’ai un gros soucis de débit extrêmement faible avec NFS.

Pour les tests, le serveur et le client sont sur le même réseau local et tous les deux utilisent NFSv4 sous debian 10 buster.

Un test hors NFS en utilisant netcat me donne un débit de 98,8MiB/s (soit environ 828,8 Mbps/s) :

  • sur le serveur :
$ nc -l -p 1234 > test.data
  • sur le client :
$ pv image.iso | nc serveur 1234 -w10
    1,11GiO 0:00:11 [98,8MiB/s] [=======================================>] 100%

Maintenant, en utilisant NFS par l’intermédiaire d’une redirection de sortie standard, le débit tombe à 5,60MiB/s et encore en forcant le buffer de données à 16 MB !!! Sans forcer le buffer, je tombe encore plus bas à 1,65MiB/s.

  • Sur le client :
pv -B 64M image.iso > /mnt/data.test
    1,11GiO 0:03:23 [5,60MiB/s] [========================================>] 100%

Dans le premier cas, le transfert des 1,2 GO s’effectue en 11 secondes !!!
Dans le deuxième cas, le transfert prend plus de 3 minutes !!!

Voici ma configuration sur le serveur :

/etc/default/nfs-common

NEED_STATD="no"
STATDOPTS=
NEED_IDMAPD="yes"
 NEED_GSSD="no"

/etc/default/nfs-kernel-server

NEED_STATD="no"
NEED_IDMAPD="yes"
NEED_GSSD="no"
RPCNFSDCOUNT=4
RPCNFSDPRIORITY=0
RPCNFSDOPTS="-N 2 -N 3"
RPCMOUNTDOPTS="--manage-gids -N2 -N3"
NEED_SVCGSSD="no"
RPCSVCGSSDOPTS=""

/etc/exports

/data    CLIENT(rw,sync,no_root_squash,no_subtree_check)

Voici ma configuration sur le client :

/etc/fstab

[...]
SERVEUR:/data    /mnt    nfs4    noauto,user,sync,tcp    0    0

et le montage du partage NFS sur le client :

$ mount -vvvv /mnt
mount.nfs4: timeout set for Mon Aug 17 18:23:26 2020
mount.nfs4: trying text-based options 'tcp,vers=4.2,addr=192.168.0.1,clientaddr=192.168.0.6'

Savez-vous comment on peut optimiser le débit NFS ?
Merci à vous.

#2

Je continue mes investigations.
Il semblerait que les paramètres rsize et wsize aient été négociés entre le client et le serveur à leur valeur maximum. D’après la page du manuel, cette valeur est plafonnée à 1048576 bytes.

Sur le client :

root@client:~# cat /proc/mounts
[...]
SERVEUR:/data /mnt nfs4 rw,sync,nosuid,nodev,noexec,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.6,local_lock=none,addr=192.168.0.1 0 0

Il ne semble donc pas y avoir d’optimisation à faire du côté de ces paramètres…

#3

D’où sort cette option sync ?
Pour monter une clé USB, à la rigueur (pour un périphérique lent de toute façons), je comprendrais. Mais pour un export via le réseau , de tout un système de fichiers, c’est la garantie assurée d"avoir un système de fichiers qui se traîne.

idem pour sync et à quoi sert vraiment l’option tcp ?
Le type générique nfs serait préférable, de toute façons avec un NFS assez moderne (des deux côtés) le bon protocole et les bonnes options seront prises en compte.

évitez les commandes en étant root

fgrep nfs /proc/mounts

Supprimez la synchronisation devrait améliorer les choses.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

3 J'aime
#4

L’option sync vient des exemples donnés dans le fichier /etc/exports lors de l’installation du paquet nfs-kernel-server :

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#

Je n’ai fais que reprendre le dernier exemple et rajouter l’option no_root_squash.
Mais c’est également une vieille habitude, j’ai toujours mis l’option sync à cet endroit. Peut-être cela était-il nécessaire à une certaine époque dans une version inférieure de NFS…

Idem, vieille habitude, j’ai toujours fait comme ça et ne me rappelle plus pourquoi…
Mais je n’avais constaté de telles lenteurs de transferts de fichiers avec le protocole NFS.

Mince, j’étais persuadé que /proc n’était accessible que par root.
Mauvaise habitude de ma part…

ET COMMENT !!! :smiley: :smiley: :smiley:

Voici ce que ça donne après avoir supprimé les références à sync :

$ pv image.iso > /mnt/test.data
1,11GiO 0:00:08 [ 141MiB/s] [=========================================>] 100%

C’est encore plus rapide qu’avec netcat !
141MiB/s <=> 1182,8 Mbps/s !!!
On ne peut gère faire mieux avec du Gigabit Ethernet. J’utilise le réseau à pleine puissance !!! :stuck_out_tongue: :stuck_out_tongue_winking_eye: :crazy_face:

Incroyable que cette option sync pénalise le débit à ce point. :roll_eyes:

Merci à toi littlejohn75, je marque le message comme résolu.

#5

J’ai du mal à croire qu’il y ait une telle augmentation des performances, jusqu’à dépasser la capacité d’un lien 1 Gbit/s !
J’aurais préféré voir des test de performance en écriture avec des commandes du type :

time dd if=/dev/zero of=/point/montage/nfs bs=64k count=16384

D’abord sync est la valeur par défaut depuis longtemsp et elle ne devrait pas être modifiée à moins d’accepter le risque de corruption de données (plantage, redémarrage intempestif du serveur, etc.).
Si on enlève sync du fichier exports, cela ne changera rien.
Il faut préciser explicitement async dans le fichier exports pour que le serveur rende la main sans attendre d’être sûr que les données ont bien été écrite sur le disque. On va certes gagner (un peu) en performance, mais au prix d’une moindre sécurité des données.

cf. man exports

#6

Il y avait peut-être un effet de cache disque.
J’ai refait le test après reboot du client :

$ pv image.iso > /mnt/test.data
1,11GiO 0:00:11 [99,5MiB/s] [====================================================>] 100%

C’est quand même nettement mieux que mon tout premier test où j’obtenais 5,60MiB/s et proche de ce que j’obtiens avec netcat.

Et voilà !

$ time dd if=/dev/zero of=/mnt/test.data bs=64k count=16384
16384+0 enregistrements lus
16384+0 enregistrements écrits
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 15,4727 s, 69,4 MB/s

real    0m16,590s
user    0m0,014s
sys     0m0,641s

C’est quand même moins rapide que précédemment, mais je pense que dd doit avoir un système de synchronisation pour pouvoir vider et recharger le buffer, ce qui ralentit légèrement le débit.

Je suis d’accord, mais les faits sont là.
En spécifiant les options sync dans les fichiers concernés, ça rame et en retirant ces options, le débit est correct. Je n’ai rien changé d’autre.

#7

Je parle uniquement de l’option sync de NFS : celle du fichier exports. AMHA, si tu la remtes explicitement dans ce fichier cela ne changer rien. De tourte façon si tu ne vois pas async dans le retour de exportfs -v c’est que l’option sync est bien activée.
L’option sync dans le fstab était effectivement peut être problématique.