Mémoire on Zwindler's Reflection

Redis, MongoDB, RabbitMQ, désactiver les Transparent Huge Pages

Mon, 10 Feb 2020 07:30:00 +0000

Transparents Huge Pages

Les THP et moi, ça remonte à quelques années (i.e.n un brouillon qui traîne depuis longtemps); Mais j’ai de nouveau eu besoin de toucher aux Transparent Huge Pages il y a peu donc c’est une bonne occasion de m’y remettre.

Redis, MongoDB, RabbitMQ, Kafka… Tout ces logiciels vous demandent, à l’installation ou dans la documentation, de désactiver ce paramètre système de vos serveurs Linux.

01-07-2020 03:46:32.730 +0000 WARN ulimit - ulimits: This instance is running on a machine that has kernel transparent huge pages enabled. This can significantly reduce performance and is against best practices. Turn off kernel transparent huge pages using the method that is most appropriate for your Linux distribution. Même dmesg me dit de le désactiver :'(

Dans cet article, je vais vous montrer à quoi ça sert, mais surtout comment on va faire pour le désactiver (le plus proprement possible).

Mais au fait, c’est quoi ?

Avant de lui couper la chique, le mieux c’est quand même peut-être de savoir de quoi il s’agit avant de respecter les précos des éditeurs.

Note : Ca me fait penser à SELinux, la première chose qu’on nous demande de désactiver quand on installe un progiciel sur RHEL et qu’on connaît au final assez mal…

Pour faire bref, la gestion de la mémoire par le CPU passe par une couche d’abstraction : la mémoire est découpée en pages de taille fixe (par défaut 4ko) et le CPU garde une table de correspondance de ces pages dans la MMU.

Pour des raisons de performance, il peut être intéressant, sur nos systèmes récents ayant beaucoup de RAM, d’avoir des pages plus grosses pour faciliter le travail du CPU (aka des “huge pages”). Cependant, il est nécessaire de modifier le code de l’application pour tirer parti des HugePages. Arrive alors une autre couche d’abstraction, les Transparent Huge Pages. Vous avez deviné, pour faire ça de manière transparente !

Je vous met en bas de l’article quelques liens pour comprendre en détail de quoi on parle.

Oneshot

Maintenant qu’on sait ce que c’est, on peut le désactiver en tout quiétude.

Déjà, on va commencer par vérifier l’état de notre OS, pour savoir un peu où on en est au niveau des THP. Pour ça, un simple cat de /sys/kernel/mm/transparent_hugepage/enabled nous donnera l’info :

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Il existe 3 valeurs possibles pour ce paramètre : always, madvise et never. always et never sont simples à comprendre, et pour ce qui est de madvise, il s’agit d’un paramètre intermédiaire qui dit que par défaut, les THP sont désactivées, mais que les applications peuvent utiliser un appel “madvise” pour allouer des THP dans la zone mémoire réservée pour ça.

Ici, on va donc vouloir désactiver les THP totalement (donc never).

Pour se faire, on peut simplement utiliser la commande suivante :

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Attention cependant, le paramètre ne sera pris en compte que jusqu’au prochain reboot.

Les méthodes classiques pour désactiver durablement les THP

A partir de là, on va vouloir le désactiver pour les prochains boots. On va donc devoir indiquer d’une manière ou d’une autre à l’OS qu’il faut désactiver ce paramètre, activé par défaut.

La plupart des logiciels vous conseillent de faire un service qui ne fait que ça et qui sera lancé au démarrage de votre machine (ex. vertica, couchbase, …).

Je suis pas fan, je trouve que modifier un paramètre au démarrage ne devrait pas se faire comme ça.

La façon la plus “propre” de le faire est probablement de modifier la configuration du bootloader (souvent GRUB). Si vous avez GRUB, c’est assez facile de le faire puisque c’est une option à ajouter dans le grub :

cat /etc/default/grub
[...]
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300"
GRUB_CMDLINE_LINUX=""
[...]
## APRES
cat /etc/default/grub
[...]
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300 transparent_hugepage=never"
GRUB_CMDLINE_LINUX=""

