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
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
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
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 ?
> 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 ?
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 ?
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).
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).
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).
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.
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.
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.
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
É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...
É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...
É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...
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&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 ?
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&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 ?
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&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 ?
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 » …
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 » …
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 » …
