Bonjour à tous,
Depuis quelque temps, j'observe un problème assez embêtant avec mes
postes de travail. Je m'explique.
J'ai un serveur principal, routeur à tout faire qui tourne sous NetBSD.
En particulier, ce serveur me sert de serveur de boot, nis, dhcpd, tftpd
et serveur nfs (v3/tcp).
Le LAN de ce serveur est un device agr0 (deux liens 10Gbps agrégés) qui
tombe sur un switch distribuant tous les flux en 1Gbps (avec de la QoS
pour la téléphonie, paquets taggués et altqd sur le serveur NetBSD). Ça
fonctionne bien.
Les postes de travail sont des Linux (amd64, arm, sparc32 [carte de dev
Leon4]), des FreeBSD (amd64) et des NetBSD (amd64). En temps normal,
tout fonctionne correctement. Les machines (sauf les arm dont les
systèmes de boot sont foireux et aléatoires en tftp... Un coup je
marche, un coup je ne marche pas...) démarrent toutes en récupérant
leurs informations sur le serveur.
Là où cela se corse, c'est lorsque ces stations de travail commencent à
utiliser le swap. Je sais qu'avoir le swap sur une partition nfs n'est
pas une idée forcément géniale, mais là n'est pas le débat.
Par ailleurs, depuis quelques versions du noyau, j'ai l'impression que
l'option vm.swappiness ne sert plus à rien. Que je la colle à 10 ou à
90, le noyau utilise le swap comme un goret alors que j'ai 32 Go de
mémoire sur ma machine. Dans l'ancien temps, le fait de coller
vm.swappiness à une valeur faible modérait les ardeurs du noyau. Ce
n'est pas bien grave, le réseau suit.
En revanche, ce qui me dérange bien plus, ce sont les "plantages"
aléatoires en cas de forte utilisation du swap. Typiquement, lorsque je
lance une grosse simulation ngspice la nuit (mesure de bruit par
exemple), 9 fois sur 10, mon poste est planté le lendemain matin. J'ai
naturellement vérifié qu'il ne s'agissait pas d'un "out of memory" en
faisant tourner la même simulation sur un poste avec des disques locaux.
La simulation arrive au bout puis ngspice écrit les données sur le
disque. Dans le cas d'une simulation concernant du bruit, l'écriture de
ces données prend beaucoup de place en mémoire et le système swappe.
La charge arrive à monter à 15, le début du fichier est inscrit puis le
système se bloque. Pas sur un problème réseau, la station répond
toujours au ping. Mais il n'y a plus aucune activité réseau comme si un
processus passait avant le swapper et faisait une attente bloquante sur
l'interface réseau. Naturellement, rien dans les logs (sauf si le noyau
veut écrire quelque chose qu'il n'arrive pas à balancer sur le disque
/var en nfs). Rien sur l'écran non plus. Si xscreensaver passe, pas
moins de réveiller l'écran. Impossible de se connecter en ssh.
La machine est un i7-4490 avec 32 Go de mémoire sur une carte-mère Asus
Q87T. Noyau Linux 4.19.0-1-amd64. Cette carte-mère possède deux cartes
réseau, une Realtek et une Intel. J'utilise actuellement la Realtek, ne
réussissant pas utiliser la carte Intel en tftp. Elle récupère bien une
adresse IP, mais le boot réseau s'arrête là. J'ai bien essayé de
comprendre sans succès.
À partir de là, je sèche. J'ai déjà observé des plantages lorsque le
swap était utilisé à moins de 10% et je ne comprends pas. J'admets que
l'utilisation d'un swap sur un disque réseau apporte des latences
importantes, pas que cela plante un système.
Le swap est défini à la hussarde avec un fichier :
/swapfile.0 none swap sw 0 0
et dmesg renvoie :
[ 10.345811] Adding 16383996k swap on /swapfile.0. Priority:-2
extents:1 across:16383996k FS
J'ai trouvé ceci :
https://superuser.com/questions/497249/why-using-swap-file-over-a-smb-nfs-mounted-filesystem-is-not-possible-in-linux
Est-ce toujours utile ? Et sinon, des pistes pour corriger le problème ?
Bien cordialement,
JKB
