É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
