Aller au contenu

Problème de débit en NFS


Messages recommandés

Bonjour,

Voila ma configuration :

Serveur : Debian lenny ; nfs-kernel ; aucune option particulière dans le fichier de config NFS.

2 disques durs avec un débit soutenu de 70 mo environ en lecture + réseau gigabit entre les PC.

Client : mandriva 2008.1, avec les options de montage NFS de Mandriva - taille lecture et écriture 8192 de tête )

pour faire ceci :

debian disque dur n°1 --> NFS --> Mandriva -->NFS --> debian disque dur n°2 ( soit l'équivalent d'un copier coller de fichier à partir d'un explorateur de fichier sous mandriva entre 2 répertoire NFS du serveur ) , débit est de 20 Mo / s.

Par contre si je fais un simple cp directement sur le serveur, j'arrive à au moins 60 mo /s.

Avez -vous avez une bonne configuration de fichier de conf pour NFS du côté serveur et client ???

j'ai lu un truc au sujet des transferts asynchrone pour l'écriture ... ça fonctionne sous Linux ??

que dois-je mettre ....??

je vais faire plus de tests ( ftp / samba / nfs ) pour comparer ... mais NFS était bon dernier du lot :keskidit:

Lien vers le commentaire
Partager sur d’autres sites

/home 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check,insecure)

voila ce que j'ai dans /etc/export

ne fouillant un peu, si je met async et no_sbtree_chech à la place de mes options ça devrait être mieux.. :keskidit:

je testerai demain... :chinois:

Lien vers le commentaire
Partager sur d’autres sites

J'ai déjà eu le cas, eu j'ai eu beau changer les paramètres de buffer et cie, la seule solution que j'ai trouvé a été de passer en iScsi... oui je sais, ce n'est pas forcément possible...

si quelqu'un a une bonne doc sur le tuning NFS, je suis également preneur :francais:

Lien vers le commentaire
Partager sur d’autres sites

bon j'ai testé un peu toute les options :fume:

le problème est bien sur l'interconnexion entre nfs--kernel--serveur et l'accès au disque.. :D

En effet, si je je commence le tranfert d'un gros fichier de 3 ou 4 giga , ça sature à 30 mo /s maintenant avec l'option asyns et no subtree :chinois: .

si je coupe au milieu et que je relance le même transfert, une partie du fichier est donc déja en cache, et plus d'accès disue pour la lecture..

et la ça plafonne à 60 mo /s soit l'équivalent de la vitesse d'écriture de mon disue sur mon pc client :chinois:

rsize ne change rien même avec des grosses valeurs, et même en forçont en nfs 3 ça change rien.

Par contre il seblerait qu'en baissant le nombre de démons nfsd ( je suis passé de 8 à 4 et à 2 ) , ça tourne beaucioup mieux :ouioui: .

Vuq eu ej susi monoutilisateur du nfs , je vais le mettre à 4.

voila. donc résultat --> 30 mo/s environ en nfs, 60 mo/s en local, et idem en FTP.

tants pis on fera avec :craint:

Lien vers le commentaire
Partager sur d’autres sites

Simple remarque : quand tu fais un cp, tu ne passes pas par le client. C'est directement de disque à disque. Donc, tu profites du débit du SATA de 60Mos

Par contre, quand tu fais ça via nfs, les paquets transitent par ton client avant de repartir vers ton PC. Tu es donc bridé par le réseau. Personnellement, je bridais à 11,4Mos en cifs sur une ligne 100MBps.

Pour moi tes chiffres sont normaux :D

LSP, le manchot qui a ptêt pas tout suivi

Lien vers le commentaire
Partager sur d’autres sites

Normalement sur du Gigabit la limite théorique tourne dans les 120Mo/s.

Après il peut y avoir une limite au niveau du driver lui-même et du débit brut, pour ça un test iperf peut se révéler utile (en tcp et en udp). Ce qui va déjà permettre de voir si le réseau limite fortement ou pas.

Après y'a le protocole qui passe par dessus, ça, ça peut se tester avec des protocoles plus simple que du NFS, comme du ftp (éventuellement du http et du cifs pour confirmer les valeurs). En fonction de ces résultats, si le NFS est beaucoup moins performant il faudra voir si y'a moyen de savoir d'où ça vient (utilisation CPU? mauvais paramétrage?)

Enfin voilà quelques idées, j'ai vu que tu avais testé en FTP, tu confirmes que ça fait bien du 60Mo/s?

Lien vers le commentaire
Partager sur d’autres sites

Normalement sur du Gigabit la limite théorique tourne dans les 120Mo/s.

Après il peut y avoir une limite au niveau du driver lui-même et du débit brut, pour ça un test iperf peut se révéler utile (en tcp et en udp). Ce qui va déjà permettre de voir si le réseau limite fortement ou pas.

