Re: Station diskless et Debian testing

[BERTRAND Joël]

BOITEUX, Frederic a écrit :
>   Bonjour,
> 
>   Je crois que depuis Stretch, le protocole NFS est passé par défaut en TCP, 
> est-ce que tu as bien configuré ton accès NFS si tu veux accéder à un serveur 
> qui est toujours en UDP (j'imagine en NFSv3) ? Voir les options de mount, 
> comme « proto=udp » …

Bonsoir,

Tout est en TCP et en v3, client comme serveur. J'ai viré le lockd et
fait un rapport d'erreur sur le noyau. Avec un noyau plus ancien et la
même version de nfsd/lockd, ça ne provoque pas ce genre d'erreur sur le
serveur.

Bien cordialement,

JKB

RE: Station diskless et Debian testing

[BOITEUX, Frederic]

Bonjour,

  Je crois que depuis Stretch, le protocole NFS est passé par défaut en TCP, 
est-ce que tu as bien configuré ton accès NFS si tu veux accéder à un serveur 
qui est toujours en UDP (j'imagine en NFSv3) ? Voir les options de mount, comme 
« proto=udp » …

Cdlt,
Fred.

-Message d'origine-
De : BERTRAND Joël <joel.bertr...@systella.fr> 
Envoyé : samedi 28 avril 2018 18:30
À : debian-user-french@lists.debian.org
Objet : Re: Station diskless et Debian testing

Bonsoir à tous,

J'avance sur mon problème. Je viens de m'apercevoir que mon syslog est 
plein de lignes comme ceci :

Apr 28 17:35:23 hilbert kernel: [282745.749938] lockd: server
192.168.10.128 not responding, still trying Apr 28 17:35:23 hilbert kernel: 
[282745.749969] xs_tcp_setup_socket:
connect returned unhandled error -107
Apr 28 17:35:29 hilbert kernel: [282751.810082] lockd: server
192.168.10.128 OK
Apr 28 18:27:15 hilbert kernel: [285857.121396] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:27:15 hilbert kernel: 
[285857.373345] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:27:16 hilbert kernel: 
[285858.641114] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:27:25 hilbert kernel: 
[285866.965630] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:27:26 hilbert kernel: 
[285868.225678] lockd: server
192.168.10.128 not responding, still trying Apr 28 18:28:36 hilbert kernel: 
[285938.011610] lockd: server
192.168.10.128 OK
Apr 28 18:28:37 hilbert kernel: [285939.019589] lockd: server
192.168.10.128 OK
Apr 28 18:28:45 hilbert kernel: [285947.627997] lockd: server
192.168.10.128 OK
Apr 28 18:28:47 hilbert kernel: [285949.139779] lockd: server
192.168.10.128 OK

Il y a donc un truc qui casse au moins NFSv3 dans le noyau 4.15.17-1 de 
chez Debian. Je précise que lorsque je me prends ce genre d'erreur depuis mon 
poste de dev, toutes les autres machines diskess utilisant le même serveur 
(arm, x86 FreeBSD...) fonctionnement parfaitement. Je n'arrive pas à savoir si 
lockd par en timeout sur l'erreur 107 ou si c'est le contraire.

Bien cordialement,

JKB

This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.

Re: Station diskless et Debian testing

[BERTRAND Joël]

Bonsoir à tous,

J'avance sur mon problème. Je viens de m'apercevoir que mon syslog est
plein de lignes comme ceci :

Apr 28 17:35:23 hilbert kernel: [282745.749938] lockd: server
192.168.10.128 not responding, still trying
Apr 28 17:35:23 hilbert kernel: [282745.749969] xs_tcp_setup_socket:
connect returned unhandled error -107
Apr 28 17:35:29 hilbert kernel: [282751.810082] lockd: server
192.168.10.128 OK
Apr 28 18:27:15 hilbert kernel: [285857.121396] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:27:15 hilbert kernel: [285857.373345] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:27:16 hilbert kernel: [285858.641114] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:27:25 hilbert kernel: [285866.965630] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:27:26 hilbert kernel: [285868.225678] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:28:36 hilbert kernel: [285938.011610] lockd: server
192.168.10.128 OK
Apr 28 18:28:37 hilbert kernel: [285939.019589] lockd: server
192.168.10.128 OK
Apr 28 18:28:45 hilbert kernel: [285947.627997] lockd: server
192.168.10.128 OK
Apr 28 18:28:47 hilbert kernel: [285949.139779] lockd: server
192.168.10.128 OK

Il y a donc un truc qui casse au moins NFSv3 dans le noyau 4.15.17-1 de
chez Debian. Je précise que lorsque je me prends ce genre d'erreur
depuis mon poste de dev, toutes les autres machines diskess utilisant le
même serveur (arm, x86 FreeBSD...) fonctionnement parfaitement. Je
n'arrive pas à savoir si lockd par en timeout sur l'erreur 107 ou si
c'est le contraire.

Bien cordialement,

JKB

Re: Station diskless et Debian testing

[Étienne Mollier]

Joël Bertrand, le mercredi 18 avril 2018 :
> Étienne Mollier a écrit :
> > C'est toujours ça de pris.  Avec un peu de chance, désactiver
> > une tâche de fond du type à mettre à jour des caches pourrait
> > aider, typiquement mlocate/updatedb (m'enfin celui-ci n'est
> > censé ne tourner que quotidiennement par défaut, et n'était
> > probablement pas en train de tourner lors de vos essais).
>
>   C'est le premier truc que je désactive.

Okay...  :-)

>   C'est un peu délicat. De toute façon, je n'ai que NFSv2
> et v3 côté NetBSD. Il y a bien le code NEW_NFS qui est le NFS
> de FreeBSD dans le noyau, mais il n'est pas aisément compilable
> et dans un état incertain.  J'ai essayé de le compiler sans
> succès cet après-midi.
>
>   Quoi qu'il en soit, je pourrais forcer un NFSv2, mais je
> ne suis pas sûr que ça améliorera les choses...

Okay, je vois le tableau ; vers=3 c'est très bien en l'état.

>   Pour avoir continué mes essais, j'ai l'impression que le
> problème tourne autour de lockd. C'est lui qui semble partir en
> timeout.  Côté serveur, j'ai un tas de :
>
> Apr 17 12:28:01 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:01 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:01 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:02 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:02 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:04 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:04 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:05 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:05 legendre rpc.lockd: no matching entry for hilbert
> Apr 17 12:28:05 legendre rpc.lockd: duplicate lock from hilbert.2
> Apr 17 12:28:05 legendre rpc.lockd: no matching entry for hilbert
>
> que je n'avais pas avant. J'ai essayé de remonter la partition
> /home (puisque c'est celle qui semble poser problème) avec
> l'option nolock et je n'obtiens qu'un :
>
> root@hilbert:~# mount -o remount,rw,nolock /home
> mount.nfs: an incorrect mount option was specified

Rien dans la documentation de nfs(5) ne suggère que ces options
soient erronées.  Au pire, le "nolock" serait en contradiction
avec le "local_lock=none" déjà présent.  Mais dans ce cas, cette
première option aurait dû avoir préséance.

Soit il y a une subtilité qu'on a loupé, par exemple vis-à-vis
d'un montage NFS effectué dans un autre montage NFS côté client ;
soit il y a légitimement un bug dans le client (ou le serveur)
NFSv3 vis-à-vis du montage dans ce genre de situation.

>   Autre chose qui semble avoir changé. Mon fstab contient :
> 192.168.10.128:/srv/hilbert  /  nfs intr,tcp,nfsvers=3,async 0 0
> 192.168.10.128:/home /home  nfs intr,tcp,nfsvers=3,async 0 0
> /swapfile.0 noneswapsw  0   0
>
>   Pourtant, les montages sont reconnus par le système
> comme :
> root@hilbert:~# nfsstat -m
> / from 192.168.10.128:/srv/hilbert
>  Flags: 
> rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=7,retrans=10,sec=sys,local_lock=all,addr=192.168.10.128
>
> /home from 192.168.10.128:/home
>  Flags: 
> rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.10.128,mountvers=3,mountport=1020,mountproto=tcp,local_lock=none,addr=192.168.10.128
>
>   Je suppose que c'est encore un coup de la bouse systemd
> qui modifie les options puisque / est monté avec un nolock et
> /home avec un lock.

Je vois mal quoi rajouter, à part espérer que forcer "nolock" ou
bien "local_lock=all" aux options de montage des / et /home
directement dans le fichier fstab permette de contourner ce
problème, et révèle in fine si ces options silencieusement
passées étaient bien la cause des ralentissements.

En espérant que ça aide un peu quand même,
À plus,
-- 
Étienne Mollier 

Re: Station diskless et Debian testing

[BERTRAND Joël]

Étienne Mollier a écrit :
> Joël Bertrand, le mardi 17 avril 2018 :
>> Étienne Mollier a écrit :
>>> Si le problème se déclenche au lancement d'applications du
>>> type à manipuler du cache pour des raisons de performances
>>> (navigateurs web, java, etc), est-ce que diminuer, rediriger
>>> en local, ou supprimer ledit cache permettrait de diminuer
>>> l'ampleur des sautes d'humeur du poste de CAO ?
>>
>>  Les programmes incriminés sont principalement les
>> navigateurs web (seamonkey, firefox, chromium).  Pas d'autre
>> activité suspecte lorsque le problème survient.  J'ai forcé le
>> cache de seamonkey à 0.  Je ne suis pas sûr que cela arrange la
>> chose puisque durant les périodes fautives, il n'y a pas
>> d'activité nfs. Comme si Linux attendait quelque chose.  J'ai
>> aussi l'impression que le problème est survenu avec le noyau
>> 4.15 (je n'ai pas noté ce genre de problème auparavant sauf
>> lorsque la machine se mettait à swapper, mais tous les
>> programmes étaient impactés).
> 
>>  Un petit retour. J'ai désactivé le cache, ça améliore un
>> tout petit peu les choses. J'ai noté avec un tcpdump que des
>> requêtes NFS passaient lors des périodes où les applications
>> bloquaient, requêtes ayant des réponses normales (et à un débit
>> ridicule, quelques dizaines de kbps sur une réseau loin d'être
>> engorgé et avec un serveur qui fait les pieds au mur en même
>> temps). Lors de ces problèmes, aucun souci de résolution de nom
>> ou autre chose. Pas de problème de réseau non plus (j'ai un
>> vncviewer ouvert sur une machine distante qui continue à
>> fonctionner parfaitement). C'est un peu comme si le client NFS
>> mettait en cache des requêtes et oubliait de les envoyer...
> 
> Bonsoir,
> 
> C'est toujours ça de pris.  Avec un peu de chance, désactiver une
> tâche de fond du type à mettre à jour des caches pourrait aider,
> typiquement mlocate/updatedb (m'enfin celui-ci n'est censé ne
> tourner que quotidiennement par défaut, et n'était probablement
> pas en train de tourner lors de vos essais).

C'est le premier truc que je désactive.

> Du côté « correction du mal à la racine », le noyau 4.15 a
> effectivement vu des modifications de son client NFS, versions 3
> et 4, entre autres dans sa gestion des caches, depuis le noyau
> 4.14 :
> 
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/diff/fs/nfs/?id=v4.14=v4.15.16=2
> 
> À part dans nfs4proc.c, les changements ne donnent pas
> l'impression d'avoir été francs non plus.  La migration depuis
> refcount vers atomic est éventuellement suspecte.  Avez-vous la
> possibilité de tester les diverses versions de NFS pour voir si
> le problème se maintient d'une version à l'autre, ou bien c'est
> délicat ?

C'est un peu délicat. De toute façon, je n'ai que NFSv2 et v3 côté
NetBSD. Il y a bien le code NEW_NFS qui est le NFS de FreeBSD dans le
noyau, mais il n'est pas aisément compilable et dans un état incertain.
J'ai essayé de le compiler sans succès cet après-midi.

Quoi qu'il en soit, je pourrais forcer un NFSv2, mais je ne suis pas
sûr que ça améliorera les choses...

Pour avoir continué mes essais, j'ai l'impression que le problème
tourne autour de lockd. C'est lui qui semble partir en timeout. Côté
serveur, j'ai un tas de :

Apr 17 12:28:01 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:01 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:01 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:02 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:02 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:04 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:04 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:05 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:05 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:05 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:05 legendre rpc.lockd: no matching entry for hilbert

que je n'avais pas avant. J'ai essayé de remonter la partition /home
(puisque c'est celle qui semble poser problème) avec l'option nolock et
je n'obtiens qu'un :

root@hilbert:~# mount -o remount,rw,nolock /home
mount.nfs: an incorrect mount option was specified

ceci expliquant sans doute cela.

Autre chose qui semble avoir changé. Mon fstab contient :
192.168.10.128:/srv/hilbert  /  nfs intr,tcp,nfsvers=3,async 0 0
192.168.10.128:/home /home  nfs intr,tcp,nfsvers=3,async 0 0
/swapfile.0 noneswapsw  0   0

Pourtant, les montages sont reconnus par le système comme :
root@hilbert:~# nfsstat -m
/ from 192.168.10.128:/srv/hilbert
 Flags:
rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=7,retrans=10,sec=sys,local_lock=all,addr=192.168.10.128

/home from 192.168.10.128:/home
 Flags:

Re: Station diskless et Debian testing

[Étienne Mollier]

Joël Bertrand, le mardi 17 avril 2018 :
> Étienne Mollier a écrit :
> > Si le problème se déclenche au lancement d'applications du
> > type à manipuler du cache pour des raisons de performances
> > (navigateurs web, java, etc), est-ce que diminuer, rediriger
> > en local, ou supprimer ledit cache permettrait de diminuer
> > l'ampleur des sautes d'humeur du poste de CAO ?
>
>   Les programmes incriminés sont principalement les
> navigateurs web (seamonkey, firefox, chromium).  Pas d'autre
> activité suspecte lorsque le problème survient.  J'ai forcé le
> cache de seamonkey à 0.  Je ne suis pas sûr que cela arrange la
> chose puisque durant les périodes fautives, il n'y a pas
> d'activité nfs. Comme si Linux attendait quelque chose.  J'ai
> aussi l'impression que le problème est survenu avec le noyau
> 4.15 (je n'ai pas noté ce genre de problème auparavant sauf
> lorsque la machine se mettait à swapper, mais tous les
> programmes étaient impactés).

>   Un petit retour. J'ai désactivé le cache, ça améliore un
> tout petit peu les choses. J'ai noté avec un tcpdump que des
> requêtes NFS passaient lors des périodes où les applications
> bloquaient, requêtes ayant des réponses normales (et à un débit
> ridicule, quelques dizaines de kbps sur une réseau loin d'être
> engorgé et avec un serveur qui fait les pieds au mur en même
> temps). Lors de ces problèmes, aucun souci de résolution de nom
> ou autre chose. Pas de problème de réseau non plus (j'ai un
> vncviewer ouvert sur une machine distante qui continue à
> fonctionner parfaitement). C'est un peu comme si le client NFS
> mettait en cache des requêtes et oubliait de les envoyer...

Bonsoir,

C'est toujours ça de pris.  Avec un peu de chance, désactiver une
tâche de fond du type à mettre à jour des caches pourrait aider,
typiquement mlocate/updatedb (m'enfin celui-ci n'est censé ne
tourner que quotidiennement par défaut, et n'était probablement
pas en train de tourner lors de vos essais).

Du côté « correction du mal à la racine », le noyau 4.15 a
effectivement vu des modifications de son client NFS, versions 3
et 4, entre autres dans sa gestion des caches, depuis le noyau
4.14 :


https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/diff/fs/nfs/?id=v4.14=v4.15.16=2

À part dans nfs4proc.c, les changements ne donnent pas
l'impression d'avoir été francs non plus.  La migration depuis
refcount vers atomic est éventuellement suspecte.  Avez-vous la
possibilité de tester les diverses versions de NFS pour voir si
le problème se maintient d'une version à l'autre, ou bien c'est
délicat ?

À plus,
-- 
Étienne Mollier 

Re: Station diskless et Debian testing

[BERTRAND Joël]

Étienne Mollier a écrit :
> Si le problème se déclenche au lancement d'applications du type à
> manipuler du cache pour des raisons de performances (navigateurs
> web, java, etc), est-ce que diminuer, rediriger en local, ou
> supprimer ledit cache permettrait de diminuer l'ampleur des
> sautes d'humeur du poste de CAO ?

Un petit retour. J'ai désactivé le cache, ça améliore un tout petit peu
les choses. J'ai noté avec un tcpdump que des requêtes NFS passaient
lors des périodes où les applications bloquaient, requêtes ayant des
réponses normales (et à un débit ridicule, quelques dizaines de kbps sur
une réseau loin d'être engorgé et avec un serveur qui fait les pieds au
mur en même temps). Lors de ces problèmes, aucun souci de résolution de
nom ou autre chose. Pas de problème de réseau non plus (j'ai un
vncviewer ouvert sur une machine distante qui continue à fonctionner
parfaitement). C'est un peu comme si le client NFS mettait en cache des
requêtes et oubliait de les envoyer...

Bien cordialement,

JKB

Re: Station diskless et Debian testing

[BERTRAND Joël]

Étienne Mollier a écrit :
> Joël Bertrand, le 2018-04-16 :
>>  Je n'ai pas l'impression que la carte réseau soit en
>> cause (les autres applications appelant elles aussi les disques
>> NFS ne sont pas impactées). J'ai l'impression que ça touche
>> soit le pilote de la carte réseau soit le protocole NFS.
> 
> [...]
> 
>>
>> Étienne Mollier a écrit :
>>> Sans toucher au matériel, l'absence générale de charge lors
>>> d'un gel de la machine suggère un timeout quelconque.  Ça
>>> pourait, par exemple, venir de la configuration du DNS (mais
>>> j'imagine que le post client monte son NFS root via l'IP), ou
>>> peut-être du Name Service Cache Daemon nscd (mais si vous
>>> utilisez directement /etc/passwd tel que monté en NFS root,
>>> vous n'en avez peut-être pas l'usage, le service est prévu
>>> pour doper des outils de centralisation des logins comme LDAP
>>> ou du NIS).
>>
>>  Tout est monté en dur via les adresses IP. Le NIS et le
>> DNS fonctionnent parfaitement... Lorsque une application se met
>> en attente NFS, la charge monte très vite et très haut.
>> Jusqu'au moment où ça se remet à fonctionner normalement.
>> Aucune trace dans les logs, ce serait trop facile.
>>
> 
> Oups, après l'heure, ce n'est plus l'heure...  é_è
> J'ai lu de travers le message initial à propos de la charge,
> désolé.  Effectivement, ça ressemble beaucoup moins à un timeout
> et beaucoup plus à un problème de perte temporaire de la
> connexion entre le client et le serveur NFS, à ceci près que cela
> ne concerne qu'une petite sélection de programmes intensifs.
> Curieux...

N'est-ce pas ? ;-)

> Autre idée : j'ai eu un cas un peu similaire il y a quelques
> années avec gvfsd, un service Gnome qui faisait « des trucs » en
> travaillant en boucle sur des petits fichiers dans le home.  Avec
> un home monté NFS, forcément, ça se passait moins bien.
> Symlinker le répertoire concerné dans un espace local (disque
> local, /dev/shm, peu importe) avait résorbé le problème.  Le
> volume de données échangé n'était pas énorme, mais l'attente
> entre chaque requête et chaque réponse suffisait à ralentir le
> tout.  Le problème venait de la latence et non du débit.  Mais je
> ne me souviens plus exactement du comportement de la charge.
> 
> Si le problème se déclenche au lancement d'applications du type à
> manipuler du cache pour des raisons de performances (navigateurs
> web, java, etc), est-ce que diminuer, rediriger en local, ou
> supprimer ledit cache permettrait de diminuer l'ampleur des
> sautes d'humeur du poste de CAO ?

Les programmes incriminés sont principalement les navigateurs web
(seamonkey, firefox, chromium). Pas d'autre activité suspecte lorsque le
problème survient. J'ai forcé le cache de seamonkey à 0. Je ne suis pas
sûr que cela arrange la chose puisque durant les périodes fautives, il
n'y a pas d'activité nfs. Comme si Linux attendait quelque chose. J'ai
aussi l'impression que le problème est survenu avec le noyau 4.15 (je
n'ai pas noté ce genre de problème auparavant sauf lorsque la machine se
mettait à swapper, mais tous les programmes étaient impactés).

Bien cordialement,

JKB

Re: Station diskless et Debian testing

[Étienne Mollier]

Joël Bertrand, le 2018-04-16 :
>   Je n'ai pas l'impression que la carte réseau soit en
> cause (les autres applications appelant elles aussi les disques
> NFS ne sont pas impactées). J'ai l'impression que ça touche
> soit le pilote de la carte réseau soit le protocole NFS.

[...]

>
> Étienne Mollier a écrit :
> > Sans toucher au matériel, l'absence générale de charge lors
> > d'un gel de la machine suggère un timeout quelconque.  Ça
> > pourait, par exemple, venir de la configuration du DNS (mais
> > j'imagine que le post client monte son NFS root via l'IP), ou
> > peut-être du Name Service Cache Daemon nscd (mais si vous
> > utilisez directement /etc/passwd tel que monté en NFS root,
> > vous n'en avez peut-être pas l'usage, le service est prévu
> > pour doper des outils de centralisation des logins comme LDAP
> > ou du NIS).
>
>   Tout est monté en dur via les adresses IP. Le NIS et le
> DNS fonctionnent parfaitement... Lorsque une application se met
> en attente NFS, la charge monte très vite et très haut.
> Jusqu'au moment où ça se remet à fonctionner normalement.
> Aucune trace dans les logs, ce serait trop facile.
>

Oups, après l'heure, ce n'est plus l'heure...  é_è
J'ai lu de travers le message initial à propos de la charge,
désolé.  Effectivement, ça ressemble beaucoup moins à un timeout
et beaucoup plus à un problème de perte temporaire de la
connexion entre le client et le serveur NFS, à ceci près que cela
ne concerne qu'une petite sélection de programmes intensifs.
Curieux...

Autre idée : j'ai eu un cas un peu similaire il y a quelques
années avec gvfsd, un service Gnome qui faisait « des trucs » en
travaillant en boucle sur des petits fichiers dans le home.  Avec
un home monté NFS, forcément, ça se passait moins bien.
Symlinker le répertoire concerné dans un espace local (disque
local, /dev/shm, peu importe) avait résorbé le problème.  Le
volume de données échangé n'était pas énorme, mais l'attente
entre chaque requête et chaque réponse suffisait à ralentir le
tout.  Le problème venait de la latence et non du débit.  Mais je
ne me souviens plus exactement du comportement de la charge.

Si le problème se déclenche au lancement d'applications du type à
manipuler du cache pour des raisons de performances (navigateurs
web, java, etc), est-ce que diminuer, rediriger en local, ou
supprimer ledit cache permettrait de diminuer l'ampleur des
sautes d'humeur du poste de CAO ?

En espérant ne pas être tombé trop à côté de la question cette
fois ci,  :-)
À plus,
-- 
Étienne Mollier 

Re: Station diskless et Debian testing

[BERTRAND Joël]

Étienne Mollier a écrit :
> Bonsoir,
> 
>>> J'ai l'impression que ce problème s'est aggravé avec le
>>> noyau 4.15 (avant cela, ce genre de chose pouvait arriver,
>>> mais seulement lorsque le système commençait à swapper) et la
>>> libc qui venait avec lui.  La dernière mise à jour de la libc
>>> (hier) semble avoir un peu calmé la chose, mais sans la
>>> corriger.
> 
>>  Aucune idée ?
> 
> Pas vraiment d'idée, les problèmes intermittents sont les plus
> compliqués à résoudre.  À vue de nez, il faudrait tester avec une
> autre carte réseau, mais si la carte mère ne permet le PXE boot
> que sur sa carte intégrée, ça va être compliqué à vérifier.

Je n'ai pas l'impression que la carte réseau soit en cause (les autres
applications appelant elles aussi les disques NFS ne sont pas
impactées). J'ai l'impression que ça touche soit le pilote de la carte
réseau soit le protocole NFS.

> Sans toucher au matériel, l'absence générale de charge lors d'un
> gel de la machine suggère un timeout quelconque.  Ça pourait, par
> exemple, venir de la configuration du DNS (mais j'imagine que le
> post client monte son NFS root via l'IP), ou peut-être du Name
> Service Cache Daemon nscd (mais si vous utilisez directement
> /etc/passwd tel que monté en NFS root, vous n'en avez peut-être
> pas l'usage, le service est prévu pour doper des outils de
> centralisation des logins comme LDAP ou du NIS).
Tout est monté en dur via les adresses IP. Le NIS et le DNS
fonctionnent parfaitement... Lorsque une application se met en attente
NFS, la charge monte très vite et très haut. Jusqu'au moment où ça se
remet à fonctionner normalement. Aucune trace dans les logs, ce serait
trop facile.

Bien cordialement,

JKB

Re: Station diskless et Debian testing

[Étienne Mollier]

Bonsoir,

> > J'ai l'impression que ce problème s'est aggravé avec le
> > noyau 4.15 (avant cela, ce genre de chose pouvait arriver,
> > mais seulement lorsque le système commençait à swapper) et la
> > libc qui venait avec lui.  La dernière mise à jour de la libc
> > (hier) semble avoir un peu calmé la chose, mais sans la
> > corriger.

>   Aucune idée ?

Pas vraiment d'idée, les problèmes intermittents sont les plus
compliqués à résoudre.  À vue de nez, il faudrait tester avec une
autre carte réseau, mais si la carte mère ne permet le PXE boot
que sur sa carte intégrée, ça va être compliqué à vérifier.

Sans toucher au matériel, l'absence générale de charge lors d'un
gel de la machine suggère un timeout quelconque.  Ça pourait, par
exemple, venir de la configuration du DNS (mais j'imagine que le
post client monte son NFS root via l'IP), ou peut-être du Name
Service Cache Daemon nscd (mais si vous utilisez directement
/etc/passwd tel que monté en NFS root, vous n'en avez peut-être
pas l'usage, le service est prévu pour doper des outils de
centralisation des logins comme LDAP ou du NIS).

En espérant que ça aide à débroussailler une piste,
-- 
Étienne Mollier 

Re: Station diskless et Debian testing

[BERTRAND Joël]

BERTRAND Joël a écrit :
>   Bonjour à tous.
> 
>   J'ai depuis quelques jours un problème assez embêtant avec mon poste de
> travail. La configuration du réseau est la suivante :
> - gros serveur de boot et nfs tournant sous NetBSD 8 (i7, 16 Go de
> mémoire, 128 threads du serveur nfsd)
> - postes de travail sous Linux ou FreeBSD tous diskless
> - serveur connecté au réseau interne par lien agrégés (agr0 sous NetBSD
> et un switch manageable qui comprend le protocole). Les cartes réseau du
> serveur sont des intel (wm sous NetBSD) et envoient réellement 4 Gbps
> vers le réseau (avec la limitation du xor entre mac source et mac
> destination). Le switch est capable de gérer ces 4 Gbps sans broncher.
> 
>   Un poste sous FreeBSD 11.1 fonctionne parfaitement bien. Le player
> video sous Linux Debian stable fonctionne normalement lui aussi.
> d'autres machines de dev du labo ne bronchent pas (arm et mips).
> 
>   En revanche, mon poste de CAO électronique est à la ramasse.
> Configuration de la machine : i7 4970, 16 Go de mémoire, carte réseau
> gigabit. Par moment, tout fonctionne normalement. À d'autres, la charge
> monte anormalement, atteignant parfois plus de dix (alors que rien ne le
> justifie) et bloquant soit le système en entier, soit une application
> particulière. Je précise que le poste ne swappe pas et qu'il n'y a pas
> de saturation de réseau (lors de ces montées en charge, le débit réseau
> est de quelques dizaines de kbps). La charge du serveur ne monte pas non
> plus. La carte-mère du poste en question est une Asus thin mini-itx
> (Q87T) avec deux cartes réseau, une Realtek et une intel, j'utilise
> actuellement la realtek n'arrivant pas à booter sur le réseau avec la
> carte intel.
> 
>   J'ai l'impression que ce problème s'est aggravé avec le noyau 4.15
> (avant cela, ce genre de chose pouvait arriver, mais seulement lorsque
> le système commençait à swapper) et la libc qui venait avec lui. La
> dernière mise à jour de la libc (hier) semble avoir un peu calmé la
> chose, mais sans la corriger.
> 
>   Typiquement, des applications comme seamonkey, firefox ou chromium
> peuvent figer le système. Le lancement de firefox provoquait juste
> l'affichage des décorations de la fenêtre, rien d'autre.
> 
>   Je pensais à des histoires de segments de mémoire partagée, mais sysctl
> renvoie des valeurs tout à fait correctes.
> 
>   Je ne sais plus où chercher. Toute idée sera la bienvenue.
> 
>   Bien cordialement,
> 
>   JKB
> 

Aucune idée ? C'est franchement pénible. À certains moments, je suis
contraint d'attendre 10 minutes pour que la charge tombe... Ce n'est pas
un problème de serveur, tous les autres postes se comportent bien.

Bien cordialement,

JKB