Cependant, cette méthode nécessite de reconstruire votre fichier grub (avec grub2-mkconfig) donc j’imagine que c’est pour cela que cette méthode n’est pas mise en avant.

Une méthode alternative pour désactiver les transparent Huge Pages

Si vous ne vous sentez pas de modifier votre bootloader et que vous n’aimez pas, comme moi, l’idée de faire un service pour faire un echo au boot, il reste une dernière possibilité.

apt install sysfsutils
echo "kernel/mm/transparent_hugepage/enabled = never" >> /etc/sysfs.conf
echo "never" >> /sys/kernel/mm/transparent_hugepage/enabled

L’avantage, c’est que, contrairement à la modif du GRUB, ça va être ultra simple du coup d’automatiser ça avec Ansible. Je vais pouvoir intégrer la modification dans mes playbooks d’installation des logiciels cités en début d’article !

---
- hosts: all
become: yes
tasks:
- name: "Install sysfsutils"
apt:
name: "{{item}}"
state: present
loop:
- sysfsutils
- name: "Disable permanently Transparent Huge Pages"
lineinfile:
path: /etc/sysfs.conf
line: kernel/mm/transparent_hugepage/enabled = never
- name: "Disable THP for this boot"
shell: "echo 'never' >> /sys/kernel/mm/transparent_hugepage/enabled"

Et voilà :D

Sources

[En bref] Agrandissement de swap sous Linux

Sat, 06 Feb 2016 11:30:44 +0000

Agrandir la swap, pourquoi faire ?

Avec la montée en puissance de l’extension à chaud de RAM sur les machines virtuelles et l’explosion des tailles de JVM délirantes (20 Go pour un outil de gestion de projet pour 100 personnes. Allo…) il est de plus en plus simple de se dire :

Tiens, le vent souffle aujourd’hui, j’vais rajouter un peu de RAM à mes VMs.

Sauf qu’il arrive d’oublier les bonnes pratiques en vigueur dans votre propre contexte professionnel : 1 fois la RAM, 1,5 fois la RAM, 2 fois la RAM, 0,5 fois la RAM si on a plus de 8Go, 2Go quoiqu’il arrive (rayez les mentions inutiles).

Ça et les templates, pour qui on ne différencie pas toujours les gros des petits serveurs, par flemme.

Du coup, je me retrouve régulièrement à nettoyer des serveurs pour qui on a oublié d’agrandir la RAM après une extension. Et du coup, j’aime bien avoir sous la main la procédure pour le faire rapidement.

Les commandes pour le faire sous Linux (RHEL 6 en l’occurrence)

Afficher des informations sur la swap

swapon -s

Récupérer/retrouver le device qui porte la swap dans la fstab

grep swap /etc/fstab
/dev/VolGroup00/LogVol01 swap swap defaults 0 0

Vérifier que la swap n’est pas utilisée, ou à défaut, que toutes les pages swapées peuvent être stockées en mémoire sinon …!

free -m

Désactivation de la swap

swapoff -a

Agrandir le LV (si on a fait du LVM, sinon il faut agrandir ou créer une nouvelle partition ce qui peut être un peu plus casse pied) puis recréer le volume de swap à la nouvelle taille :

lvextend -L +4G /dev/VolGroup00/LogVol01
mkswap /dev/VolGroup00/LogVol01

Réactiver la swap

swapon -a

Vérifier la prise en compte

swapon -s
cat /proc/swaps #affiche la même chose mais j'aime bien

Bonus : techniques barbares pour faire le ménage

Je me rend le plus souvent compte que les serveurs n’ont pas les bonnes tailles de swap lorsque j’ai une alerte dans ma supervision.

Cycle en V : recherche des coupables

Souvent, les gros systèmes taillés au plus juste swappent un peu, quelques centaines de Mo de temps en temps, lorsqu’un gros traitement se déclenche et qu’on dépasse la quantité de mémoire totale prévue. Mais parfois cela peut assi être un processus qui perd la boule et qui se met à consommer un max de mémoire (avec la réduction drastique des performances qui vont avec en cas de swap).

