Surveiller la RAM et le CPU

Un VPS de 512 Mo ou 2 Go n'a pas la même marge qu'un serveur dédié. Avant d'ajouter des ressources, il faut comprendre ce qui consomme : mémoire réellement utilisée, cache récupérable, charge CPU rapportée au nombre de vCPU. Une lecture naïve de free ou de top mène souvent à une conclusion fausse.

Lire la mémoire

free -h
swapon --show
ps aux --sort=-%mem | head

Dans free, la colonne importante est available, pas free. buff/cache correspond à des pages que le noyau peut libérer sous pression : ce n'est pas de la mémoire perdue. Un serveur avec 200 Mo de free mais 1,2 Go de available n'est pas en difficulté.

swapon --show indique si du swap est actif. Dans un conteneur système, le swap est généralement fourni par la plateforme : vous pouvez le voir sans pouvoir le redimensionner. Le swap évite un arrêt brutal, il ne remplace pas de la RAM.

Lire le CPU et la charge

uptime
nproc
top
vmstat 1 5

uptime affiche trois moyennes de charge (1, 5 et 15 minutes). Comparez-les au nombre de vCPU donné par nproc : une charge de 2 sur 2 vCPU signifie une saturation soutenue, une charge de 2 sur 4 vCPU laisse de la marge. Une charge élevée peut aussi venir d'attentes disque, pas seulement du calcul.

Dans top, regardez us (utilisateur), sy (système), wa (attente I/O), id (inactif) et st (vol de temps par la plateforme). Un wa élevé pointe vers le disque ou une base lente. vmstat 1 5 confirme avec les colonnes r (processus prêts), b (bloqués), si/so (swap entrant/sortant).

Pour classer les processus :

ps aux --sort=-%cpu | head
sudo apt install sysstat
pidstat 1 5

Reconnaître l'OOM killer

Quand la mémoire manque, le noyau tue un processus. Le service disparaît sans message applicatif clair :

sudo journalctl -k | grep -i -E 'oom|killed process'
sudo dmesg -T | grep -i oom

Cherchez Out of memory: Killed process et le nom du processus. Un redémarrage automatique peut masquer la cause : le service revient, puis meurt à nouveau. Réduisez les workers (PHP-FPM, Node.js, workers Python), les tampons de base de données, ou passez à une offre avec plus de RAM.

Diagnostiquer et corriger

Procédez dans cet ordre :

1. Vérifiez available et le swap.
2. Comparez la charge au nombre de vCPU.
3. Identifiez les premiers processus par mémoire et par CPU.
4. Cherchez un OOM dans le noyau.
5. Corrigez la cause avant d'augmenter l'offre.

Une fuite mémoire se voit à une croissance régulière de la RSS d'un processus. Redémarrer le service tous les jours n'est pas une correction durable : mesurez, corrigez ou limitez.

Vérifier

free -h
uptime
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
journalctl -k -b | grep -i oom

Après un changement, comparez la charge et la mémoire disponible à la même heure, sur plusieurs jours. Une moyenne isolée ne prouve rien ; c'est la tendance qui indique si le VPS est correctement dimensionné.