Broutage encore

Jo Engo <yl@icite.fr> écrivait:

Je ne retrouve plus le fil que j'avais initié, il est trop vieux sans
doute. Bon mon PC se fige encore de temps en temps mais lÍ  j'avais lancé
un htop en remote ce qui fait que j'ai pu épingler firefox, seulement 2
tabs actives dont https://www.mdph31.fr et 77% des ressources mémoire.
Apparemment c'est cette page qui est gourmande. Du coup le swap est plein
et le PC est quasi-complètement gelé (j'ai pu faire un killall firefox-esr
en remote) et qui m'a permis de reprendre la main puis j'ai lancé htop en
remote (ssh) sur mon autre machine puis j'ai relancé firefox-esr et
constaté les dégÍ¢ts.

- Est-ce normal que ma machine se fige quasiment quand le swap est plein ?

Oui, et après c'est le plantage pour toutes les applications mal
programmés qui ne gèrent pas les erreurs d'allocations de ram.

- j'envisage de gaver la machine en RAM et de supprimer le swap, est-ce
une bonne idée ?

Oui.

Jo Engo <yl@icite.fr> wrote:

- Est-ce normal que ma machine se fige quasiment quand le swap est plein ?

Oui et non.

Deux éléments:

- par défaut, le kernel Linux travaille en overcommit: il peut donc
promettre aux applications plus de RAM qu'il n'y en a, en général
cette sur-réservation (overbooking) n'a pas de conséquence sinon
baisser les coÍ»ts du matériel nécessaire

- un mécanisme existe dans le kernel, le OOM killer, qui va essayer
lorsque la mémoire est insuffisante lors d'une faute de page d'un
processus qui aurait voulu allouer cette page, de tuer un processus plus
adéquat que celui ayant causé la faute de page.

- toutefois, ces mécanismes ne sont pas sans faute.

Un swap plein est un symptÍ´me de plusieurs choses:

- soit la RAM est effectivement insuffisante

- soit le work-load de la machine est tel que la pression sur les I/O
fait que le kernel remplace des pages de données de processus (qui
finissent dans le swap) par des pages de cache/buffer I/O

Sur un serveur, lorsque je vois qu'il swappe, j'ai tendance Í  analyser
la performance et la RAM effectivement utilisée, et parfois Í  modifier
les paramètres de la gestion mémoire: cela diminue un peu la performance
I/O mais cela évite des délais liés au swap. Toutefois, je ne fais cela
que si la RAM est suffisante.

