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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
didier gaumet
Ne m'en veux pas si ma réponse n'est pas pertinente: mes compétences en la matière tendent dangereusement vers zéro. Une remarque et une question toutefois: - la page man de swapon(8) indique: "[...]NOTES Vous ne devriez pas utiliser swapon sur un fichier qui comporte des trous. Cela peut être vu dans le journal système comme swapon: swapfile has holes. L’implémentation de fichier d’échange dans le noyau s’attend à pouvoir écrire directement dans le fichier, sans aide du système de fichiers. C’est un problème pour les fichiers préalloués (par exemple par fallocate(1)) sur les systèmes de fichiers comme XFS ou ext4 et sur les systèmes de fichiers utilisant la copie sur écriture (« copy-on-write ») comme Btrfs Utiliser dd(1) et /dev/zero est conseillé pour éviter les trous sur XFS et ext4. [...] La pagination par NFS (Network File System) risque de ne pas fonctionner. [...]" Donc le problème me semble toujours au moins partiellement d'actualité. - même indépendamment du fait, en soi, de mettre le swap sur le réseau, en tant que béotien total de la question, je me demande si l'hétérogénéité des architectures matérielles (non seulement type mais aussi nombre de bits) et des systèmes d'exploitation parmi les clients et le serveur de swap ne pose pas problème (mais c'est peut-être une remarque stupide illustrant mon ignorance)
Ne m'en veux pas si ma réponse n'est pas pertinente: mes compétences en
la matière tendent dangereusement vers zéro.
Une remarque et une question toutefois:
- la page man de swapon(8) indique:
"[...]NOTES
Vous ne devriez pas utiliser swapon sur un fichier qui comporte
des trous. Cela peut être vu dans le journal système comme
swapon: swapfile has holes.
L’implémentation de fichier d’échange dans le noyau s’attend à
pouvoir écrire directement dans le fichier, sans aide du système
de fichiers. C’est un problème pour les fichiers préalloués (par
exemple par fallocate(1)) sur les systèmes de fichiers comme XFS ou ext4
et sur les systèmes de fichiers utilisant la copie sur écriture («
copy-on-write ») comme Btrfs
Utiliser dd(1) et /dev/zero est conseillé pour éviter les trous
sur XFS et ext4.
[...]
La pagination par NFS (Network File System) risque de ne pas
fonctionner.
[...]"
Donc le problème me semble toujours au moins partiellement d'actualité.
- même indépendamment du fait, en soi, de mettre le swap sur le réseau,
en tant que béotien total de la question, je me demande si
l'hétérogénéité des architectures matérielles (non seulement type mais
aussi nombre de bits) et des systèmes d'exploitation parmi les clients
et le serveur de swap ne pose pas problème (mais c'est peut-être une
remarque stupide illustrant mon ignorance)
Ne m'en veux pas si ma réponse n'est pas pertinente: mes compétences en la matière tendent dangereusement vers zéro. Une remarque et une question toutefois: - la page man de swapon(8) indique: "[...]NOTES Vous ne devriez pas utiliser swapon sur un fichier qui comporte des trous. Cela peut être vu dans le journal système comme swapon: swapfile has holes. L’implémentation de fichier d’échange dans le noyau s’attend à pouvoir écrire directement dans le fichier, sans aide du système de fichiers. C’est un problème pour les fichiers préalloués (par exemple par fallocate(1)) sur les systèmes de fichiers comme XFS ou ext4 et sur les systèmes de fichiers utilisant la copie sur écriture (« copy-on-write ») comme Btrfs Utiliser dd(1) et /dev/zero est conseillé pour éviter les trous sur XFS et ext4. [...] La pagination par NFS (Network File System) risque de ne pas fonctionner. [...]" Donc le problème me semble toujours au moins partiellement d'actualité. - même indépendamment du fait, en soi, de mettre le swap sur le réseau, en tant que béotien total de la question, je me demande si l'hétérogénéité des architectures matérielles (non seulement type mais aussi nombre de bits) et des systèmes d'exploitation parmi les clients et le serveur de swap ne pose pas problème (mais c'est peut-être une remarque stupide illustrant mon ignorance)
BERTRAND Jo=c3=abl
didier gaumet a écrit :
Ne m'en veux pas si ma réponse n'est pas pertinente: mes compétences en la matière tendent dangereusement vers zéro.
Aucun souci.
Une remarque et une question toutefois: - la page man de swapon(8) indique: "[...]NOTES Vous ne devriez pas utiliser swapon sur un fichier qui comporte des trous. Cela peut être vu dans le journal système comme swapon: swapfile has holes.
Je n'ai pas ce message dans /var/log/syslog. En revanche, j'ai ce genre d'erreur : syslog.4.gz:Mar 29 12:23:09 hilbert kernel: [739587.545009] Write error on dio swapfile (690577408)
L’implémentation de fichier d’échange dans le noyau s’attend à pouvoir écrire directement dans le fichier, sans aide du système de fichiers. C’est un problème pour les fichiers préalloués (par exemple par fallocate(1)) sur les systèmes de fichiers comme XFS ou ext4 et sur les systèmes de fichiers utilisant la copie sur écriture (« copy-on-write ») comme Btrfs Utiliser dd(1) et /dev/zero est conseillé pour éviter les trous sur XFS et ext4. [...]
Le fichier d'échange fut créé par dd.
La pagination par NFS (Network File System) risque de ne pas fonctionner. [...]" Donc le problème me semble toujours au moins partiellement d'actualité.
J'ai remonté le truc avec /dev/loop0. On va voir si ça fonctionne mieux.
- même indépendamment du fait, en soi, de mettre le swap sur le réseau, en tant que béotien total de la question, je me demande si l'hétérogénéité des architectures matérielles (non seulement type mais aussi nombre de bits) et des systèmes d'exploitation parmi les clients et le serveur de swap ne pose pas problème (mais c'est peut-être une remarque stupide illustrant mon ignorance)
Normalement, nfs est nfs et ça fonctionne (tant qu'on ne touche pas à NFSv4...). Bien cordialement, JKB
didier gaumet a écrit :
Ne m'en veux pas si ma réponse n'est pas pertinente: mes compétences en
la matière tendent dangereusement vers zéro.
Aucun souci.
Une remarque et une question toutefois:
- la page man de swapon(8) indique:
"[...]NOTES
Vous ne devriez pas utiliser swapon sur un fichier qui comporte
des trous. Cela peut être vu dans le journal système comme
swapon: swapfile has holes.
Je n'ai pas ce message dans /var/log/syslog. En revanche, j'ai ce genre
d'erreur :
syslog.4.gz:Mar 29 12:23:09 hilbert kernel: [739587.545009] Write error
on dio swapfile (690577408)
L’implémentation de fichier d’échange dans le noyau s’attend à
pouvoir écrire directement dans le fichier, sans aide du système
de fichiers. C’est un problème pour les fichiers préalloués (par
exemple par fallocate(1)) sur les systèmes de fichiers comme XFS ou ext4
et sur les systèmes de fichiers utilisant la copie sur écriture («
copy-on-write ») comme Btrfs
Utiliser dd(1) et /dev/zero est conseillé pour éviter les trous
sur XFS et ext4.
[...]
Le fichier d'échange fut créé par dd.
La pagination par NFS (Network File System) risque de ne pas
fonctionner.
[...]"
Donc le problème me semble toujours au moins partiellement d'actualité.
J'ai remonté le truc avec /dev/loop0. On va voir si ça fonctionne mieux.
- même indépendamment du fait, en soi, de mettre le swap sur le réseau,
en tant que béotien total de la question, je me demande si
l'hétérogénéité des architectures matérielles (non seulement type mais
aussi nombre de bits) et des systèmes d'exploitation parmi les clients
et le serveur de swap ne pose pas problème (mais c'est peut-être une
remarque stupide illustrant mon ignorance)
Normalement, nfs est nfs et ça fonctionne (tant qu'on ne touche pas à
NFSv4...).
Ne m'en veux pas si ma réponse n'est pas pertinente: mes compétences en la matière tendent dangereusement vers zéro.
Aucun souci.
Une remarque et une question toutefois: - la page man de swapon(8) indique: "[...]NOTES Vous ne devriez pas utiliser swapon sur un fichier qui comporte des trous. Cela peut être vu dans le journal système comme swapon: swapfile has holes.
Je n'ai pas ce message dans /var/log/syslog. En revanche, j'ai ce genre d'erreur : syslog.4.gz:Mar 29 12:23:09 hilbert kernel: [739587.545009] Write error on dio swapfile (690577408)
L’implémentation de fichier d’échange dans le noyau s’attend à pouvoir écrire directement dans le fichier, sans aide du système de fichiers. C’est un problème pour les fichiers préalloués (par exemple par fallocate(1)) sur les systèmes de fichiers comme XFS ou ext4 et sur les systèmes de fichiers utilisant la copie sur écriture (« copy-on-write ») comme Btrfs Utiliser dd(1) et /dev/zero est conseillé pour éviter les trous sur XFS et ext4. [...]
Le fichier d'échange fut créé par dd.
La pagination par NFS (Network File System) risque de ne pas fonctionner. [...]" Donc le problème me semble toujours au moins partiellement d'actualité.
J'ai remonté le truc avec /dev/loop0. On va voir si ça fonctionne mieux.
- même indépendamment du fait, en soi, de mettre le swap sur le réseau, en tant que béotien total de la question, je me demande si l'hétérogénéité des architectures matérielles (non seulement type mais aussi nombre de bits) et des systèmes d'exploitation parmi les clients et le serveur de swap ne pose pas problème (mais c'est peut-être une remarque stupide illustrant mon ignorance)
Normalement, nfs est nfs et ça fonctionne (tant qu'on ne touche pas à NFSv4...). Bien cordialement, JKB
didier gaumet
Le 02/04/2019 à 11:22, BERTRAND Joël a écrit :
didier gaumet a écrit :
[...]
je me demande si
l'hétérogénéité des architectures matérielles (non seulement type mais aussi nombre de bits) et des systèmes d'exploitation parmi les clients et le serveur de swap ne pose pas problème (mais c'est peut-être une remarque stupide illustrant mon ignorance)
Normalement, nfs est nfs et ça fonctionne (tant qu'on ne touche pas à NFSv4...).
Disons qu'en tant qu'ignare du domaine, c'est ce qu'il m'avait semblé comprendre quand les données sous-jacentes sont gérées par des systèmes de fichiers évolués, mais que je doutais que le swap fasse partie de cette catégorie et redoutais qu'il soit plus plus impacté par l'architecture matérielle utilisée ainsi que l'implémentation du noyau de l'OS particulière à cette architecture. Mais on peut affirmer sans risque de beaucoup se tromper que je n'entrave que pouic au sujet et je posais juste la question pour mon édification personnelle, donc pardon pour le bruit :-)
Le 02/04/2019 à 11:22, BERTRAND Joël a écrit :
didier gaumet a écrit :
[...]
je me demande si
l'hétérogénéité des architectures matérielles (non seulement type mais
aussi nombre de bits) et des systèmes d'exploitation parmi les clients
et le serveur de swap ne pose pas problème (mais c'est peut-être une
remarque stupide illustrant mon ignorance)
Normalement, nfs est nfs et ça fonctionne (tant qu'on ne touche pas à
NFSv4...).
Disons qu'en tant qu'ignare du domaine, c'est ce qu'il m'avait semblé
comprendre quand les données sous-jacentes sont gérées par des systèmes
de fichiers évolués, mais que je doutais que le swap fasse partie de
cette catégorie et redoutais qu'il soit plus plus impacté par
l'architecture matérielle utilisée ainsi que l'implémentation du noyau
de l'OS particulière à cette architecture.
Mais on peut affirmer sans risque de beaucoup se tromper que je
n'entrave que pouic au sujet et je posais juste la question pour mon
édification personnelle, donc pardon pour le bruit :-)
l'hétérogénéité des architectures matérielles (non seulement type mais aussi nombre de bits) et des systèmes d'exploitation parmi les clients et le serveur de swap ne pose pas problème (mais c'est peut-être une remarque stupide illustrant mon ignorance)
Normalement, nfs est nfs et ça fonctionne (tant qu'on ne touche pas à NFSv4...).
Disons qu'en tant qu'ignare du domaine, c'est ce qu'il m'avait semblé comprendre quand les données sous-jacentes sont gérées par des systèmes de fichiers évolués, mais que je doutais que le swap fasse partie de cette catégorie et redoutais qu'il soit plus plus impacté par l'architecture matérielle utilisée ainsi que l'implémentation du noyau de l'OS particulière à cette architecture. Mais on peut affirmer sans risque de beaucoup se tromper que je n'entrave que pouic au sujet et je posais juste la question pour mon édification personnelle, donc pardon pour le bruit :-)
Erwann Le Bras
bonjour Ce ne serait le NFS qui saturerait (vu ailleurs avec une appli AIX gourmande en écriture qui plantait si elle avait ses données sur un disque NFS)? Je suis surpris qu'avec 32Go de RAM ça ne suffise pas. En désactivant le swap, ça donne quoi? Avez-vous essayé avec un Ramdrive pour le Swap (<==!!!)? cordialement Le 02/04/2019 à 10:11, BERTRAND Joël a écrit :
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
bonjour
Ce ne serait le NFS qui saturerait (vu ailleurs avec une appli AIX
gourmande en écriture qui plantait si elle avait ses données sur un
disque NFS)?
Je suis surpris qu'avec 32Go de RAM ça ne suffise pas. En désactivant le
swap, ça donne quoi?
Avez-vous essayé avec un Ramdrive pour le Swap (<==!!!)?
cordialement
Le 02/04/2019 à 10:11, BERTRAND Joël a écrit :
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
bonjour Ce ne serait le NFS qui saturerait (vu ailleurs avec une appli AIX gourmande en écriture qui plantait si elle avait ses données sur un disque NFS)? Je suis surpris qu'avec 32Go de RAM ça ne suffise pas. En désactivant le swap, ça donne quoi? Avez-vous essayé avec un Ramdrive pour le Swap (<==!!!)? cordialement Le 02/04/2019 à 10:11, BERTRAND Joël a écrit :
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
Pascal Hambourg
Le 02/04/2019 à 10:11, BERTRAND Joël a écrit :
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 ?
Sachant que l'utilisation d'un fichier de swap sur un système de fichiers local par le noyau Linux au lieu d'un périphérique bloc est un sale hack affligé de diverses restrictions (cf. extraits de pages de manuel cités dans cette discussion), je ne pensais même pas que le swap sur NFS puisse être supporté sans artifice de type loop. Recherche faite dans les changelogs, il l'est depuis Linux 3.6. Mais cela n'est visiblement pas trivial et a nécessité de nombreux patchs, encore dans les versions récentes du noyau. Il a fallu régler des histoires d'interblocage entre swap et NFS par exemple. Auparavant, on recommandait des choses comme NBD (Network Block Device) ou iSCSI. Je ne sais pas si NetBSD supporte. Quelqu'un a suggéré d'utiliser un ramdrive. Ce n'est pas idiot, non pas dans sa version originelle rd qui n'apporte rien, bien au contraire, mais la variante zram qui compresse les données, ce qui me semble compatible avec la taille de ton swap (16 Go, soit la moitié de la RAM). Je ne l'ai pas utilisé, mais d'après mes lectures ce serait redoutablement efficace.
Le 02/04/2019 à 10:11, BERTRAND Joël a écrit :
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
Est-ce toujours utile ? Et sinon, des pistes pour corriger le problème ?
Sachant que l'utilisation d'un fichier de swap sur un système de
fichiers local par le noyau Linux au lieu d'un périphérique bloc est un
sale hack affligé de diverses restrictions (cf. extraits de pages de
manuel cités dans cette discussion), je ne pensais même pas que le swap
sur NFS puisse être supporté sans artifice de type loop. Recherche faite
dans les changelogs, il l'est depuis Linux 3.6. Mais cela n'est
visiblement pas trivial et a nécessité de nombreux patchs, encore dans
les versions récentes du noyau. Il a fallu régler des histoires
d'interblocage entre swap et NFS par exemple.
Auparavant, on recommandait des choses comme NBD (Network Block Device)
ou iSCSI. Je ne sais pas si NetBSD supporte.
Quelqu'un a suggéré d'utiliser un ramdrive. Ce n'est pas idiot, non pas
dans sa version originelle rd qui n'apporte rien, bien au contraire,
mais la variante zram qui compresse les données, ce qui me semble
compatible avec la taille de ton swap (16 Go, soit la moitié de la RAM).
Je ne l'ai pas utilisé, mais d'après mes lectures ce serait
redoutablement efficace.
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 ?
Sachant que l'utilisation d'un fichier de swap sur un système de fichiers local par le noyau Linux au lieu d'un périphérique bloc est un sale hack affligé de diverses restrictions (cf. extraits de pages de manuel cités dans cette discussion), je ne pensais même pas que le swap sur NFS puisse être supporté sans artifice de type loop. Recherche faite dans les changelogs, il l'est depuis Linux 3.6. Mais cela n'est visiblement pas trivial et a nécessité de nombreux patchs, encore dans les versions récentes du noyau. Il a fallu régler des histoires d'interblocage entre swap et NFS par exemple. Auparavant, on recommandait des choses comme NBD (Network Block Device) ou iSCSI. Je ne sais pas si NetBSD supporte. Quelqu'un a suggéré d'utiliser un ramdrive. Ce n'est pas idiot, non pas dans sa version originelle rd qui n'apporte rien, bien au contraire, mais la variante zram qui compresse les données, ce qui me semble compatible avec la taille de ton swap (16 Go, soit la moitié de la RAM). Je ne l'ai pas utilisé, mais d'après mes lectures ce serait redoutablement efficace.
BERTRAND Jo=c3=abl
Pascal Hambourg a écrit :
Le 02/04/2019 à 10:11, BERTRAND Joël a écrit :
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 ?
Sachant que l'utilisation d'un fichier de swap sur un système de fichiers local par le noyau Linux au lieu d'un périphérique bloc est un sale hack affligé de diverses restrictions (cf. extraits de pages de manuel cités dans cette discussion), je ne pensais même pas que le swap sur NFS puisse être supporté sans artifice de type loop. Recherche faite dans les changelogs, il l'est depuis Linux 3.6. Mais cela n'est visiblement pas trivial et a nécessité de nombreux patchs, encore dans les versions récentes du noyau. Il a fallu régler des histoires d'interblocage entre swap et NFS par exemple.
Ça ressemble assez à ce que j'observe avec un noyau 4.19.0-1-amd64. On dirait bien que toutes les conditions bloquantes n'ont pas été éradiquées. Présentement, le swap est monté dans un loopback.
Auparavant, on recommandait des choses comme NBD (Network Block Device) ou iSCSI. Je ne sais pas si NetBSD supporte.
J'ai de très mauvaises expériences avec ndb (pour être franc, il y a longtemps que je n'ai plus utilisé ndb). Je n'ai pas pensé à iSCSI. NetBSD le supporte, mais ça m'obligerait à jongler avec des slices BSD côté serveur et ça m'emballe assez modérément. Aujourd'hui, la configuration est assez simple : /home dans un wedge (dk1 en raid5) et tous les rootfs dans un slice raid1 sur une autre grappe de disques. J'aimerais éviter de créer un device de type bloc par station diskless.
Quelqu'un a suggéré d'utiliser un ramdrive. Ce n'est pas idiot, non pas dans sa version originelle rd qui n'apporte rien, bien au contraire, mais la variante zram qui compresse les données, ce qui me semble compatible avec la taille de ton swap (16 Go, soit la moitié de la RAM). Je ne l'ai pas utilisé, mais d'après mes lectures ce serait redoutablement efficace.
Je vais regarder ce point. Bien cordialement, JKB
Pascal Hambourg a écrit :
Le 02/04/2019 à 10:11, BERTRAND Joël a écrit :
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
Est-ce toujours utile ? Et sinon, des pistes pour corriger le
problème ?
Sachant que l'utilisation d'un fichier de swap sur un système de
fichiers local par le noyau Linux au lieu d'un périphérique bloc est un
sale hack affligé de diverses restrictions (cf. extraits de pages de
manuel cités dans cette discussion), je ne pensais même pas que le swap
sur NFS puisse être supporté sans artifice de type loop. Recherche faite
dans les changelogs, il l'est depuis Linux 3.6. Mais cela n'est
visiblement pas trivial et a nécessité de nombreux patchs, encore dans
les versions récentes du noyau. Il a fallu régler des histoires
d'interblocage entre swap et NFS par exemple.
Ça ressemble assez à ce que j'observe avec un noyau 4.19.0-1-amd64. On
dirait bien que toutes les conditions bloquantes n'ont pas été
éradiquées. Présentement, le swap est monté dans un loopback.
Auparavant, on recommandait des choses comme NBD (Network Block Device)
ou iSCSI. Je ne sais pas si NetBSD supporte.
J'ai de très mauvaises expériences avec ndb (pour être franc, il y a
longtemps que je n'ai plus utilisé ndb). Je n'ai pas pensé à iSCSI.
NetBSD le supporte, mais ça m'obligerait à jongler avec des slices BSD
côté serveur et ça m'emballe assez modérément. Aujourd'hui, la
configuration est assez simple : /home dans un wedge (dk1 en raid5) et
tous les rootfs dans un slice raid1 sur une autre grappe de disques.
J'aimerais éviter de créer un device de type bloc par station diskless.
Quelqu'un a suggéré d'utiliser un ramdrive. Ce n'est pas idiot, non pas
dans sa version originelle rd qui n'apporte rien, bien au contraire,
mais la variante zram qui compresse les données, ce qui me semble
compatible avec la taille de ton swap (16 Go, soit la moitié de la RAM).
Je ne l'ai pas utilisé, mais d'après mes lectures ce serait
redoutablement efficace.
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 ?
Sachant que l'utilisation d'un fichier de swap sur un système de fichiers local par le noyau Linux au lieu d'un périphérique bloc est un sale hack affligé de diverses restrictions (cf. extraits de pages de manuel cités dans cette discussion), je ne pensais même pas que le swap sur NFS puisse être supporté sans artifice de type loop. Recherche faite dans les changelogs, il l'est depuis Linux 3.6. Mais cela n'est visiblement pas trivial et a nécessité de nombreux patchs, encore dans les versions récentes du noyau. Il a fallu régler des histoires d'interblocage entre swap et NFS par exemple.
Ça ressemble assez à ce que j'observe avec un noyau 4.19.0-1-amd64. On dirait bien que toutes les conditions bloquantes n'ont pas été éradiquées. Présentement, le swap est monté dans un loopback.
Auparavant, on recommandait des choses comme NBD (Network Block Device) ou iSCSI. Je ne sais pas si NetBSD supporte.
J'ai de très mauvaises expériences avec ndb (pour être franc, il y a longtemps que je n'ai plus utilisé ndb). Je n'ai pas pensé à iSCSI. NetBSD le supporte, mais ça m'obligerait à jongler avec des slices BSD côté serveur et ça m'emballe assez modérément. Aujourd'hui, la configuration est assez simple : /home dans un wedge (dk1 en raid5) et tous les rootfs dans un slice raid1 sur une autre grappe de disques. J'aimerais éviter de créer un device de type bloc par station diskless.
Quelqu'un a suggéré d'utiliser un ramdrive. Ce n'est pas idiot, non pas dans sa version originelle rd qui n'apporte rien, bien au contraire, mais la variante zram qui compresse les données, ce qui me semble compatible avec la taille de ton swap (16 Go, soit la moitié de la RAM). Je ne l'ai pas utilisé, mais d'après mes lectures ce serait redoutablement efficace.
