# Problème de débit avec NFS ou comment l'optimiser? **URL:** \ **Category:** Support Debian\ **Created:** [Août 17, 2020, 5:08 UTC](https://www.debian-fr.org/t/probleme-de-debit-avec-nfs-ou-comment-loptimiser/82646 "2020-08-17T17:08:16Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![libresurf](https://www.debian-fr.org/user_avatar/www.debian-fr.org/libresurf/32/5259_2.png) [@libresurf](https://www.debian-fr.org/u/libresurf)\ **Post date:** [Août 17, 2020, 5:08 UTC](https://www.debian-fr.org/t/probleme-de-debit-avec-nfs-ou-comment-loptimiser/82646/1 "2020-08-17T17:08:16Z")
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 : ```nohighlight $ nc -l -p 1234 > test.data ``` - sur le client : ```nohighlight $ 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 : ```nohighlight 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 : ```nohighlight /etc/default/nfs-common ``` ```nohighlight NEED_STATD="no" STATDOPTS= NEED_IDMAPD="yes" NEED_GSSD="no" ``` ```nohighlight /etc/default/nfs-kernel-server ``` ```nohighlight 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="" ``` ```nohighlight /etc/exports ``` ```nohighlight /data CLIENT(rw,sync,no_root_squash,no_subtree_check) ``` Voici ma configuration sur le client : ```nohighlight /etc/fstab ``` ```nohighlight [...] SERVEUR:/data /mnt nfs4 noauto,user,sync,tcp 0 0 ``` et le montage du partage NFS sur le client : ```nohighlight $ 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. ---
**Author:** ![libresurf](https://www.debian-fr.org/user_avatar/www.debian-fr.org/libresurf/32/5259_2.png) [@libresurf](https://www.debian-fr.org/u/libresurf)\ **Post date:** [Août 17, 2020, 5:40 UTC](https://www.debian-fr.org/t/probleme-de-debit-avec-nfs-ou-comment-loptimiser/82646/2 "2020-08-17T17:40:16Z")
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 : ```nohighlight 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… ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Août 17, 2020, 7:11 UTC](https://www.debian-fr.org/t/probleme-de-debit-avec-nfs-ou-comment-loptimiser/82646/3 "2020-08-17T19:11:49Z")
> [@libresurf](#): > > ```auto > /etc/exports > > ``` > > ```auto > /data CLIENT(rw,sync,no_root_squash,no_subtree_chec > > ``` 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. > [@libresurf](#): > > […] SERVEUR:/data /mnt nfs4 noauto,user,sync,tcp 0 0 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. > [@libresurf](#): > > root@client:~# cat /proc/mounts évitez les commandes en étant `root` ```auto 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 ---
**Author:** ![libresurf](https://www.debian-fr.org/user_avatar/www.debian-fr.org/libresurf/32/5259_2.png) [@libresurf](https://www.debian-fr.org/u/libresurf)\ **Post date:** [Août 18, 2020, 8:24 UTC](https://www.debian-fr.org/t/probleme-de-debit-avec-nfs-ou-comment-loptimiser/82646/4 "2020-08-18T08:24:19Z")
> [@littlejohn75](#): > > D’où sort cette option **sync**? L’option **sync** vient des exemples donnés dans le fichier _/etc/exports_ lors de l’installation du paquet _nfs-kernel-server_ : ```auto # /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… > [@littlejohn75](#): > > > [@libresurf](#): > > > > […] SERVEUR:/data /mnt nfs4 noauto,user,sync,tcp 0 0 > > 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. 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. > [@littlejohn75](#): > > > [@libresurf](#): > > > > root@client:~# cat /proc/mounts > > évitez les commandes en étant `root` > > ```auto > fgrep nfs /proc/mounts > > ``` Mince, j’étais persuadé que _/proc_ n’était accessible que par `root`. Mauvaise habitude de ma part… > [@littlejohn75](#): > > Supprimez la synchronisation devrait améliorer les choses. **ET COMMENT !!!** 😃 😃 😃 Voici ce que ça donne après avoir supprimé les références à **sync** : ```auto $ 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 !!! 😛 😜 🤪 Incroyable que cette option **sync** pénalise le débit à ce point. 🙄 Merci à toi **littlejohn75** , je marque le message comme résolu. ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Août 19, 2020, 8:41 UTC](https://www.debian-fr.org/t/probleme-de-debit-avec-nfs-ou-comment-loptimiser/82646/5 "2020-08-19T08:41:34Z")
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 : ```nohighlight 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 ---
**Author:** ![libresurf](https://www.debian-fr.org/user_avatar/www.debian-fr.org/libresurf/32/5259_2.png) [@libresurf](https://www.debian-fr.org/u/libresurf)\ **Post date:** [Août 19, 2020, 6:19 UTC](https://www.debian-fr.org/t/probleme-de-debit-avec-nfs-ou-comment-loptimiser/82646/6 "2020-08-19T18:19:08Z")
> [@anon70622873](#): > > 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 ! Il y avait peut-être un effet de cache disque. J’ai refait le test après reboot du client : ```plaintext $ 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_. > [@anon70622873](#): > > J’aurais préféré voir des test de performance en écriture avec des commandes du type : > > ```plaintext > time dd if=/dev/zero of=/point/montage/nfs bs=64k count=16384 > > ``` Et voilà ! ```plaintext $ 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. > [@anon70622873](#): > > D’abord _sync_ est la valeur par défaut depuis longtemps 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 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. ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Août 19, 2020, 6:47 UTC](https://www.debian-fr.org/t/probleme-de-debit-avec-nfs-ou-comment-loptimiser/82646/7 "2020-08-19T18:47:03Z")
> [@libresurf](#): > > 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. 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.