# [Optimisation NFS-1Gbits] Est-ce que j'ai fait le tour?

## El_Goretto

Bonjour,

je me suis penché sur le "tuning" réseau entre mon serveur hébergeant 1 gros disque NFS et mon PC qui travaille dessus en permanence (données, mais pas /home). Les 2 machines sont en direct l'une sur l'autre avec le même controleur Gigabit des 2 côtés.

Après une petite recherche (2 liens pas mal: http://nfs.sourceforge.net/nfs-howto/performance.html et http://www.int-evry.fr/mci/user/procacci/Doc/nfs.html#htoc3), j'en suis arrivé à tripoter les paramètres suivants:

la MTU: passé à 9000 pour faire des jumbo frames en Gbit (lien qu'il est bien)

forcer la version 3 de NFS

utiliser UDP (lien réseau fiable)

serveur et client en mode asynchrone: parait que c'est dangereux, qu'il faut mieux mettre le serveur en synchrone et le montage client en asynchrone... Mouais, je suis en full asyn depuis pas mal de semaines déjà (ext3 derrière).

taille des blocs NFS laissée 8K pour coller avec la taille des jumbos frames

les buffers TCP/IP pour un environnement Gbit: passé à 256KB, mais je pense encore augmenter un chouilla et voir ce que çà donne.

Toute suggestion/commentaire sur le sujet est bien évidemment avidement attendu  :Smile: 

----------

## anigel

 *El_Goretto wrote:*   

> [*]utiliser UDP (lien réseau fiable)

 

Je suis loin d'être un pro de NFS, mais il me semble que pour un débit soutenu, et des performances optimales, TCP est plus indiqué ?

----------

## El_Goretto

 *anigel wrote:*   

>  *El_Goretto wrote:*   [*]utiliser UDP (lien réseau fiable) 
> 
> Je suis loin d'être un pro de NFS, mais il me semble que pour un débit soutenu, et des performances optimales, TCP est plus indiqué ?

 

A priori non.

Les en-têtes TCP sont largement plus gros, avec des champs à calculer plus nombreux (contrôle d'erreur, etc), sans compter le mode connecté. Sur un réseau fiable, UDP diminue l'overhead et devrait être "plus rapide".

----------

## _kal_

 *El_Goretto wrote:*   

>  *anigel wrote:*    *El_Goretto wrote:*   [*]utiliser UDP (lien réseau fiable) 
> 
> Je suis loin d'être un pro de NFS, mais il me semble que pour un débit soutenu, et des performances optimales, TCP est plus indiqué ? 
> 
> A priori non.
> ...

 

Je suis du même avis mais je crois (pas sur) que puisque UDP ne vérifie pas les trames, alors la vérification se fait de manière logicielle, non ?   :Wink: 

----------

## El_Goretto

 *_kal_ wrote:*   

> Je suis du même avis mais je crois (pas sur) que puisque UDP ne vérifie pas les trames, alors la vérification se fait de manière logicielle, non ?  

 

Ah? Et par qui?  :Smile: 

Je n'ai pas vu d'info comme quoi NFS se mangeait du travail supplémentaire de vérification en UDP (le mode de fonctionnement historique), ceci dit, j'ai lu que les docs d'optimisation alors... (aucune indication supplémentaire ici)

----------

## _kal_

 *El_Goretto wrote:*   

>  *_kal_ wrote:*   Je suis du même avis mais je crois (pas sur) que puisque UDP ne vérifie pas les trames, alors la vérification se fait de manière logicielle, non ?   
> 
> Ah? Et par qui? 
> 
> Je n'ai pas vu d'info comme quoi NFS se mangeait du travail supplémentaire de vérification en UDP (le mode de fonctionnement historique), ceci dit, j'ai lu que les docs d'optimisation alors... (aucune indication supplémentaire ici)

 

Bah moi j'avais cru lire ca quelque part : TCP fait la verification de manière hardware alors que UDP s'en occupe de manière logicielle mais ce n'est pas obligatoire. Tu peux utiliser UDP sans verification logicielle, mais je sais pas si NFS le permet ou l'oblige  :Wink: 

----------

## El_Goretto

 *_kal_ wrote:*   

> Bah moi j'avais cru lire ca quelque part : TCP fait la verification de manière hardware alors que UDP s'en occupe de manière logicielle mais ce n'est pas obligatoire. Tu peux utiliser UDP sans verification logicielle, mais je sais pas si NFS le permet ou l'oblige 

 

Ca m'interesse si tu retrouves çà, parce que je comprends pas ce qui est sous-entendu par TCP et sa vérification calculée "matériellement" (numéros de séquence? checksums? etc, bref, les en-têtes, "matériellement" voulant dire en interne par le protocole?) et UDP dont la sienne serait "logicielle" (l'unique checksum UDP est désactivable, mais je vois pas en quoi "logicielle"... Sinon ca voudrait dire peut être une vérification "externe", mais donc UDP n'aurait plus rien à voir là dedans.)

Tu m'embrouilles là  :Smile: 

----------

## Poischack

Je comprends ce que _kal_ veut dire:TCP fait le controle des en-tête au niveau de ala carte réseaux, UDP non, donc certains logiciels  controle eux-même les informations reçues (signature des messages, ...) mais c'est absolument pas nécessaire.

----------

## El_Goretto

 *Poischack wrote:*   

> Je comprends ce que _kal_ veut dire:TCP fait le controle des en-tête au niveau de ala carte réseaux, UDP non, donc certains logiciels  controle eux-même les informations reçues (signature des messages, ...) mais c'est absolument pas nécessaire.

 

Mmmm, je me gourre peut être, mais je trouve bizarre qu'une carte réseau calcule le contenu des en-têtes TCP "de façon matérielle". Alors je vais peut être apprendre un truc aujourd hui et me coucher moins bête ce soir  :Smile: 

Ceci dit, qu'une carte éthernet calcule des données pour une protocole de haut niveau, j'ai des doutes. Déjà, je ne sais même pas si une carte ethernet calcule "en hard" quoi que ce soit pour les en têtes ethernet (vu qu'au besoin on en fait ce qu'on veut de ces en-tête en userspace).

Waiting for data  :Smile: 

----------

## Poischack

En fait en me relisant: je dis bcp de betises.

Non c'est pas la carte réseaux qui calcule ça (dsl)

----------

## _kal_

Bah en fait, lors d'un transfert en TCP, il y a certain bit de la trame qui constituent le checksum. A l'arrivé, on fait le checksum de la trame, et on compare au checksum recu. Voilà je crois que c'est ca  :Wink: 

Source : http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader.htm

----------

## El_Goretto

UDP a le même type de mécanisme (checksum aussi), et c'est le seul qu'il ait.

Pour rappel, TCP a d'autres systèmes de vérification (ordre d'arrivé des trames, aquitement des trames, etc).

--

edit:

ah oui, j'ai une vraie question sur NFS: je ne comprends pas le système multi-serveurs de NFS, qui en lance 8 par défaut. En quoi est-ce intéressant? Si c'est pour répartir de la charge CPU sur un multi-proc, c'est louche vu le nombre, si c'est pour une histoire de charge réseau, je ne vois pas en quoi plusieurs processus seront plus costauds qu'un seul (à part du point de vue du nombre de requêtes à traiter (et encore), et pas leur conséquence en terme de charge en bande passante).

----------

## guilc

 *Poischack wrote:*   

> En fait en me relisant: je dis bcp de betises.
> 
> Non c'est pas la carte réseaux qui calcule ça (dsl)

 

Bah en fait, sur les vraies bonnes cartes réseau, si, y a du calcul délégué par le kernel a la carte réseau, parceque ces cartes ont un petit proc. Mais bon, faut taper dans du 3Com haut de gamme pour ça  :Very Happy: 

----------

## Poischack

J'ai eu peur de dire une grosse connerie  :Smile: 

Mais c'est bien ce que j'avais entendu.

----------

## anigel

En fait je tenais mes infos... de la doc du kernel directement.

```
CONFIG_NFSD_TCP:

If you want your NFS server to support TCP connections, say Y here.

TCP connections usually perform better than the default UDP when

the network is lossy or congested.  If unsure, say Y.
```

Dans ce cas précis, d'après ce que j'ai lu, le réseau n'est pas "lossy", mais bien "congested" (grosse charge) ?

----------

## El_Goretto

 *anigel wrote:*   

> En fait je tenais mes infos... de la doc du kernel directement.
> 
> ```
> CONFIG_NFSD_TCP:
> 
> ...

 

Moi ce que j'en comprends, c'est que c'est une situation valable quand le réseau est congestionné (sisi c'est français, essayez avec un rhume pour voir). En effet, TCP joue son rôle de régulation des flux lorsque la bande passante est insuffisante, alors qu'UDP n'a pas de mécanisme de régulation.

Or, dans un réseau 1 Gbit, ça va, le plafond théorique est loin d'être atteint par un seul disque physique en NFS même si j'y ajoute un ADSL2+.

----------

## anigel

Bon bon, alors c'est moi qui avait mal compris ta problématique. J'avais retenu que tu avais un fort traffic entre ces 2 machines, et que donc tu cherchais à avoir la lisaison la plus fiable et efficace possible (cf ta première phrase, en haut de ce thread).

----------

## guilc

 *anigel wrote:*   

> Bon bon, alors c'est moi qui avait mal compris ta problématique. J'avais retenu que tu avais un fort traffic entre ces 2 machines, et que donc tu cherchais à avoir la lisaison la plus fiable et efficace possible (cf ta première phrase, en haut de ce thread).

 

A mon avis, le problème de réseau congestionné, c'est pas quand on a seulement 2 machines entre elles, mais une machine qui sert plusieurs machines en concurrence, ou plusieurs machines qui utilisent la même liaison.

----------

## fabienZ

Salut,

As tu essayé de modifier les valeurs de "/proc/sys/net/core/rmem_default" et "/proc/sys/net/core/rmem_max" tel qu'ils en parle dans un de tes howto ?

http://www.tldp.org/HOWTO/NFS-HOWTO/performance.html#MEMLIMITS

Sinon, mais cela ne te conviendra peut être pas, tu peux essayer de changer ton filesystem pour un plus performant comme xfs   :Wink: 

Tiens, pendant que j'y suis, quand j'essaie de passer le mtu de mes cartes réseau au dessus de 1500, ça ne fonctionne pas. par contre, jusqu'a 1500, ça roule.

```
ifconfig eth0 mtu 1501

SIOCSIFMTU: Argument invalide
```

A quoi cela peut il être dû ?

----------

## DomiX

Salut,

 *fabienZ wrote:*   

> 
> 
> ```
> ifconfig eth0 mtu 1501
> 
> ...

 

Le paramètre mtu sur de l'ethernet est de 1500 pas plus.

http://www.rfc-editor.org/rfc/rfc1191.txt

Bye

----------

## El_Goretto

+1

Les jumbo frames sont supportés en gigabit, pas en 10/100.

@fabienZ: oui, c'est ce que j'entendais par les buffers TCP/IP.

----------

