Bonjour, Après une semaine de recherches, je me résous à appeler à l'aide : j'ai un sérieux soucis de performances sur du NFS.
Pour planter le décor : Un filer, avec des performances en écritures 'correctes' : # sync && date && dd if=/dev/zero of=test.raw count=2000000 && date && sync && date mercredi 12 janvier 2011, 17:55:01 (UTC+0100) 1024000000 octets (1,0 GB) copiés, 4,98119 seconde, 206 MB/s mercredi 12 janvier 2011, 17:55:06 (UTC+0100) mercredi 12 janvier 2011, 17:55:22 (UTC+0100)
Je note déjà qu'il se passe 16 secondes juste pour le 'sync' de la fin, à voir. C'est du RAID5 sur une carte Adaptec 3405 mais sans BBU (et donc sans write-cache).
iperf me donne un réseau qui, à première vue, marche bien : [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.06 GBytes 912 Mbits/sec 900 Mb/s sur un lien giga, ok.
Maintenant, ce qui me chiffonne, c'est que les perfs en écriture depuis le même client sont CA TA STRO PHIQUES : # sync && date && dd if=/dev/zero of=test.raw count=2000 && date && sync && date mercredi 12 janvier 2011, 17:57:31 (UTC+0100) 1024000 octets (1,0 MB) copi�s, 27,2681 seconde, 37,6 kB/s mercredi 12 janvier 2011, 17:57:58 (UTC+0100) mercredi 12 janvier 2011, 17:57:58 (UTC+0100)
même pas 40 ko/s ??? (la taille du fichier est volontairement réduite)
au niveau des options de montage du partage NFS : rw,sync,noatime,nodiratime,rsize=8192,wsize=8192,tcp,nfsvers=3
Et j'ai un nombre plutôt importants de threads NFS : RPCNFSDCOUNT=128
Le MTU est 1500 (un bug driver sur le filer m'empêche de le changer pour le moment). Pas de routeur entre les deux, juste un switch.
J'ai essayé pas mal de choses : wsize variable (de 1k à 16k), udp au lieu de tcp, sync/async.
Alors, le filer est monté sur une quinzaine de machines mais ca ne devrait pas avoir une incidence pareille non ? Je précise que les perfs sont les mêmes sur tous les clients, ce qui me fait penser à un problème côté serveur.
Bref, si vous avez une piste, je prend tout !
Merci et bonne soirée, Julien
On Wed, Jan 12 2011, Julien Escario wrote:
Pour planter le décor : Un filer, avec des performances en écritures 'correctes' : # sync && date && dd if=/dev/zero of=test.raw count=2000000 && date && sync && date mercredi 12 janvier 2011, 17:55:01 (UTC+0100) 1024000000 octets (1,0 GB) copiés, 4,98119 seconde, 206 MB/s mercredi 12 janvier 2011, 17:55:06 (UTC+0100) mercredi 12 janvier 2011, 17:55:22 (UTC+0100)
Je note déjà qu'il se passe 16 secondes juste pour le 'sync' de la fin, à voir.
Rajoute conv=sync à dd pour ne pas à avoir à faire le sync final, ce qui te donnera des chiffres plus près de la réalité.
Bref, si vous avez une piste, je prend tout !
tcpdump/wireshark, sinon NFSv4.
Le 12/01/2011 18:21, Julien Danjou a écrit :
Rajoute conv=sync à dd pour ne pas à avoir à faire le sync final, ce qui te donnera des chiffres plus près de la réalité.
C'est kifkif sur une fichier de 1 Go. Par contre, je me suis dit que les résultats étaient peut être faussés puisque 1Go, ca tient en cache. Avec un fichier de 10 Go, c'est déjà nettement moins glop : # sync && date && dd if=/dev/zero of=test.raw count=20000000 conv=sync && date mercredi 12 janvier 2011, 18:26:30 (UTC+0100) 10240000000 octets (10 GB) copiés, 168,379 seconde, 60,8 MB/s mercredi 12 janvier 2011, 18:29:21 (UTC+0100)
Je m'attendais quand même à mieux, passons.
Bref, si vous avez une piste, je prend tout !
tcpdump/wireshark, sinon NFSv4.
OK, mais je cherche quoi ? Tout le trafic entre le serveur et le client ? Au moment d'un dd ?
Merci, Julien
On Wed, Jan 12 2011, Julien Escario wrote:
tcpdump/wireshark, sinon NFSv4.
OK, mais je cherche quoi ? Tout le trafic entre le serveur et le client ? Au moment d'un dd ?
Normalement wireshark est assez intelligent pour comprendre le protocole NFS et te le montrer de manière human-readable, donc tu devrais voir les appels RPC passés avec un timestamp. Ca peut t'aider à voir pourquoi c'est si lent.
2011/1/12 Julien Escario escario@azylog.net:
Bonjour, Après une semaine de recherches, je me résous à appeler à l'aide : j'ai un sérieux soucis de performances sur du NFS.
[...]
C'est quoi le l'OS du Filer et l'OS du client (quelles versions etc)
Youssef Ghorbal
Le 12/01/2011 19:24, Youssef Ghorbal a écrit :
2011/1/12 Julien Escarioescario@azylog.net:
Bonjour, Après une semaine de recherches, je me résous à appeler à l'aide : j'ai un sérieux soucis de performances sur du NFS.
[...]
C'est quoi le l'OS du Filer et l'OS du client (quelles versions etc)
Côté filer : Linux ron 2.6.18-6-686 #1 SMP Thu Nov 5 16:28:13 UTC 2009 i686 GNU/Linux
Sur le client : Linux cho 2.6.26-2-amd64 #1 SMP Thu Sep 16 21:20:20 UTC 2010 x86_64 GNU/Linux
Julien
2011/1/12 Julien Escario escario@azylog.net:
Le 12/01/2011 19:24, Youssef Ghorbal a écrit :
2011/1/12 Julien Escarioescario@azylog.net:
Bonjour, Après une semaine de recherches, je me résous à appeler à l'aide : j'ai un sérieux soucis de performances sur du NFS.
[...]
C'est quoi le l'OS du Filer et l'OS du client (quelles versions etc)
Côté filer : Linux ron 2.6.18-6-686 #1 SMP Thu Nov 5 16:28:13 UTC 2009 i686 GNU/Linux
Sur le client : Linux cho 2.6.26-2-amd64 #1 SMP Thu Sep 16 21:20:20 UTC 2010 x86_64 GNU/Linux
Nous avons eu un probleme de perfs avec le client NFS sous CentOS 5. Ca ete resolu avec l'option de montage actimeo=1. Je crois que par defaut il etait a 0 (pas d'attribute caching)
Youssef Ghorbal
Bonjour, Après une semaine de recherches, je me résous à appeler à l'aide : j'ai un sérieux soucis de performances sur du NFS.
A mon avis, avant toute chose, regarde du coté de ton switch et coté serveur si tu n'as pas un problème de mode (mauvaise négociation genre half/full duplex ou Gb/s d'un coté FE de l'autre, etc...)
amicalement,
Le 12/01/2011 19:25, christophe.casalegno@digital-network.net a écrit :
Bonjour, Après une semaine de recherches, je me résous à appeler à l'aide : j'ai un sérieux soucis de performances sur du NFS.
A mon avis, avant toute chose, regarde du coté de ton switch et coté serveur si tu n'as pas un problème de mode (mauvaise négociation genre half/full duplex ou Gb/s d'un coté FE de l'autre, etc...)
Ca a été vérifié : les deux serveurs (et le swtich confirme) : c'est bien du giga full duplex.
Julien
A mon avis, avant toute chose, regarde du coté de ton switch et coté serveur si tu n'as pas un problème de mode (mauvaise négociation genre half/full duplex ou Gb/s d'un coté FE de l'autre, etc...)
Ca a été vérifié : les deux serveurs (et le swtich confirme) : c'est bien du giga full duplex.
C'est un switch manageable ou non manageable ?
amicalement,
Le 12/01/2011 20:52, christophe.casalegno@digital-network.net a écrit :
A mon avis, avant toute chose, regarde du coté de ton switch et coté serveur si tu n'as pas un problème de mode (mauvaise négociation genre half/full duplex ou Gb/s d'un coté FE de l'autre, etc...)
Ca a été vérifié : les deux serveurs (et le swtich confirme) : c'est bien du giga full duplex.
C'est un switch manageable ou non manageable ?
Manageable L3. Netgear FSM7328S.
Julien
Le 12/01/2011 20:55, christophe.casalegno@digital-network.net a écrit :
C'est un switch manageable ou non manageable ?
Manageable L3. Netgear FSM7328S.
Ok, et sur l'interface du switch il n'indique aucune erreurs de paquets sur les ports ?
Pas une colision, pas une erreur. Merci pour la piste.
Julien
On 12/01, Julien Escario wrote:
Et j'ai un nombre plutôt importants de threads NFS : RPCNFSDCOUNT=128
Ça ne fait pas un peu trop ? Ici nous avons constaté des grosses baisses de performance sous forte charge si on augmente trop le nombre de threads. Pour trouver la valeur optimale, il vaut mieux partir de peu et augmenter : nfsd râle quand il a trop de connexions ouvertes.
Le 12/01/2011 19:34, Cyril Bellot a écrit :
On 12/01, Julien Escario wrote:
Et j'ai un nombre plutôt importants de threads NFS : RPCNFSDCOUNT=128
Ça ne fait pas un peu trop ? Ici nous avons constaté des grosses baisses de performance sous forte charge si on augmente trop le nombre de threads. Pour trouver la valeur optimale, il vaut mieux partir de peu et augmenter : nfsd râle quand il a trop de connexions ouvertes.
J'avais justement un doute ... J'ai réduit à 32 et rien de mieux pour le moment.
Julien
On 12/01, Julien Escario wrote:
Le 12/01/2011 19:34, Cyril Bellot a écrit :
On 12/01, Julien Escario wrote:
Et j'ai un nombre plutôt importants de threads NFS : RPCNFSDCOUNT=128
Ça ne fait pas un peu trop ? Ici nous avons constaté des grosses baisses de performance sous forte charge si on augmente trop le nombre de threads. Pour trouver la valeur optimale, il vaut mieux partir de peu et augmenter : nfsd râle quand il a trop de connexions ouvertes.
J'avais justement un doute ... J'ai réduit à 32 et rien de mieux pour le moment.
Nous n'avons jamais eu besoin de dépasser 16. Tu as déjà des messages dans tes logs du style : increase the number of threads ?
Commence peut-être par regarder la charge et les IOs (iostat -x 3) du côté serveur pour voir si ton device est au taquet ou non quand c'est lent; s'il ne l'est pas, laisse tourner nfsstat pour voir le type d'opérations qui te prennent de la ressource
Le 12/01/2011 21:11, Cyril Bellot a écrit :
On 12/01, Julien Escario wrote:
Le 12/01/2011 19:34, Cyril Bellot a écrit :
On 12/01, Julien Escario wrote:
Et j'ai un nombre plutôt importants de threads NFS : RPCNFSDCOUNT=128
Ça ne fait pas un peu trop ? Ici nous avons constaté des grosses baisses de performance sous forte charge si on augmente trop le nombre de threads. Pour trouver la valeur optimale, il vaut mieux partir de peu et augmenter : nfsd râle quand il a trop de connexions ouvertes.
J'avais justement un doute ... J'ai réduit à 32 et rien de mieux pour le moment.
Nous n'avons jamais eu besoin de dépasser 16. Tu as déjà des messages dans tes logs du style : increase the number of threads ?
Ca ne me dit rien. Ce qui m'a fait augmenter le nombre de threads, c'est la ligne th dans /proc/net/rpc/nfsd Le dernier chiffre n'est pas zéro ;-)
Commence peut-être par regarder la charge et les IOs (iostat -x 3) du côté serveur pour voir si ton device est au taquet ou non quand c'est lent; s'il ne l'est pas, laisse tourner nfsstat pour voir le type d'opérations qui te prennent de la ressource
Alors précision : c'est toujours lent ... Par contre, les I/O sont quand même assez hautes, oui fréquemment autour de 40% et le premier iostat me donne un iowait à 29,46%.
C'est beaucoup non ? (je n'ai pas d'autre filer sous la main pour faire une comparaison).
Ceci dit, même si c'est élevé, je trouve étonnant que ca puisse dégrader les perfs à ce point là.
Julien
On 12/01, Julien Escario wrote:
Nous n'avons jamais eu besoin de dépasser 16. Tu as déjà des messages dans tes logs du style : increase the number of threads ?
Ca ne me dit rien. Ce qui m'a fait augmenter le nombre de threads, c'est la ligne th dans /proc/net/rpc/nfsd Le dernier chiffre n'est pas zéro ;-)
Ce n'est pas gênant que 100% des threads servent. Tant que le nfsd n'est pas en permanence à 100% d'utilisation de ses threads (un graph munin des sondes de bases est train bien fait pour suivre ça)
Commence peut-être par regarder la charge et les IOs (iostat -x 3) du côté serveur pour voir si ton device est au taquet ou non quand c'est lent; s'il ne l'est pas, laisse tourner nfsstat pour voir le type d'opérations qui te prennent de la ressource
Alors précision : c'est toujours lent ... Par contre, les I/O sont quand même assez hautes, oui fréquemment autour de 40% et le premier iostat me donne un iowait à 29,46%.
C'est beaucoup non ? (je n'ai pas d'autre filer sous la main pour faire une comparaison).
Ceci dit, même si c'est élevé, je trouve étonnant que ca puisse dégrader les perfs à ce point là.
À priori ce n'est pas ton matériel qui limite, sinon tu le verrais souvent à 100% (ça arrive aussi avec des drivers mal fait)
Regarde la répartition des IOs nfs. nfsstat donne aussi des mesures côté client.
Bonsoir,
Maintenant, ce qui me chiffonne, c'est que les perfs en écriture depuis le
même client sont CA TA STRO PHIQUES : # sync && date && dd if=/dev/zero of=test.raw count=2000 && date && sync && date mercredi 12 janvier 2011, 17:57:31 (UTC+0100) 1024000 octets (1,0 MB) copi�s, 27,2681 seconde, 37,6 kB/s mercredi 12 janvier 2011, 17:57:58 (UTC+0100) mercredi 12 janvier 2011, 17:57:58 (UTC+0100)
même pas 40 ko/s ??? (la taille du fichier est volontairement réduite)
Effectivement, tiens, regardes : # sync && date && dd if=/dev/zero of=test.raw count=20000 && date && sync && date Wed Jan 12 20:36:36 CET 2011 20000+0 records in 20000+0 records out 10240000 bytes (10 MB) copied, 0.267938 s, 38.2 MB/s Wed Jan 12 20:36:36 CET 2011 Wed Jan 12 20:36:36 CET 2011
Avec ces options de montage (NFSv4) : type nfs4 (rw,noexec,noatime,soft,timeo=30,retrans=1,noresvport,rsize=2048,wsize=2048)
Je ne pense pas que le problème soit lié à NFS, mais plutot à un problème réseau entre les 2 machines ?
Greg
Le 12/01/2011 20:43, Greg a écrit :
Bonsoir,
Maintenant, ce qui me chiffonne, c'est que les perfs en écriture depuis le même client sont CA TA STRO PHIQUES : # sync && date && dd if=/dev/zero of=test.raw count=2000 && date && sync && date mercredi 12 janvier 2011, 17:57:31 (UTC+0100) 1024000 octets (1,0 MB) copi�s, 27,2681 seconde, 37,6 kB/s mercredi 12 janvier 2011, 17:57:58 (UTC+0100) mercredi 12 janvier 2011, 17:57:58 (UTC+0100) même pas 40 ko/s ??? (la taille du fichier est volontairement réduite)Effectivement, tiens, regardes : # sync && date && dd if=/dev/zero of=test.raw count=20000 && date && sync && date Wed Jan 12 20:36:36 CET 2011 20000+0 records in 20000+0 records out 10240000 bytes (10 MB) copied, 0.267938 s, 38.2 MB/s Wed Jan 12 20:36:36 CET 2011 Wed Jan 12 20:36:36 CET 2011
Avec ces options de montage (NFSv4) : type nfs4 (rw,noexec,noatime,soft,timeo=30,retrans=1,noresvport,rsize=2048,wsize=2048)
Je ne pense pas que le problème soit lié à NFS, mais plutot à un problème réseau entre les 2 machines ?
Et pourtant, je n'avais encore jamais testé NFS4, ne m'étant pas documenté sur le protocole : # sync && date && dd if=/dev/zero of=test.raw count=5000000 conv=sync && date mercredi 12 janvier 2011, 21:51:13 (UTC+0100) 2560000000 octets (2,6 GB) copi�s, 180,434 seconde, 14,2 MB/s mercredi 12 janvier 2011, 21:54:15 (UTC+0100)
Juste en passant en version 4, impressionnant. Ca ne s'explique pas avec quelques optimisations dans le protocole. Il va falloir que je comprenne ce qui a changé fondamentalement entre NFS3 et NFS4.
En tout cas, j'ai gagné ma soirée : 46 000% de gain de perf en mettant 4 à la place de 3, je prend !
Merci à tous, Julien
-
christophe.casalegno＠digital-network.net -
Cyril Bellot -
Greg -
Julien Danjou -
Julien Escario -
Sylvain Rochet -
Youssef Ghorbal