Mémoire et swap : quand passer à un palier supérieur

« 120 Mo libres sur 2 Go » effraie les débutants et ne veut rien dire sous Linux : le système utilise délibérément la mémoire libre pour le cache de fichiers, car une mémoire vide ne sert à rien. Une autre colonne donne la vraie image.

Lire correctement free

free -h
#               total  used   free  shared  buff/cache  available
# Mem:          1.9Gi  742Mi  102Mi    18Mi       1.1Gi      1.0Gi
# Swap:         1.0Gi  126Mi  898Mi

Regardez available — la quantité de mémoire qu'une application peut obtenir en évincant le cache. Tant que cette valeur reste bien au-dessus de zéro, la machine va bien. free en ce sens est inutile.

Signaux d'alerte :

• available est inférieur à 10 % de total ;
• Swap used augmente et n'est pas libéré ;
• dans vmstat 2, si/so sont non nuls et constants — le système pagine en continu sur le disque.

Ce qui consomme exactement la mémoire :

ps aux --sort=-%mem | head -10
smem -tk -s uss 2>/dev/null | tail -10

Swap : nécessaire ou non

Un petit swap est utile à n'importe quel palier : il donne au système de la place pour déplacer les pages inutilisées depuis longtemps et protège contre la mort instantanée d'un processus lors d'un pic court. Ce n'est pas un remplacement de la mémoire — un disque est des centaines de fois plus lent.

Créez un fichier de swap de 2 Go :

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Freinez l'empressement du système à swapper :

sysctl -w vm.swappiness=10
echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf

Gardez à l'esprit que le fichier de swap occupe de l'espace sur le disque du palier (40 Go sur VDS-1), et que l'écriture dessus consomme de la bande passante disque, voir Charge disque.

Fuite ou mémoire insuffisante

Le graphique de mémoire dans le panneau /hosting/vds/m/<id> sur une échelle hebdomadaire aide à distinguer l'un de l'autre :

• En dents de scie — monte jusqu'au plafond, chute au redémarrage du service, remonte. C'est une fuite dans l'application ; un palier supérieur ne fera que repousser le problème.
• Un plateau plat au plafond dès le départ — l'ensemble de travail n'a tout simplement pas assez de place.
• Une chute brutale — l'OOM killer a tué le processus ; voir l'article Mémoire insuffisante.

Avant de changer de formule, occupez-vous de l'évident : limitez SystemMaxUse pour le journal, fixez des limites raisonnables pour la base de données (MySQL en demande pas mal par défaut), supprimez les services inutilisés (systemctl list-units --type=service --state=running) et réduisez le nombre de workers pour PHP-FPM et Gunicorn.

Quand passer à un palier supérieur

Si après le nettoyage available reste proche de zéro pendant des semaines, que le swap est constamment utilisé et que vous avez besoin de l'application dans son ensemble, prenez un palier supérieur. La mémoire augmente selon la série 2, 4, 8, 16, 24, 32 Go. Les upgrades se font uniquement vers le haut, avec un paiement supplémentaire pour les jours restants ; les downgrades ne sont pas disponibles : le disque ne rétrécit pas. Pour plus de détails, voir l'article Changement de formule.

Erreurs courantes

• Désactiver complètement le swap. Lors d'un pic, le système tuera le processus au lieu de survivre une minute.
• Faire un swap de la taille du disque. La machine ne mourra pas, mais elle rampera pendant des heures, ce qui est pire qu'un crash rapide.
• Regarder VIRT dans htop. La taille virtuelle pour JVM, PostgreSQL et Node est énorme et ne reflète pas la consommation. Regardez RES.

Vous devez vérifier la mémoire avant une panne, pas après. Configurez des alertes par seuil — il y a une recette simple dans l'article Alertes d'indisponibilité du site.