Exemple: un serveur avec 32 GB de RAM, donc les applications utilisent
environ 8GB, le buffer-cache le reste, et qui avait tendance Í  mettre
2-3 GB dans le swap, avec pas mal de swap-in (ce qui est dans le swap
est en fait utile aux applications, mauvaise nouvelle pour la
performance): j'ai sacrifié un peu de performance I/O en rendant moins
agressif le pre-swapping et le swapping de pression I/O et la
performance globale est maintenant excellente (très peu d'I/O wait) tout
en utilisant peu le swap (10%) et surtout vmstat 5 montre que le swap-in
et swap-out est très faible, de même pour les statistiques Í  long terme
munin; uptime d'une centaine de jours. Ce serveur a aussi une VM lxc
avec du x2go utilisée pour du montage vidéo ponctuellement, donc c'est
aussi un desktop (mais sans écran local, Í  distance).

Sur un client, le problème est différent et en général Linux me semble
s'en tirer mieux par défaut, s'il y a assez de RAM.

- j'envisage de gaver la machine en RAM et de supprimer le swap, est-ce
une bonne idée ?

Oui et non.

DéjÍ , le swap peut être utilisé pour les fonctions d'hibernation.

Ensuite, Linux utilise le swap aussi pour optimiser les I/O: imaginez un
gros processus endormi depuis des jours, sa mémoire serait plus utile au
buffer/cache. Ou pour pre-swapper afin de pouvoir répondre plus
interactivement Í  des besoins de l'utilisateur.

Si la vieille règle de deux fois plus de swap que de RAM des systèmes
BSD n'a jamais été valable sous Linux, on lit fréquemment des mises en
garde sur le risque de ne pas mettre de swap. D'autant plus que la
quantité de swap est un des paramètres de la gestion mémoire plus ou
moins agressive de Linux.

Actuellement, je mets en général 1x la RAM en swap, toutefois je vais
rarement au-delÍ  de 4 GB. Seulement dans des cas très particuliers de
systèmes embarqués je ne mets pas de swap, mais dans ce cas le besoin en
RAM des applications est largement assuré, sans pointes (assez
déterministe, en fait).

Dans votre cas précis, je recommanderais d'instrumenter la gestion
mémoire de votre machine, par exemple en tournant

vmstat 5

dans une console, ou installer munin et apache2 pour plus de détails
(recommandé sur un serveur seulement). Il y a peut-être d'autres outils
plus orienté desktop.

vmstat vous apprendra en temps réel si votre système swappe activement (en
général mauvais pour la performance si beaucoup de swap in; s'il n'y a
que du swap out c'est plutÍ´t une bonne nouvelle), la colonne wait vous
donnera aussi des idées sur la performance globale I/O.

Il faudrait aussi consulter le log kernel (dmesg) pour voir quelle
décision l'OOM killer a prise et pourquoi lorsque vous devrez Í  nouveau
décoincer Í  distance votre machine.

Ensuite, oui, ajouter de la RAM est toujours une bonne solution. Mais
avoir un swap de taille suffisante est aussi important.

Jo Engo <yl@icite.fr> wrote:

- Est-ce normal que ma machine se fige quasiment quand le swap est plein ?

Oui et non.

Mais:

- par défaut, le kernel Linux travaille en overcommit: il peut donc
promettre aux applications plus de RAM qu'il n'y en a, en général
cette sur-réservation (overbooking) n'a pas de conséquence sinon
baisser les coÍ»ts du matériel nécessaire

- un mécanisme existe dans le kernel, le OOM killer, qui va essayer
lorsque la mémoire est insuffisante lors d'une faute de page d'un
processus qui aurait voulu allouer cette page, de tuer un processus plus
adéquat que celui ayant causé la faute de page.

- toutefois, ces mécanismes ne sont pas sans faute.

Un swap plein est un symptÍ´me de plusieurs choses:

- soit la RAM est effectivement insuffisante

- soit le work-load de la machine est tel que la pression sur les I/O
fait que le kernel remplace des pages de données de processus (qui
finissent dans le swap) par des pages de cache/buffer I/O

Sur un serveur, lorsque je vois qu'il swappe, j'ai tendance Í  analyser
la performance et la RAM effectivement utilisée, et parfois Í  modifier
les paramètres de la gestion mémoire: cela diminue un peu la performance
I/O mais cela évite des délais liés au swap. Toutefois, je ne fais cela
que si la RAM est suffisante.

Exemple: un serveur avec 32 GB de RAM, donc les applications utilisent
environ 8GB, le buffer-cache le reste, et qui avait tendance Í  mettre
2-3 GB dans le swap, avec pas mal de swap-in (ce qui est dans le swap
est en fait utile aux applications, mauvaise nouvelle pour la
performance): j'ai sacrifié un peu de performance I/O en rendant moins
agressif le pre-swapping et le swapping de pression I/O et la
performance globale est maintenant excellente (très peu d'I/O wait) tout
en utilisant peu le swap (10%) et surtout vmstat 5 montre que le swap-in
et swap-out est très faible, de même pour les statistiques Í  long terme
munin; uptime d'une centaine de jours. Ce serveur a aussi une VM lxc
avec du x2go utilisée pour du montage vidéo ponctuellement, donc c'est
aussi un desktop (mais sans écran local, Í  distance).

Sur un client, le problème est différent et en général Linux me semble
s'en tirer mieux par défaut, s'il y a assez de RAM.

- j'envisage de gaver la machine en RAM et de supprimer le swap, est-ce
une bonne idée ?

Oui et non.

DéjÍ , le swap peut être utilisé pour les fonctions d'hibernation.

Ensuite, Linux utilise le swap aussi pour optimiser les I/O: imaginez un
gros processus endormi depuis des jours, sa mémoire serait plus utile au
buffer/cache. Ou pour pre-swapper afin de pouvoir répondre plus
interactivement Í  des besoins de l'utilisateur.

Si la vieille règle de deux fois plus de swap que de RAM des systèmes
BSD n'a jamais été valable sous Linux, on lit fréquemment des mises en
garde sur le risque de ne pas mettre de swap. D'autant plus que la
quantité de swap est un des paramètres de la gestion mémoire plus ou
moins agressive de Linux.

Actuellement, je mets en général 1x la RAM en swap, toutefois je vais
rarement au-delÍ  de 4 GB. Seulement dans des cas très particuliers de
systèmes embarqués je ne mets pas de swap, mais dans ce cas le besoin en
RAM des applications est largement assuré, sans pointes (assez
déterministe, en fait).

Dans votre cas précis, je recommanderais d'instrumenter la gestion
mémoire de votre machine, par exemple en tournant

vmstat 5

dans une console, ou installer munin et apache2 pour plus de détails
(recommandé sur un serveur seulement). Il y a peut-être d'autres outils
plus orienté desktop.

vmstat vous apprendra en temps réel si votre système swappe activement (en
général mauvais pour la performance si beaucoup de swap in; s'il n'y a
que du swap out c'est plutÍ´t une bonne nouvelle), la colonne wait vous
donnera aussi des idées sur la performance globale I/O.

Il faudrait aussi consulter le log kernel (dmesg) pour voir quelle
décision l'OOM killer a prise et pourquoi lorsque vous devrez Í  nouveau
décoincer Í  distance votre machine.

Ensuite, oui, ajouter de la RAM est toujours une bonne solution. Mais
avoir un swap de taille suffisante est aussi important.

Jo Engo , dans le message <rpqgdc$kdt$1@pasdenom.info>, a écrit :

Apparemment c'est cette page qui est gourmande.

Vérifie avec le task manager.

Le 27/11/2020 Í  10:20, Jo Engo a écrit :

Je ne retrouve plus le fil que j'avais initié, il est trop vieux sans
doute. Bon mon PC se fige encore de temps en temps mais lÍ  j'avais lancé
un htop en remote ce qui fait que j'ai pu épingler firefox, seulement 2
tabs actives dont https://www.mdph31.fr et 77% des ressources mémoire.
Apparemment c'est cette page qui est gourmande. Du coup le swap est plein
et le PC est quasi-complètement gelé (j'ai pu faire un killall firefox-esr
en remote) et qui m'a permis de reprendre la main puis j'ai lancé htop en
remote (ssh) sur mon autre machine puis j'ai relancé firefox-esr et
constaté les dégÍ¢ts.

J'ai le même problème ici : Le composant Lisio est le fautif. Noscript
est ton ami.

- Est-ce normal que ma machine se fige quasiment quand le swap est plein ?

Non. Normalement, Firefox tue un onglet qui réclame de la mémoire alors
que le swap est plein. Le noyau lui-même est sensé garder suffisamment
de mémoire sous le coude pour gérer correctement ce cas.

- j'envisage de gaver la machine en RAM et de supprimer le swap, est-ce
une bonne idée ?

Pas nécessairement. Ton problème est plutÍ´t dÍ» Í  Firefox et au noyau qui
font mal leur travail dans ce cas de figure. Il faut voir plutÍ´t avec
leur développeurs respctifs pour corriger ces comportements.

Le Fri, 27 Nov 2020 11:36:36 +0100, Marc SCHAEFER a écrit :

Sur un client, le problème est différent et en général Linux me semble
s'en tirer mieux par défaut, s'il y a assez de RAM.

Ceci étant il est possible que j'ai aussi des problèmes avec le
contrÍ´leur du disque qui aurait des vapeurs épisodiques. Ce qui me fait
penser ça et qu'il arrive que j'ai du lag de temps en temps et que ça
revienne rapidement fluide. Ce qui me fait penser ça est que j'avais
lancé plasma «par erreur» et que KFÞ me balançait des injurebox comme
quoi il attendait le disque. Je ne sais pas trop o͹ il faut que je
regarde ça. Je n'ai pas s.m.a.r.t du moins moins je ne trouve pas les
commandes adéquates avec apropos. J'avais lancé un moniteur smart mais il
ne m'avait détecté aucune erreur.


--

<inflam> tcpdump est une comamnde interdite ? est ce que je vais me faire
buster je l`utilise assez régulierement

Le Fri, 27 Nov 2020 11:52:40 +0000, Nicolas George a écrit :

Vérifie avec le task manager.

about:taskmanager me dit :
«Â Hum, cette adresse ne semble pas valide.

Vérifiez que l’URL est correcte puis réessayez. »

Ceci étant, j'avais seulement cet onglet et un autre actif, et
l'occupation de mémoire de FF est montée aux alentour de 77% au lieu de
20% habituellement tandis que la machine était sur les genoux. Je tue FF
et je le relance donc c'est le seul onglet actif, et la mémoire augmente
inexorablement jusqu'Í  77% et que je tue de nouveau le processus. Je peux
faire un test avec seulement cet onglet si tu estimes que c'est utile
mais je n'ai pas trouvé le task manager de firefox.



--

<Obelix_> pour augmenter les perfs, ce qui est pas mal c de mettre le
swap sur un ramdisk

Le Fri, 27 Nov 2020 11:52:40 +0000, Nicolas George a écrit :

Vérifie avec le task manager.

about:performance, je n'étais pas aidé je suis tombé sur la page d'un
windowsien. Bon au temps pour moi, la page ne fait pas bien lourd, (40.4M
et ça ne bouge pas) et FF plafonne Í  11% de mémoire totale ce n'était
donc pas ce site qui posait problème (ou alors le webmaster a corrigé
entre temps :p)


--
La pire chose que vous puissiez faire Í  l'homme
qui vous a pris votre femme, c'est de la lui laisser.
-+- Sacha Guitry -+-

Le Fri, 27 Nov 2020 14:30:26 +0100, David Larochette a écrit :

J'ai le même problème ici : Le composant Lisio est le fautif.

Connait pas. Il fut un temps o͹ j'étais un no-scrip king, mais ça m'a
passé, je considère ça comme une perte de temps, mais je peux m'y
remettre (et casser tous les sites en ajax par un clic)




--
S'il fallait permettre aux autres tout ce que l'on
se permet Í  soi-même, l'existence serait intenable.
-+- Eugène Labiche (1815-1888) -+-

Le Fri, 27 Nov 2020 15:00:51 +0000, Jo Engo a écrit :

about:performance, je n'étais pas aidé je suis tombé sur la page d'un
windowsien. Bon au temps pour moi, la page ne fait pas bien lourd,
(40.4M et ça ne bouge pas) et FF plafonne Í  11% de mémoire totale ce
n'était donc pas ce site qui posait problème (ou alors le webmaster a
corrigé entre temps :p)

En fait ça a recommencé, toujours sur cette page, en fait il fallait que
je clique sur le lien "contact" la mémoire s'est mise Í  monter en flêche
le pointeur se bloquer ce qui fait que je n'ai même pas pu accéder au
gestionnaire de tÍ¢che :( je recommence l'expérience en laissant les 2
fenêtres cÍ´te Í  cÍ´te.



--
Deux augures ne peuvent se regarder sans rire.
-+- Cicéron (106-43 avant JC) -+-