Pour déterminer quel processus consomme le plus de swap sous Linux, on peut utiliser les commandes suivantes :

free -m
------total        used        free        shared        buffers        cached
Mem:           3948      3186         761                 0                 17             1593
-/+ buffers/cache:      1575      2372
Swap:           4000              0      4000

3948 la quantité totale de RAM du système
3186 et 761 représentent respectivement les quantités de RAM utilisée et disponible, sans tenir compte de ce qui est utilisable en cache/buffer
2372 représente la quantité réelle de mémoire disponible (soit pas du tout utilisée, soit dans un cache qui pourra être libéré si nécessaire)
1575 représente la quantité réellement utilisée par les processus

Si votre système est récent (procps-ng) l’affichage sera un peu différent car les buffers et le cache ont été regroupés dans une même colonne, sur la même ligne que la mémoire. Et c’est tant mieux car c’est plus clair comme ça, je trouve :

free -m
------total        used        free      shared  buff/cache   available
Mem:               993         353       329              37              309           447
Swap:            2079             0       2079

993 la quantité totale de RAM du système
353 représente la quantité réellement utilisée par les processus
329 représente la quantité de mémoire pas du tout utilisée (ni par des processus, ni par des caches)
447 représente une estimation de la quantité réelle de mémoire disponible pour d’autres processus avant que le système ne se mette à swaper (soit pas du tout utilisée, soit dans un cache qui pourra être libéré si nécessaire)

Dans certaines versions de top, il est possible d’obtenir un tri par processus de l’utilisation de la swap, notamment avec RHEL/CentOS, jusqu’à version 6 qui utilise procps :

top
O #o majuscule
p #p minucule
[touche entrée]

La commande top devrait alors lister les processus en fonction de leur utilisation de SWAP

PID USER PR VIRT NI SHR SWAP S %CPU %MEM TIME+ RES COMMAND
4390 root 18 2449m 0 2276 2.0g S 0 9.3 185:11.98 367m mrmonitord
4316 root 34 1566m 19 1976 1.1g S 0 10.7 4:15.62 423m yum-updatesd
4385 root 18 1141m 0 1476 1.1g S 0 0.6 423:19.03 23m java
22009 apache 15 385m 0 4708 360m S 0 0.6 0:20.40 25m httpd

Cependant, cet affichage n’est pas totalement exact et c’est pour cela que cette fonction n’existe pas toujours dans top. C’est notamment vrai pour les dernières versions de Debian/Ubuntu et de RHEL 7 qui utilisent procps**-ng**.
Personnellement je trouve que ça donne un bon aperçu des processus qui sont en train de swapper en cas de recherche d’un coupable. Si vous voulez plus d’information là dessus, je vous conseille de lire la partie « A note about top command » de cet article.

Faire un peu de ménage

Certains d’entre vous trouveront peut être plus simple de le relancer (quand cela est possible). Ceci pourrait rendre de la mémoire au serveur qui se mettra à arrêter de swapper. Pour autant, la mémoire swappée ne sera pas forcément rendue, et l’alerte en supervision restera présente même si l’incident est terminé…

Du coup, voici quelques tips supplémentaires pour faire du ménage dans les caches pour libérer la mémoire réservée mais pas forcément nécessaire :

Libération du pagecache

echo 1 > /proc/sys/vm/drop_caches

Libération des dentries et des inodes

echo 2 > /proc/sys/vm/drop_caches

Tout libérer d’un coup

echo 3 > /proc/sys/vm/drop_caches

Tout péter

Si vous vous sentez d’humeur guerrière et que vous pensez que tout ce qui est dans la swap peut re-rentrer en RAM, vous pouvez toujours désactiver la swap. Ceci aura pour effet de vider complètement la swap et donc de tout rappatrier en RAM. Il va sans dire que si vous vous êtes trompé, le système se bloquera et vous pourrez appuyer longuement sur le bouton « Power ».

swapoff -a #extinction de la swap
swapon -a #relance de la swap

Vous voilà prévenus ;)