Le site meurt à minuit, la base de données redémarre sans raison, SSH devient si lent qu'on ne peut plus se connecter — la cause la plus fréquente derrière ces symptômes est l'épuisement de la mémoire. Cet article montre comment le confirmer, appliquer les premiers secours et corriger durablement.
Étape 1 : confirmer que c'est la mémoire
Connectez-vous en SSH et exécutez free -h, en surveillant la colonne available : sous 200 Mo en permanence, la mémoire est sous pression. Puis lancez dmesg | grep -i kill — si vous voyez Out of memory: Killed process, l'OOM Killer du noyau termine des processus, exactement pourquoi vos services « disparaissent mystérieusement ».
Étape 2 : trouver ce qui mange la mémoire
Lancez top et appuyez sur Shift+M pour trier par mémoire. Les suspects habituels :
- MySQL : les réglages par défaut supposent beaucoup de RAM — sur une petite machine, réduisez innodb_buffer_pool_size ;
- PHP-FPM : trop de processus workers — estimez max_children comme RAM disponible ÷ consommation par processus ;
- Applications en fuite : un processus Node.js ou Java qui fuit grossit jusqu'à tout consommer.
Étape 3 : ajouter du swap en premiers secours
Le swap est de l'espace disque servant de mémoire de secours, empêchant l'OOM Killer de frapper immédiatement. Les images VPS n'ont généralement pas de swap. Pour ajouter 2 Go : créez un fichier swap avec fallocate, réglez les permissions avec chmod 600, formatez avec mkswap, activez avec swapon, et ajoutez-le à /etc/fstab pour qu'il survive aux redémarrages. Rappelez-vous : le swap n'est qu'un tampon — quand la RAM manque vraiment, le système ralentit au lieu de planter, vous laissant le temps d'enquêter.
La solution durable
Si la mémoire disponible reste au plancher après optimisation et que l'usage du swap reste élevé, votre charge a dépassé l'offre — augmenter la RAM est la solution la plus rentable. 00Shark permet la montée en gamme sur place ; contactez le support avec votre usage actuel pour une évaluation.