Anomalie #4452
ferméAméliorer la gestion du swap
0%
Description
Actuellement :
total (Mo) used (Mo) free (Mo) swappiness vfs_cache_pressure ===== bastion ===== Swap: 1019 22 997 60 100 ===== admin ===== Swap: 1019 104 915 60 100 ===== dns ===== Swap: 1019 0 1019 60 100 ===== mail ===== Swap: 1019 130 889 60 100 ===== sympa ===== Swap: 1019 13 1006 60 100 ===== lamp ===== Swap: 1019 12 1007 60 100 ===== pad ===== Swap: 1019 44 975 60 100 ===== pouet ===== Swap: 1019 222 797 60 100 ===== libreoffice ===== Swap: 1019 0 1019 60 100 ===== valise ===== Swap: 1019 132 887 60 100 ===== xmpp ===== Swap: 1019 1 1018 60 100 ===== drop ===== Swap: 1019 83 936 60 100 ===== allo ===== Swap: 1019 44 975 60 100 ===== maine.chapril.org ===== Swap: 6143 420 5723 60 100 ===== coon.chapril.org ===== Swap: 6143 0 6143 60 100 ===== icinga2.chapril.org ===== Swap: 487 31 456 60 100
Pour rappel, vm.swappiness=0 signifie : « n'utiliser le swap que pour éviter un OOMKILL ».
Une confiance naturelle envers le noyau consisterait à penser qu'il pourrait faire du swap intelligent (mettre en swap des pages mémoires excessivement rarement utilisées) pour se donner plus de place pour les pages buffer/cache/etc. Par défaut oui. Mais on peut s'interroger sur la quantité de pages concernées. A priori, on peut penser que c'est faible et donc que l'on peut s'en passer. En conséquence, l'approche de « n'utiliser le swap que pour éviter un OOMKILL » semble totalement acceptable.
Sur le SI April, on a vm.swappiness=1 et on étudie la pertinence de passer à vm.swappiness=0 (ticket #4450).
Demande : passer vm.swappiness=0 sur toutes les machines (pm + vm) du SI Chapril.
Note : déploiement via le paquet Chapril avec un fichier dans /etc/sysctrl/chapril.conf (méthode similaire au paquet eeinstall) ?