Après y'a le protocole qui passe par dessus, ça, ça peut se tester avec des protocoles plus simple que du NFS, comme du ftp (éventuellement du http et du cifs pour confirmer les valeurs). En fonction de ces résultats, si le NFS est beaucoup moins performant il faudra voir si y'a moyen de savoir d'où ça vient (utilisation CPU? mauvais paramétrage?)

Enfin voilà quelques idées, j'ai vu que tu avais testé en FTP, tu confirmes que ça fait bien du 60Mo/s?

Bon je vais commencer par donner des réponses avec les données que j'ai

Pour iperf, voila le résultat :

Client connecting to 192.168.1.100, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 192.168.1.30 port 38731 connected with 192.168.1.100 port 5001

[ 3] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec

c'est marrant, dans la fenetre de gkrellm, mon moniteur system , ça sature à 120 mo/s :transpi: ( tiens bizarre , Tuxx avait vu juste LOL )

utilisation cpu : 30 % d'un des 2 core de mon pentium e2160 lors du transfert :transpi:

donc pas de problème du côté réseau :keskidit:

Edit : Je vous écrit depuis une fedora core 9 . 2 h de galère pour monter les lecteurs NFS au boot :pleure:

Lien vers le commentaire
Partager sur d’autres sites

pour le ftp du serveur vers mon pc client

226 Transfer complete.

8532505905 bytes received in 170 secs (50310,85 Kbytes/sec)

ftp>

donc environ 49 mo /s si je ne me trompe pas ( mon dur en local saturait )

donc cela correspond à l'écriture sur mon disqur local.

Lien vers le commentaire
Partager sur d’autres sites

J'avais chnagé le nombre de démon de nfs ( j'avais laissé que 2 )

donc le tauc d'occupation en lecture nfs sur le serbveur : 2 x 28 % ( de chaque core ) sachantq eu le total fait 200 % :francais:

403 root 20 0 0 0 0 D 280.0 1:58.49 nfsd

404 root 20 0 0 0 0 D 280.0 1:58.60 nfsd

4325 mldonkey 20 0 89508 75m 5600 S 13 3.8 500:11.96 mlnet

206 root 15 -5 0 0 0 S 2 0.0 1:08.28 kswapd0

43 root 15 -5 0 0 0 S 1 0.0 0:04.60 kblockd/0

3817 root 20 0 18496 1048 788 S 0 0.1 6:38.78 cpufreqd

5885 alexandr 20 0 29204 10m 7428 S 0 0.5 0:04.20 gkrellm

le même fichier que précédement qui fait 7.9 Go a été tranféré en ----> 2 minute 48 s ( chronométre avec le telephone :chinois: ) soit 170 secondes ..... :p

soit le même temps qu'avec le FTP :francais:

c'est peut être l'effet fedora

Lien vers le commentaire
Partager sur d’autres sites

copie d'un disque nfs sur un autre disque nfs

403 root 20 0 0 0 0 R 44 0.0 3:21.69 nfsd

404 root 20 0 0 0 0 S 41 0.0 3:21.71 nfsd

3minutes 45 seconde..

nautilus annoncé environ 35.8 Mo /s

copie du disue local vers le serveur

404 root 20 0 0 0 0 R 40 0.0 4:51.56 nfsd

403 root 20 0 0 0 0 R 40 0.0 4:49.90 nfsd

2 minutes 24 s soit 144 s --> 56.4mo /s ( doit être la vitesse max d'écritude du disue du serveur ou plutôt la vitesse max de lecture du disque client :francais: )

La conclusion :

en écriture c'est ok.

en lecture c'est ok.

en lecture écriture simultané --> chutre de performance.

soit c'est le nfs qui aime pas ça, ou amors ca a du mal a faire du full duplex au dessus de 35 mo /s

Lien vers le commentaire
Partager sur d’autres sites

lecture/écriture, ça me paraît normal que ça baisse : tu fait faire plein d'aller-retours à la tête, surtout sur un gros fichier, non ?

en fait , il y a 3 disques dur sur le serveur de 750 Go :keskidit:

lors de mon transfert, il copie les fichiers d'un disque sur l'autre:

en gros :

lecture disque dur n°1 serveur --> nfs serveur -->réseau --> nfs client --> réseau --> nfs serveur --> ecriture disque n°2 serveur = 35 mo /s

ce qui revient en fait à la même chose que ça :

ecture disque dur n°1 serveur --> cp local --> ecriture disque n°2 serveur = 60 mo /s

je fais faire me même tets avec du ftp .... pour voir ce que ça donne ... ( heu ..... semi ftp peut être ... )

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...