Commandes et outils pour vérifier la consommation de RAM sous Linux

La surveillance de l’utilisation de la RAM sous Linux consiste à interroger le sous-système mémoire du noyau pour récupérer des métriques sur l’allocation de la mémoire physique, l’utilisation du swap et les tailles de jeu résident par processus. Les méthodes les plus directes utilisent des utilitaires intégrés — free, top, htop, ps, vmstat et smem — chacun exposant une couche différente de la hiérarchie mémoire, des totaux à l’échelle du système jusqu’à la taille de jeu proportionnel (PSS) par processus.

Une pression mémoire excessive déclenche le mécanisme Linux Out-of-Memory (OOM) killer, qui termine de force des processus pour récupérer de la RAM. Comprendre quelles commandes révèlent quelles métriques — et ce que ces métriques signifient réellement — fait la différence entre une gestion réactive des incidents et une gestion proactive des capacités. Ce guide couvre tous les outils majeurs, les sources de données du noyau qu’ils lisent, et les cas particuliers qui surprennent même les administrateurs expérimentés.

Pourquoi la surveillance de la RAM est importante sur les serveurs Linux

La gestion de la mémoire Linux est délibérément agressive. Le noyau utilise toute la RAM disponible comme cache de pages pour accélérer les E/S disque, ce qui signifie qu’un système signalant une mémoire libre quasi nulle n’est pas nécessairement sous pression — il peut simplement mettre en cache efficacement. Mal interpréter ce comportement est l’une des erreurs les plus courantes lors de la lecture des chiffres bruts de mémoire.

Principales raisons de surveiller la RAM en continu :

• Prévention de l’OOM killer : Identifier les processus gourmands en mémoire avant que le noyau ne termine les services critiques.
• Détection de l’utilisation du swap : Une activité de swap intense indique un épuisement de la RAM et provoque une latence d’E/S sévère.
• Diagnostic des fuites mémoire : Les processus dont le RSS augmente régulièrement au fil du temps signalent des fuites au niveau applicatif.
• Planification de capacité : Les données de tendance informent les décisions concernant la mise à l’échelle verticale ou la redistribution des charges de travail.
• Optimisation des performances : L’ajustement de vm.swappiness, des huge pages et de la topologie NUMA nécessite des données mémoire de référence.

Dans un environnement d’Hébergement VPS où les ressources sont partagées ou limitées par les contraintes de l’hyperviseur, une surveillance précise de la RAM est particulièrement critique — atteindre un plafond mémoire dégrade silencieusement les performances avant qu’une alerte ne se déclenche.

Comprendre la terminologie mémoire Linux

Avant d’exécuter une commande, vous devez comprendre ce que représentent réellement les colonnes de sortie.

Point crucial : Utilisez toujours la colonne Available de free -h, et non la colonne Free, pour évaluer si un système dispose de suffisamment de RAM pour une nouvelle charge de travail. La colonne Free ignore le cache récupérable, ce qui conduit à de fausses alarmes.

Le fichier /proc/meminfo : la source faisant autorité

Chaque outil décrit dans cet article lit depuis /proc/meminfo, un fichier virtuel maintenu par le noyau en temps réel. L’inspecter directement vous donne les données les plus granulaires disponibles :

cat /proc/meminfo

Champs clés à surveiller :

• MemTotal — RAM totale utilisable
• MemFree — RAM complètement inactive
• MemAvailable — RAM estimée disponible pour les nouveaux processus
• Buffers — cache de blocs disque brut
• Cached — cache de pages pour les fichiers
• SwapTotal / SwapFree — capacité et disponibilité du swap
• Dirty — mémoire en attente d’écriture sur disque (des valeurs élevées indiquent une pression d’E/S)
• HugePages_Total / HugePages_Free — état d’allocation des huge pages
• Slab — cache de structures de données du noyau (peut devenir important sur les serveurs NFS ou de bases de données très sollicités)

Comprendre /proc/meminfo vous permet d’interpréter la sortie de chaque autre outil avec un contexte complet.

Vérifier la RAM avec la commande free

free est le moyen le plus rapide d’obtenir un instantané mémoire à l’échelle du système. Il lit directement depuis /proc/meminfo et formate la sortie dans un tableau lisible par l’homme.

Utilisation de base

free

La sortie est en kilo-octets par défaut. Utilisez des indicateurs pour des formats plus lisibles :

