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
--
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/2511461.1TRNE7aotK@earendil
-- 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 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/
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54102ABB.2060708@freeatome.com
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/
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/1572504.2sZFaiXR0T@earendil
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 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/
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54115164.5010907@freeatome.com
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
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/
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/5411522E.5010503@freeatome.com
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 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/
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/5412BEE1.3070606@freeatome.com
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/
