RAM, zram et swap sur une machine IA : les trois voleurs qui nous coûtaient un facteur dix

Un modèle qui ne tient pas entièrement en VRAM garde une partie de lui-même en RAM (voir Le matériel, honnêtement). Alors la vitesse de la RAM, c'est la vitesse du modèle. Le nôtre se traînait à 1,9 jeton par seconde ; la carte, le lien PCIe et la quantification allaient bien. Trois choses volaient la RAM.

Comment ces chiffres ont été obtenus. Mesurés sur nos propres machines (voir le protocole), en général en un seul passage, vitesses relevées par le serveur lui-même ; nous ne publions pas les journaux bruts. Ce sont des ordres de grandeur sur ce matériel, pas des garanties sur le vôtre. Les chiffres extérieurs sont accompagnés de leur source.

Un peu d'histoire

Le swap, écrire des pages de mémoire sur le disque quand la RAM manque, est aussi vieux que la mémoire virtuelle. zram, intégré au noyau Linux en 2014, propose une autre voie : un bloc de RAM compressé utilisé comme swap, si bien que les pages sont tassées plutôt qu'écrites sur un disque lent. C'est rapide et gratuit, mais c'est toujours de la RAM : trop grand, il vole les modèles mêmes qu'il devait aider.

Voleur 1 : un zram à la taille de toute la RAM

zram, c'est du swap compressé en RAM. Certaines distributions le dimensionnent par défaut à toute la RAM. Sur un bureau normal, il compresse environ trois pour un et c'est une bonne affaire. Sur une machine IA, ce qui part en swap, ce sont les pages du fichier du modèle, déjà compressées par la quantification : le nôtre compressait à 1,14 pour un. zram occupait 35,8 Go de vraie RAM pour en économiser 5, et ces pages étaient justement le cache qui gardait le modèle rapide.

Vérifiez, puis plafonnez-le dans /etc/systemd/zram-generator.conf (qui prime sur le fichier de la distribution) :

cat /sys/block/zram0/mm_stat     # octets stockés contre octets réellement occupés
# /etc/systemd/zram-generator.conf
[zram0]
zram-size = 16384

sudo swapoff /dev/zram0
sudo systemctl restart systemd-zram-setup@zram0.service

Voleur 2 : une application qui fuit

Une de nos apps de génération d'images grossissait d'environ 30 Go en 25 heures, file vide. Ce n'est pas un cache utile, c'est une fuite : surveillez la mémoire résidente de vos applications qui tournent longtemps comme un compteur qui monte, et redémarrez à heure fixe celles qui fuient.

ps -eo rss,etime,comm --sort=-rss | head

Voleur 3 : le tueur de mémoire pointé sur le modèle

Des outils comme earlyoom tuent un processus avant que le système ne gèle. Le nôtre avait été réglé pour tuer de préférence le serveur du modèle, et protéger tout le reste. Lisez vos réglages (/etc/default/earlyoom) : le modèle devrait être le dernier à mourir, pas le premier.

Deux choses de plus à savoir

Arrêter un conteneur de modèle qui a chargé son fichier par mmap ne rend pas la RAM : le fichier reste dans le cache de pages (buff/cache dans free). sync; echo 3 | sudo tee /proc/sys/vm/drop_caches le libère, ce que nous avons mesuré à 46 Go.

Quatre barrettes de deux kits différents tournaient à 3 600 MT/s au lieu de 6 000 sur notre carte mère : environ 40 % de bande passante en moins pour un modèle qui lit ses experts en RAM à chaque jeton. Deux barrettes appairées sont souvent plus rapides que quatre mélangées.

Le swap n'est pas une règle unique pour toutes les machines. Une VM qui porte une base de données veut une swappiness basse (garder ses pages chaudes en RAM, le swap n'est qu'une soupape) ; une petite VM avec des pics veut la valeur par défaut. Et swapon --show lancé sans privilèges n'affiche rien au lieu d'une erreur : lisez /proc/swaps, qui dit la vérité. Testez un changement de fstab avec swapoff -a && swapon -a plutôt qu'en redémarrant.

Sources

• zram, Linux kernel documentation

Utile ? Dites-nous ce qu'il faut mesurer ensuite.