free -h        # Human-readable (MB/GB)
free -m        # Output in megabytes
free -g        # Output in gigabytes
free -s 5      # Refresh every 5 seconds (continuous monitoring)
free -h --si   # Use SI units (1000-based) instead of binary (1024-based)

Explication de l’exemple de sortie

              total        used        free      shared  buff/cache   available
Mem:           15Gi       4.2Gi       1.1Gi       312Mi       9.8Gi       10.9Gi
Swap:         2.0Gi       128Mi       1.9Gi

Dans cet exemple, le système semble n’avoir que 1,1 Go de libre, mais 10,9 Go sont réellement disponibles pour les nouveaux processus car le noyau récupérera le buff/cache à la demande. C’est la chose la plus importante à comprendre concernant la sortie de free.

Cas particulier : l’utilisation du swap comme signal d’avertissement

Même une petite quantité d’utilisation du swap (Swap: used > 0) sur un serveur de production mérite une investigation. Cela signifie que le noyau a déjà décidé que certaines pages mémoire sont mieux stockées sur disque qu’en RAM — un signe que le jeu de travail dépasse la mémoire physique.

Vérifier la RAM avec la commande top

top fournit une vue en temps réel continuellement mise à jour de l’utilisation des ressources système, combinant les statistiques CPU et mémoire avec une liste de processus classés.

top

Champs mémoire clés dans top

En haut de l’interface top, deux lignes affichent les statistiques mémoire :

MiB Mem :  16384.0 total,   1126.4 free,   4301.2 used,  10956.4 buff/cache
MiB Swap:   2048.0 total,   1920.0 free,    128.0 used.  11200.0 avail Mem

Dans le tableau des processus, les colonnes mémoire les plus pertinentes sont :

• VIRT — taille de la mémoire virtuelle (équivalent VSZ)
• RES — mémoire physique résidente (RSS)
• SHR — portion de mémoire partagée de RES
• %MEM — pourcentage de la RAM physique totale utilisée

Commandes interactives utiles de top

Exécuter top en mode non interactif

Pour les scripts et la capture de journaux, exécutez top en mode batch :

top -b -n 1 | head -30

Cela produit un instantané unique — utile pour les scripts de surveillance basés sur cron.

Vérifier la RAM avec htop

htop est un visualiseur de processus amélioré basé sur ncurses qui présente les mêmes données sous-jacentes que top avec une interface significativement plus utilisable. Il n’est pas installé par défaut sur la plupart des distributions.

Installation

# Debian / Ubuntu
apt-get install htop

# RHEL / CentOS / AlmaLinux / Rocky Linux
yum install htop
# or on newer versions:
dnf install htop

# Alpine Linux
apk add htop

Ce que htop apporte de plus que top

• Barres mémoire codées par couleur distinguant d’un coup d’œil la mémoire utilisée, les tampons et le cache
• Vue arborescente des processus horizontale et verticale (F5)
• Support de la souris pour cliquer et faire défiler
• Sélection multiple pour la gestion groupée des processus
• Recherche intégrée (F3) et filtre (F4) sans mémoriser les raccourcis clavier
• Affichage direct de la mémoire disponible en évidence dans l’en-tête

Légende des couleurs de la barre mémoire de htop

Conseil pro : Dans htop, appuyez sur F2 (Setup) > Display Options > activez « Show CPU frequency » et « Detailed CPU time » pour une image plus complète aux côtés des données mémoire.

Vérifier la RAM avec la commande ps

ps (statut des processus) interroge la table des processus du noyau et peut être trié et filtré pour identifier les principaux consommateurs de mémoire à un instant donné.

Trier les processus par consommation mémoire

ps aux --sort=-%mem

Explication des colonnes de sortie

Commandes pratiques en une ligne

Afficher les 10 processus consommant le plus de mémoire avec une sortie lisible par l’homme :

ps aux --sort=-%mem | head -11

Afficher l’utilisation mémoire pour un nom de processus spécifique (par exemple, Apache) :

ps aux | grep apache2 | awk '{sum += $6} END {print sum/1024 " MB"}'

Cela additionne les valeurs RSS de tous les processus worker apache2 — essentiel pour comprendre l’empreinte réelle des serveurs web multi-processus.

Mise en garde importante : ps affiche le RSS, qui double-compte les bibliothèques partagées. Si 20 workers Apache mappent chacun la même bibliothèque partagée de 50 MB, ps signale 1 000 MB d’utilisation de bibliothèque partagée entre eux, alors que le coût physique réel n’est que de 50 MB. Utilisez smem pour une comptabilisation précise.

