É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&id2=v4.15.16&dt=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 none swap sw 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
précise que le fstab n'a pas changé depuis le 8 janvier 2017 et que tout
fonctionnait correctement.
Bien cordialement,
JKB
