ACLClouds
ACLClouds

Le VPS redémarre ou tue des processus par manque de mémoire

Confirmer l’OOM killer, identifier le processus et corriger la consommation ou le dimensionnement.

Linux peut tuer un processus pour protéger la VM lorsqu’il ne reste plus de mémoire. Les logs du noyau permettent de distinguer OOM, crash applicatif et redémarrage manuel.

Procédure étape par étape

  1. Lire les logs du noyau

    Cherchez Out of memory et Killed process avec journalctl ou dmesg.

  2. Mesurer les processus

    Utilisez free -h, ps et les statistiques du panel pour repérer une consommation stable ou une fuite progressive.

  3. Limiter les services

    Réduisez workers, cache, concurrence et limites mémoire Docker. Évitez de cumuler plusieurs bases lourdes sur une petite offre.

  4. Ajouter une marge

    Si la charge normale reste trop proche de la limite, augmentez la RAM ou répartissez les services.

Diagnostic mémoire

free -h
ps aux --sort=-%mem | head -15
journalctl -k -g "Out of memory|Killed process" --since today

Créer un fichier d’échange de 2 Go

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf
sysctl --system
swapon --show

Avant de commencer

La page « Statistiques » des « Outils supplémentaires » indique la mémoire utilisée au moment où vous l’ouvrez. Pour savoir ce qui s’est passé, lisez les logs du noyau dans la VM : ils gardent l’heure exacte et le nom du processus tué.

La mémoire vue par Linux inclut le cache disque. Dans free -m, regardez la colonne available et non free : un free bas est normal, un available proche de zéro ne l’est pas.

Ajouter un fichier d’échange

Un fichier d’échange (swap) absorbe un pic court sans que l’OOM killer intervienne. Il ne remplace pas de la RAM : utilisé en permanence, il ralentit tout le VPS. Commencez par 1 à 2 Go, après avoir vérifié l’espace libre avec df -h.

  • La ligne /swapfile none swap sw 0 0 dans /etc/fstab le réactive à chaque démarrage.
  • vm.swappiness=10 dans /etc/sysctl.d/99-swap.conf limite son usage aux situations de manque.

Vérifier que tout fonctionne

swapon --show doit lister /swapfile. Après quelques heures de charge normale, la recherche Killed process dans journalctl -k ne doit plus rien renvoyer et available doit garder une marge.

Questions fréquentes

Mon application s’arrête avec Killed ou Exit code 137, est-ce la mémoire ?

Très souvent. 137 correspond à un arrêt par SIGKILL (128 + 9), envoyé par l’OOM killer ou par une limite mémoire Docker. dmesg | grep -i oom le confirme pour le VPS ; pour un conteneur, docker inspect --format '{{.State.OOMKilled}}' suivi de son nom renvoie true.

Node.js affiche JavaScript heap out of memory, que faire ?

C’est la limite du tas de V8 qui est atteinte, pas forcément celle du VPS. Si la RAM le permet, relevez-la avec NODE_OPTIONS=--max-old-space-size=1024 (valeur en Mo), en restant sous la mémoire disponible. Si la consommation monte sans fin, cherchez plutôt une fuite : cache sans limite, tableaux qui grossissent, écouteurs jamais retirés.

Pourquoi c’est toujours MySQL ou Java qui est tué en premier ?

L’OOM killer choisit le processus qui libère le plus de mémoire, donc le plus gros, même s’il n’est pas responsable du pic. Réduisez innodb_buffer_pool_size pour MySQL ou MariaDB, et gardez -Xmx d’une JVM nettement sous la RAM totale : la JVM consomme aussi de la mémoire hors du tas.