Vérifier la RAM avec smem

smem est l’outil de comptabilisation mémoire par processus le plus précis disponible sur Linux car il rapporte le PSS (Proportional Set Size) — la mémoire partagée est divisée proportionnellement entre tous les processus qui la mappent, éliminant le problème de double comptage inhérent aux outils basés sur le RSS.

Installation

# Ubuntu / Debian
apt-get install smem

# CentOS / RHEL 7
yum install smem

# RHEL 8+ / AlmaLinux / Rocky Linux
dnf install smem

# Alternatively, install via pip
pip install smem

Utilisation de base

smem

Options utiles de smem

smem -r              # Sort by RSS (descending)
smem -s pss -r       # Sort by PSS (most accurate, descending)
smem -u              # Aggregate by user
smem -m              # Show system-wide memory map
smem -p              # Show percentages instead of raw KB
smem -k              # Show values in KB
smem -t              # Show totals row
smem --pie name      # Generate a pie chart (requires matplotlib)
smem -P apache2      # Filter by process name pattern

PSS vs RSS : pourquoi c’est important

Considérons un serveur exécutant 10 processus worker Node.js, partageant chacun une bibliothèque runtime V8 de 100 MB :

• RSS par processus : 200 MB (100 MB partagés + 100 MB privés)
• RSS total rapporté : 2 000 MB
• PSS par processus : 110 MB (10 MB de part des 100 MB + 100 MB privés)
• PSS total rapporté : 1 100 MB
• RAM physique réellement utilisée : 1 100 MB

Le RSS surestime l’utilisation de près de 2x dans ce scénario. Lors de décisions de mise à l’échelle sur un Serveur Dédié, utiliser le PSS de smem vous donne la vérité terrain.

Vérifier la RAM avec vmstat

vmstat (statistiques de mémoire virtuelle) fournit une vue plus large de l’activité mémoire, swap, E/S et CPU, ce qui le rend idéal pour diagnostiquer la pression mémoire à l’échelle du système plutôt que les problèmes de processus individuels.

vmstat 2 10    # Report every 2 seconds, 10 times

Colonnes mémoire clés

Signal critique : Des valeurs non nulles de si (swap-in) et so (swap-out) dans un flux vmstat en cours d’exécution indiquent un swapping actif — un signe définitif d’épuisement de la mémoire. Même des pics occasionnels de so peuvent provoquer des pics de latence applicative de plusieurs centaines de millisecondes.

Vérifier la RAM avec sar (System Activity Reporter)

sar du package sysstat enregistre les données mémoire historiques, permettant une analyse rétrospective — quelque chose que les outils en temps réel ne peuvent pas fournir.

Installation

apt-get install sysstat    # Debian/Ubuntu
yum install sysstat        # CentOS/RHEL

Utilisation

sar -r 1 5          # Memory stats every 1 second, 5 times
sar -r -f /var/log/sysstat/sa$(date +%d)   # Today's historical data
sar -S 1 5          # Swap statistics

sar est inestimable pour répondre à des questions comme « Y a-t-il eu un pic mémoire à 3h du matin qui a causé le crash de l’application ? » — une question à laquelle aucun outil en temps réel ne peut répondre après coup.

Vérifier la RAM avec /proc/<PID>/status et /proc/<PID>/smaps

Pour une analyse approfondie par processus, le noyau expose des cartes mémoire détaillées directement dans /proc.

Vérification rapide de la mémoire par processus

cat /proc/$(pgrep nginx | head -1)/status | grep -E "VmRSS|VmPeak|VmSize|VmSwap"

Exemple de sortie :

VmPeak:   512340 kB
VmSize:   498120 kB
VmRSS:    102400 kB
VmSwap:        0 kB

• VmPeak — taille maximale de mémoire virtuelle jamais atteinte par ce processus
• VmRSS — taille actuelle du jeu résident
• VmSwap — quelle partie de ce processus a été swappée

Carte mémoire détaillée avec smaps

cat /proc/$(pgrep mysql | head -1)/smaps | grep -E "^(Size|Rss|Pss|Shared|Private)"

Cela révèle chaque mappage mémoire (tas, pile, bibliothèques partagées, mappages anonymes) avec les valeurs RSS et PSS individuelles — la vue mémoire la plus granulaire disponible sans profileur.

Comparaison des outils : choisir la bonne commande

Flux de travail de surveillance pratiques

Flux de travail 1 : Triage rapide (en moins de 60 secondes)

