check massif de getattr via nfs

Le
admini
salut la liste

j'ai un comportement très bizzare d'un partage nfs.

client et serveur sont sous 7.5
client 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u1
server nfs 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2

fstab du client: server:/partage mount_point nfs4
_netdev,auto,soft,noac 0 0

exportfs du server: partage
*(sync,nohide,insecure,no_all_squash,rw,no_subtree_check)

lorsqu'on se log en ssh sur le client NFS, il des checks du type getattr
via NFS au serveur, et le serveur lui répond avec les droits d'accès.
c'est quand meme 9500 paquets réseaux qui transitent chaque fois qu'une
session ssh s'ouvre. c'est pas bien grave sur un réseaux gigabit, c'est
une latence de 4 secondes, mais c'est très très handicapant lorsqu'il y
a beaucoup de petits fichiers dans les répertoires profonds à checker et
qu'il y a des applicatifs qui y accèdent tout le temps, avec des comptes
applicatifs qui s'authentifient et qui lancent des daemons. on sent bien
la latence applicative.

auriez vous une idée?

d'avance merci.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54102188.8090003@freeatome.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain L. Sauvage
Le #26307785
’lut,

Le mercredi 10 septembre 2014, 12:01:44 admini a écrit :
[…]
lorsqu'on se log en ssh sur le client NFS, il des checks du
type getattr via NFS au serveur, […]



1. Est-ce que tu as les mêmes demandes avec un login local ?

2. Qu’est-ce qui est fait au login ? (Est-ce qu’il n⠀™y a pas un
truc qui scanne les répertoires qui sont en NFS ? Pour prépa rer
un cache des fichiers p.ex.)

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
admini
Le #26307784
Le 10/09/2014 12:20, Sylvain L. Sauvage a écrit :
’lut,

Le mercredi 10 septembre 2014, 12:01:44 admini a écrit :
[…]
lorsqu'on se log en ssh sur le client NFS, il des checks du
type getattr via NFS au serveur, […]


1. Est-ce que tu as les mêmes demandes avec un login local ?


ouai

2. Qu’est-ce qui est fait au login ? (Est-ce qu’il n’y a pas un
truc qui scanne les répertoires qui sont en NFS ? Pour préparer
un cache des fichiers p.ex.)


ben, oui. j'ai trouvé un truc intéressant: dans les bash profile des
devs, il parse des classe java en nfs. donc, ca cause beaucoup de
getattr pour les droits d'accès.
j'aimerais bien trouver un moyen d'optimiser ce trafics en jouant sur
des options du genre actimeo ou autres mais j'ai du mal. on ne peut pas
toucher à jumbo frame à cause de vieux switch qui ne le supporte pas.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Sylvain L. Sauvage
Le #26307834
Le mercredi 10 septembre 2014, 12:40:59 admini a écrit :
[…]
> 2. Qu’est-ce qui est fait au login ? (Est-ce qu’il n’y a
> pas un truc qui scanne les répertoires qui sont en NFS ?
> Pour préparer un cache des fichiers p.ex.)

ben, oui. j'ai trouvé un truc intéressant: dans les bash
profile des devs, il parse des classe java en nfs. donc, ca
cause beaucoup de getattr pour les droits d'accès.
j'aimerais bien trouver un moyen d'optimiser ce trafics en
jouant sur des options du genre actimeo ou autres mais j'ai
du mal.



Euh, t’as vu que t’avais noac dans le fstab du client ?!

Sinon, s’ils se plaignent, « il suffit » de leur ex pliquer que
parser des données sur NFS, c’est long. La latence du rà ©seau est
forcément plus longue que celle de leur SSD ;o)

on ne peut pas toucher à jumbo frame à cause de vieux
switch qui ne le supporte pas.



Bah, de toute façon, ton problème, c’est le nombre de
requêtes, par leur taille.

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
admini
Le #26308006
Le 10/09/2014 12:01, admini a écrit :
salut la liste

j'ai un comportement très bizzare d'un partage nfs.

client et serveur sont sous 7.5
client 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u1
server nfs 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2

fstab du client: server:/partage mount_point nfs4
_netdev,auto,soft,noac 0 0

exportfs du server: partage
*(sync,nohide,insecure,no_all_squash,rw,no_subtree_check)

lorsqu'on se log en ssh sur le client NFS, il des checks du type
getattr via NFS au serveur, et le serveur lui répond avec les droits
d'accès. c'est quand meme 9500 paquets réseaux qui transitent chaque
fois qu'une session ssh s'ouvre. c'est pas bien grave sur un réseaux
gigabit, c'est une latence de 4 secondes, mais c'est très très
handicapant lorsqu'il y a beaucoup de petits fichiers dans les
répertoires profonds à checker et qu'il y a des applicatifs qui y
accèdent tout le temps, avec des comptes applicatifs qui
s'authentifient et qui lancent des daemons. on sent bien la latence
applicative.

auriez vous une idée?

d'avance merci.




bon ben, je me réponds un peu à moi même, une demie solution a été
trouvée. dans le mountage de nfs, j'avais mis noac pour, en gros,
réduire la consomation de la RAM, car nfs n'utilise pas sa cache pour la
attributs. en le remettant, la cache est réactivée, mais la consomation
de la ram monte, au profit du trafic réseaux qui diminue à partir du
2ieme authentification. ca m'arrange car un compte applicatif se
connecte toutes les 2 minutes ( c'est débile, mais c'est le dev qui a
pondu le truc). je continue à cherche une amélioration, et vous tiens au
courant de l'avancement.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
admini
Le #26308005
bon ben, je me réponds un peu à moi même, une demie solution a été
trouvée. dans le mountage de nfs, j'avais mis noac pour, en gros,
réduire la consomation de la RAM, car nfs n'utilise pas sa cache pour la
attributs. ##########en le remettant##############

erratum, je l'ai pas remis, mais je l'ai viré.




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
admini
Le #26308292
Le 10/09/2014 12:01, admini a écrit :
salut la liste

j'ai un comportement très bizzare d'un partage nfs.

client et serveur sont sous 7.5
client 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u1
server nfs 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2

fstab du client: server:/partage mount_point nfs4
_netdev,auto,soft,noac 0 0

exportfs du server: partage
*(sync,nohide,insecure,no_all_squash,rw,no_subtree_check)

lorsqu'on se log en ssh sur le client NFS, il des checks du type
getattr via NFS au serveur, et le serveur lui répond avec les droits
d'accès. c'est quand meme 9500 paquets réseaux qui transitent chaque
fois qu'une session ssh s'ouvre. c'est pas bien grave sur un réseaux
gigabit, c'est une latence de 4 secondes, mais c'est très très
handicapant lorsqu'il y a beaucoup de petits fichiers dans les
répertoires profonds à checker et qu'il y a des applicatifs qui y
accèdent tout le temps, avec des comptes applicatifs qui
s'authentifient et qui lancent des daemons. on sent bien la latence
applicative.

auriez vous une idée?

d'avance merci.




bon alors, j'ai avancé un peu. et de temps en temps, il me sort des
kernel lock (hard reboot, berk),
je remarque, dès que c'est en udp, il me fait un kernel lock
[<ffffffff810b4ec3>] ? lock_page+0x20/0x20
[<ffffffff8134ea71>] ? io_schedule+0x59/0x71

en tcp, ca passe. étrange.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Publicité
Poster une réponse
Anonyme