Combien de RAM pour un VPS : la règle, usage par usage

La règle : additionner ce qui reste en mémoire

Un serveur ne consomme pas de la mémoire « en général » : chaque programme qui tourne en garde une part, tant qu'il tourne. Le calcul part donc de la liste des processus présents en permanence, puis ajoute le pic et une marge :

Mémoire à prévoir = (système + services permanents + pic des tâches ponctuelles) × 1,25

• Le système : une distribution Linux minimale (Debian, Ubuntu) occupe de l'ordre de 150 à 300 Mo une fois démarrée, accès SSH et journalisation compris.
• Les services permanents : serveur web, processus de l'application, base de données, cache, file de tâches. Leur consommation dépend de la technologie, détaillée dans la section suivante.
• Le pic : ce qui s'ajoute par moments, compilation d'une application, sauvegarde, import, tâche planifiée lourde. Un serveur dimensionné sur sa moyenne tombe précisément à ces moments-là.
• La marge : 25 % au-dessus du total, pour la croissance des données et du trafic. Elle ne dort pas : Linux se sert de la mémoire libre comme cache des fichiers, ce qui accélère la base de données.

Ce que consomme chaque brique

Les ordres de grandeur ci-dessous valent pour une application de taille courante, mesurée en production. Ils donnent un point de départ ; la mesure sur votre propre application, décrite plus bas, a toujours le dernier mot.

Un pic revient souvent avec les applications JavaScript : la compilation. npm run build sur un projet Next.js, Nuxt ou Angular demande couramment 1 à 2 Go à lui seul, pendant quelques minutes, en plus de ce qui tourne déjà. Compiler sur le serveur, c'est dimensionner pour ce pic ; compiler sur votre poste ou dans votre intégration continue et ne déposer que le résultat, c'est l'éviter.

Même raisonnement pour les conteneurs Docker : chaque conteneur est un ensemble de processus comme les autres, et le démon Docker ajoute sa propre consommation. docker stats affiche ce que prend chacun.

Profils types

Ces profils additionnent les briques précédentes, pic et marge compris. Ils supposent une application de taille courante et le trafic d'un lancement ; une base volumineuse ou un trafic soutenu déplacent le curseur vers le haut.

Une application qui appelle un modèle d'IA par API (OpenAI, Anthropic, Mistral) se dimensionne comme n'importe quelle application web : le modèle tourne chez son éditeur, et votre serveur attend sa réponse. C'est l'exécution du modèle sur le serveur lui-même qui fait changer d'échelle.

Mesurer sur un serveur qui tourne

Sur un serveur en service, la mesure remplace l'estimation. Trois commandes disent où l'on en est :

free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5

• free -h : lisez la colonne available, la mémoire réellement disponible pour lancer de nouveaux programmes. La colonne free est presque toujours basse, et c'est normal : Linux remplit la mémoire inutilisée avec le cache des fichiers (buff/cache), qu'il rend dès qu'un programme en a besoin.
• ps aux --sort=-rss : les processus classés par mémoire occupée (colonne RSS, en kilo-octets). C'est ici que l'on voit ce que pèse chaque worker PHP ou Node.js.
• vmstat 5 5 : cinq relevés à cinq secondes d'intervalle. Des valeurs non nulles dans les colonnes si et so, relevé après relevé, signalent un serveur qui échange avec le swap : il manque de mémoire.

Mesurez au moment le plus chargé de la journée, et pendant les tâches ponctuelles : compilation, sauvegarde, import. C'est le pic qui compte.

Quand la mémoire manque

Un serveur à court de mémoire ne ralentit pas progressivement. Quand il n'y a plus rien à libérer, le noyau Linux déclenche l'OOM killer (out of memory) : il choisit un processus, en général celui qui occupe le plus de mémoire, et l'arrête net. Sur un serveur applicatif, c'est souvent la base de données.

Les symptômes : des erreurs 502 ou 503 par moments, un service qui redémarre sans raison apparente, une compilation qui s'interrompt sur Killed. Les journaux le confirment :

journalctl -k | grep -i "out of memory"
systemctl status nom-du-service

Dans la sortie de systemctl status, la mention Failed with result 'oom-kill' désigne un service arrêté faute de mémoire.

Le swap, quand le serveur en dispose, retarde ce moment en déplaçant sur disque la mémoire la moins utilisée. Il sert de filet, pas de capacité : un serveur qui s'appuie sur le swap en continu répond plusieurs fois plus lentement, même sur un SSD NVMe.

Les remèdes, du plus simple au plus durable : réduire le nombre de processus de l'application (pm.max_children, workers Gunicorn), compiler hors du serveur, borner la mémoire de la base de données, puis passer à une taille supérieure.

Choisir sa taille, et prévoir la suite

1. Listez ce qui tournera : serveur web, application et nombre de processus, base de données, cache, tâches planifiées.
2. Additionnez avec le tableau des briques, ajoutez le pic le plus lourd (souvent la compilation), puis 25 % de marge.
3. Retenez la taille qui couvre ce total. Entre deux tailles voisines, la plus petite convient dès lors que le passage à la taille supérieure se fait sans réinstaller.
4. Mesurez après la mise en ligne, au pic de la journée, puis à chaque étape de croissance de l'application.

La mémoire n'est pas la seule ressource : le processeur compte pour ce qui calcule (compilation, traitement d'images, exécution d'un modèle d'IA), le disque pour la base de données et les fichiers. Pour une application web, c'est pourtant presque toujours la mémoire qui fixe la taille.