free -h                          # Step 1: Is Available memory critically low?
vmstat 1 5                       # Step 2: Is active swapping occurring?
ps aux --sort=-%mem | head -15   # Step 3: Which processes are the top consumers?

Flux de travail 2 : Identification d’une fuite mémoire

# Watch a specific process's RSS grow over time
watch -n 5 'ps -o pid,rss,vsz,comm -p $(pgrep your_app)'

# Or use smem with repeated snapshots
while true; do smem -P your_app -t; sleep 30; done

Flux de travail 3 : Analyse historique post-incident

sar -r -f /var/log/sysstat/sa$(date +%d --date='yesterday')

Flux de travail 4 : Script d’alerte automatisé

#!/bin/bash
THRESHOLD=90
USED_PCT=$(free | awk '/^Mem:/ {printf "%.0f", $3/$2 * 100}')
if [ "$USED_PCT" -gt "$THRESHOLD" ]; then
    echo "ALERT: RAM usage at ${USED_PCT}% on $(hostname)" | mail -s "Memory Alert" admin@example.com
fi

Ce script peut être placé dans une tâche cron pour une surveillance automatisée continue — une nécessité pratique sur tout VPS avec cPanel en production ou serveur bare-metal.

Avancé : Paramètres de réglage de la mémoire du noyau

Une fois que vous avez identifié une pression mémoire, ces paramètres sysctl affectent directement le comportement :

# View current swappiness (default: 60)
sysctl vm.swappiness

# Reduce swap tendency (recommended for databases: 10)
sysctl -w vm.swappiness=10

# Increase dirty page write-back aggressiveness
sysctl -w vm.dirty_ratio=15
sysctl -w vm.dirty_background_ratio=5

# Drop page cache manually (use with caution on production)
sync; echo 3 > /proc/sys/vm/drop_caches

vm.swappiness expliqué : Une valeur de 60 signifie que le noyau commencera à swapper lorsque la RAM sera utilisée à 40 %. Pour les serveurs de bases de données (MySQL, PostgreSQL, Redis), définir cette valeur à 10 maintient les données en RAM beaucoup plus longtemps, réduisant considérablement la latence d’E/S. Pour les systèmes de bureau ou les systèmes avec peu de RAM, la valeur par défaut est plus appropriée.

Pièges courants et mauvaises interprétations

Piège 1 : Paniquer face à une mémoire « libre » faible

Comme expliqué précédemment, Linux utilise intentionnellement la RAM libre comme cache. Un système avec 200 MB libres mais 8 Go disponibles est en bonne santé. Lisez toujours la colonne Available.

Piège 2 : Additionner le RSS pour estimer l’utilisation totale de la mémoire

Additionner les valeurs RSS de ps pour tous les processus dépassera généralement la RAM physique totale en raison du double comptage des bibliothèques partagées. Utilisez smem -t pour un total système précis.

Piège 3 : Ignorer le cache Slab

Sur les clients ou serveurs NFS très sollicités ou les serveurs avec de nombreux petits fichiers, l’allocateur Slab du noyau peut consommer des gigaoctets de RAM. Vérifiez cat /proc/meminfo | grep Slab — cette mémoire est techniquement récupérable mais n’apparaît pas dans les outils au niveau des processus.

Piège 4 : Confondre VSZ avec l’utilisation réelle de la mémoire

Une application Java peut afficher 4 Go de VSZ mais seulement 512 MB de RSS. Le VSZ inclut les fichiers mappés en mémoire, le tas réservé mais non alloué, et les bibliothèques partagées — dont la plupart ne sont jamais réellement chargées en RAM physique.

Piège 5 : Négliger la mémoire sur les charges de travail conteneurisées

À l’intérieur d’un conteneur Docker, free affiche la mémoire totale de l’hôte, pas la limite cgroup du conteneur. Utilisez cat /sys/fs/cgroup/memory/memory.usage_in_bytes et cat /sys/fs/cgroup/memory/memory.limit_in_bytes pour des métriques précises au niveau du conteneur.

Mise en place d’une surveillance RAM persistante

Pour les environnements de production, les commandes ponctuelles sont insuffisantes. Envisagez ces approches pour une visibilité continue :

• sysstat avec cron : Active automatiquement la collecte de données historiques sar.
• Prometheus + Node Exporter : Collecte les métriques /proc/meminfo et les expose pour les tableaux de bord Grafana.
• Netdata : Surveillance en temps réel sans configuration avec une granularité à la seconde et une détection intégrée des anomalies mémoire.
• Zabbix ou Nagios : Alertes de niveau entreprise avec des seuils mémoire configurables et des politiques d’escalade.

