Vous lancez free -h sur un serveur et la colonne free affiche presque zéro. Pourtant, les applications répondent encore correctement et aucune erreur mémoire n’apparaît. Ce résultat est fréquent : Linux utilise la RAM inutilisée comme cache, puis en récupère une partie quand un processus en a besoin.
Pour savoir si la machine manque réellement de mémoire, regardez d’abord available, puis la swap et l’activité mémoire dans le temps. Une seule valeur used ne suffit pas. Voici la méthode que j’utilise avant d’arrêter un service ou d’ajouter de la RAM.

Commencer par free -h et la colonne available
La commande de base ne demande aucun droit administrateur :
free -h
L’option -h choisit automatiquement une unité lisible, par exemple MiB ou GiB. Sur la ligne Mem, commencez par ces trois colonnes :
total: la mémoire utilisable connue du noyau ;available: l’estimation de la mémoire qu’un nouveau processus peut obtenir sans provoquer de swap ;free: les pages totalement inutilisées à cet instant.
available est généralement plus utile que free. Le noyau sait libérer une partie du cache et des structures récupérables. Une machine avec 300 MiB dans free mais 4 GiB dans available n’est pas à court de RAM.
Lire used, shared et buff/cache sans les additionner
Les colonnes de free ne correspondent pas à des tiroirs indépendants qu’il faudrait additionner. Sur les versions récentes de procps-ng, used est calculé à partir de total et available. Ce n’est donc pas la somme exacte de la mémoire RSS de tous les processus.
sharedreprend principalement la mémoire utilisée partmpfs;bufferscouvre des tampons du noyau ;cacheinclut notamment le cache de fichiers et des structures récupérables ;buff/cacheregroupe les tampons et le cache dans l’affichage standard.
Pour séparer buffers et cache, utilisez l’affichage large :
free -w -h
Cette vue aide à comprendre la répartition, mais elle ne change pas le diagnostic : la question reste de savoir combien de mémoire peut être récupérée sans swap, puis si cette marge diminue durablement.
Pourquoi Linux remplit la RAM avec du cache
Relire un fichier depuis la RAM coûte moins cher que le relire depuis un SSD ou un disque dur. Linux conserve donc des données récemment utilisées dans le cache de pages. Tant qu’aucune application ne réclame cet espace, le laisser vide n’apporte aucun avantage.
Ne videz pas les caches avec drop_caches pour faire remonter artificiellement la colonne free. Vous supprimez un cache utile et vous forcez le système à relire les données. Cette opération sert surtout à des tests contrôlés, pas à l’entretien courant d’un serveur.
Vous pouvez confirmer la source des valeurs dans /proc/meminfo :
grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SReclaimable|SwapTotal|SwapFree):' /proc/meminfo
MemAvailable est une estimation produite par le noyau. Elle tient compte de la mémoire libre et d’une partie des caches récupérables, sans supposer que tout le cache peut être repris immédiatement.
Choisir les unités et observer plusieurs échantillons
Pour comparer plusieurs machines ou alimenter un relevé, gardez une unité fixe. -m affiche des mébioctets. Pour des unités décimales, ajoutez --si :
free -m
free -h --si
Évitez aussi de conclure à partir d’une capture isolée. free peut répéter le relevé toutes les deux secondes et s’arrêter après cinq mesures :
free -h -s 2 -c 5
Regardez si available baisse continuellement, si la swap progresse et si la situation revient à la normale après la fin d’un traitement. Une chute brève pendant une sauvegarde ou une compilation n’a pas le même sens qu’une baisse continue sur plusieurs heures.
Croiser la RAM avec la swap et vmstat
La ligne Swap de free indique son occupation, mais pas son activité. Quelques gigaoctets utilisés depuis longtemps ne prouvent pas que la machine échange encore des pages. Listez les zones actives, puis observez si et so avec vmstat :
swapon --show
vmstat 1 5
Dans vmstat, ignorez la première ligne pour l’activité instantanée : elle représente des moyennes depuis le démarrage. Les lignes suivantes montrent les échantillons. Des valeurs répétées dans si ou so, associées à un available faible et à des ralentissements, indiquent une vraie pression mémoire.
Le guide sur la swap sous Linux explique quand son occupation est normale et pourquoi la vider sans marge RAM peut bloquer la machine.
Trouver les processus qui consomment réellement la mémoire
Si les indicateurs confirment une tension, identifiez les processus avant d’agir :
ps -eo pid,user,comm,%mem,rss --sort=-rss | head
htop
RSS mesure la mémoire physique résidente d’un processus, mais certaines pages peuvent être partagées entre plusieurs processus. Additionner toutes les valeurs RSS peut donc surévaluer la consommation réelle. Utilisez cette liste pour repérer une piste, puis vérifiez le service, sa configuration et ses logs.
Dans htop, triez par mémoire, récupérez le PID et le nom du service, puis contrôlez son état :
systemctl status service-concerne --no-pager
journalctl -u service-concerne -n 100 --no-pager
Ne tuez pas le premier processus en tête de liste. Une base de données utilise souvent la RAM comme cache applicatif et peut respecter sa configuration. Vérifiez d’abord si la consommation est stable, attendue et libérée quand la charge baisse.
Quand conclure qu’il manque vraiment de la RAM
Un manque de mémoire devient crédible quand plusieurs signaux se recoupent : available reste très bas, vmstat montre des échanges répétés, les temps de réponse se dégradent et le noyau signale éventuellement l’OOM killer.
journalctl -k -b | grep -Ei 'out of memory|oom-killer|killed process'
dmesg -T | grep -Ei 'out of memory|oom-killer|killed process'
Dans ce cas, corrigez la cause : limite mémoire mal réglée, fuite d’un service, charge devenue trop forte ou dimensionnement insuffisant. Ajoutez de la swap seulement comme filet de sécurité, pas comme remplacement d’une RAM durablement saturée. La page de manuel de free documente les calculs de ses colonnes, tandis que proc_meminfo(5) décrit les compteurs fournis par le noyau.