Lors de l’exécution de charges de travail sur une infrastructure d’Hébergement GPU, surveillez également la VRAM GPU aux côtés de la RAM système — nvidia-smi --query-gpu=memory.used,memory.free --format=csv fournit les métriques équivalentes pour la mémoire GPU.

Pour les environnements d’hébergement web gérés via des Panneaux de contrôle VPS, la plupart des panneaux incluent des graphiques mémoire intégrés — mais ceux-ci interrogent généralement à des intervalles de 1 à 5 minutes et manqueront les pics de courte durée que vmstat ou sar captureraient.

Matrice de décision technique : quel outil utiliser et quand

Liste de contrôle des points clés

• Vérifiez toujours la mémoire Available de free -h, et non la colonne Free, pour évaluer la marge réelle disponible.
• Utilisez vmstat 1 5 pour confirmer ou exclure un swapping actif avant d’escalader une investigation.
• Utilisez smem -s pss -r plutôt que ps aux --sort=-%mem lorsque vous avez besoin de chiffres mémoire précis par processus — en particulier sur les serveurs avec de nombreux processus partageant des bibliothèques.
• Installez sysstat sur chaque serveur de production immédiatement après le provisionnement pour activer la collecte de données historiques sar.
• Définissez vm.swappiness=10 de manière persistante dans /etc/sysctl.conf sur les serveurs de bases de données pour minimiser l’utilisation du swap.
• Vérifiez /proc/meminfo pour les valeurs Slab et Dirty lorsque les outils standard n’expliquent pas la pression mémoire observée.
• Pour les charges de travail conteneurisées, lisez les fichiers mémoire cgroup — et non free — pour des limites et une utilisation précises.
• Sur les environnements d’hébergement partagé ou VPS, établissez des références mémoire pendant le fonctionnement normal afin que les anomalies soient immédiatement reconnaissables.

—

Foire aux questions

Quelle est la différence entre la mémoire « free » et « available » sous Linux ?

« Free » est la RAM sans aucune utilisation actuelle. « Available » est l’estimation réaliste de la mémoire pouvant être allouée à de nouveaux processus sans déclencher de swapping — elle inclut le cache de pages et les tampons récupérables. Sur un serveur Linux en bonne santé, « free » est souvent proche de zéro tandis que « available » reste élevé. Utilisez toujours « available » pour les évaluations de capacité.

Pourquoi la somme des valeurs RSS de tous les processus dépasse-t-elle la RAM physique totale ?

Le RSS (Resident Set Size) compte la mémoire partagée — comme les bibliothèques partagées — une fois par processus qui la mappe. Si 50 processus mappent chacun une bibliothèque partagée de 100 MB, la somme totale du RSS gonfle de 4 900 MB au-delà du coût physique réel. Utilisez smem avec le rapport PSS pour éliminer ce double comptage.

Comment trouver quel processus a déclenché l’OOM killer Linux ?

Exécutez dmesg | grep -i "oom|killed process" ou journalctl -k | grep -i oom. Le noyau enregistre le nom exact du processus, le PID et les statistiques mémoire au moment de l’événement de suppression, y compris l’oom_score de tous les processus évalués.

Que signifie une utilisation élevée du swap, et est-ce grave ?

Une utilisation soutenue du swap signifie que le jeu de travail du système dépasse la RAM physique. Le noyau compense en paginant les données sur disque, ce qui est généralement 100 à 1 000 fois plus lent que l’accès à la RAM. Même une activité de swap modeste provoque une latence applicative mesurable. C’est un signal définitif pour soit réduire la consommation mémoire, augmenter la RAM, soit redistribuer les charges de travail.

Puis-je surveiller l’utilisation de la RAM à l’intérieur d’un conteneur Docker en utilisant des commandes Linux standard ?

Les commandes standard comme free à l’intérieur d’un conteneur affichent la RAM totale de l’hôte, pas la limite cgroup du conteneur. Pour des métriques précises au niveau du conteneur, lisez /sys/fs/cgroup/memory/memory.usage_in_bytes pour l’utilisation actuelle et /sys/fs/cgroup/memory/memory.limit_in_bytes pour la limite configurée. Alternativement, utilisez docker stats <container_name> depuis l’hôte pour une vue formatée.