De combien de RAM ton VPS Linux a-t-il réellement besoin ?

La mémoire vive (RAM) est généralement la ressource qui détermine si un VPS est rapide ou s'il plante. Ce guide t'explique en détail de combien de mémoire ton serveur a réellement besoin en fonction de ta pile technologique, de ton trafic et des processus que tu exécutes en arrière-plan. Tu y trouveras des chiffres de référence pour les types de sites courants, un tableau de dimensionnement par cas d'utilisation, ainsi que les signes spécifiques qui t'indiquent qu'il est temps d'augmenter la capacité de mémoire.

La plupart des sites web fonctionnent très bien sur un VPS doté de 2 à 8 Go de RAM. La quantité exacte dépend de ce qui occupe la mémoire en même temps : ton serveur web, les processus PHP, la base de données, toute couche de mise en cache, ainsi que le nombre de visiteurs qui consultent le site simultanément. Lorsque ces demandes combinées dépassent ce que prévoit ton forfait, les requêtes commencent à s'accumuler en file d'attente, les temps de réponse augmentent et le système d'exploitation se met à tuer des processus pour rester opérationnel.

Qu'est-ce que la RAM contrôle vraiment sur un VPS ?

La RAM, c'est la mémoire vive que ton serveur utilise pour traiter les requêtes en temps réel. À chaque chargement de page, ton serveur web, PHP et ta base de données sont chargés en mémoire pour générer la réponse, et c'est dans la RAM que tout ça se passe.

Dans une pile classique, trois éléments se disputent cette place :

• Mémoire par requête. Chaque thread PHP contient le code et les données nécessaires au traitement d'une requête. Dix visiteurs simultanés peuvent donc correspondre à dix threads fonctionnant en même temps, chacun utilisant sa propre partie de mémoire.
• La base de données. MySQL ou MariaDB met en cache les index et les données fréquemment consultées en mémoire. Plus elle peut en stocker, moins elle doit effectuer d'allers-retours lents vers le disque.
• Mise en cache et services en arrière-plan. Les caches d'objets, les caches de pages, les processus de file d'attente et les tâches cron occupent tous de la mémoire, qu'un visiteur soit sur le site ou pas.

Quand la demande dépasse la mémoire vive (RAM) physique, Linux se rabat sur l'espace d'échange, ce qui déplace les pages de mémoire vers le disque. Le disque est bien plus lent que la RAM, même avec NVMe , donc un serveur qui utilise beaucoup l'espace d'échange te paraîtra lent bien avant d'être complètement à court de mémoire.

De combien de RAM un site web basique a-t-il besoin ?

Un simple site vitrine, un petit blog ou un site professionnel peu fréquenté fonctionne très bien avec 2 Go de RAM. Ça suffit largement pour le serveur web, quelques processus PHP, une petite base de données et une mise en cache légère, tout en gardant une marge de manœuvre.

Ajoute un éditeur de pages, un filtre anti-spam pour les formulaires de contact, un plugin d'analyse et quelques intégrations, et les 2 Go deviennent vite insuffisants en cas de pics de trafic. À ce stade, 8 Go te permettent d'accueillir des visiteurs simultanés sans que les workers ne ralentissent. C'est la fourchette dans laquelle se situent la plupart des sites de petites entreprises en pleine croissance.

De combien de RAM WordPress a-t-il WordPress ?

WordPress est léger, mais ce sont les plugins et les thèmes qui font grimper la consommation de mémoire. Le WordPress recommande au moins 512 Mo de RAM et PHP 8.3 ou une version plus récente pour une installation en production, et les nouvelles fonctionnalités d'IA de WordPress .0 fonctionnent mieux avec environ 512 Mo de mémoire PHP disponible. Ces chiffres sont un minimum, pas un objectif.

En pratique, prévois entre 2 et 4 Go pour un simple site de contenu, entre 8 et 16 Go si tu ajoutes WooCommerce ou un plugin d'abonnement, et 24 Go ou plus pour une boutique très fréquentée. WooCommerce est très gourmand en mémoire, car les paniers, les sessions et la logique de paiement fonctionnent tous de manière dynamique et ne peuvent pas être entièrement mis en cache.

La mémoire PHP est distincte de la RAM du serveur, et cette distinction prête souvent à confusion. Le PHP memory_limit définit une limite par processus, et sa valeur par défaut historique de 128 Mo est souvent trop faible pour les sites qui utilisent beaucoup de plugins. Une WordPress classique nécessite généralement une limite PHP de 256 Mo, voire 512 Mo pour les configurations plus gourmandes. Augmenter cette limite permet à chaque requête d'aboutir, mais ça veut aussi dire que chaque worker PHP peut utiliser davantage de ta mémoire vive totale ; il faut donc ajuster ces deux valeurs en même temps.

Combien de RAM les couches de mise en cache comme Redis et Varnish utilisent-elles ?

La mise en cache privilégie la vitesse au détriment de la RAM, et c'est l'une des meilleures façons d'utiliser la mémoire sur un VPS. Le hic, c'est que le cache occupe de la RAM, donc tu dois en tenir compte dans ton budget.

• La mise en cache d'objets avec Redis stocke les résultats des requêtes de base de données en mémoire, ce qui fait que les requêtes répétées n'accèdent jamais à la base de données. Un site WordPress WooCommerce très fréquenté peut allouer entre 256 Mo et 1 Go à Redis, et cette mémoire reste réservée même quand le trafic est faible. Tu peux en savoir plus en consultant la documentation de Redis.
• La mise en cache de pages avec Varnish ou NGINX permet de conserver en mémoire des pages entièrement générées et de les servir sans avoir à faire appel à PHP. C'est le principal gain de performances pour les sites où les lectures sont nombreuses, et ce gain évolue en fonction du nombre de pages uniques que tu mets en cache.
• OPcache conserve le bytecode PHP compilé en mémoire pour que le serveur n'ait pas à recompiler les scripts à chaque requête. On utilise souvent une allocation de 256 Mo, ce qui réduit nettement la charge du processeur.

Si tu cumules les trois, tu risques de consacrer entre 1 Go et 2 Go uniquement à la mise en cache avant même qu'un seul visiteur n'arrive. C'est de la mémoire bien utilisée, mais ça modifie tes calculs de dimensionnement.

De combien de RAM ta base de données a-t-elle besoin ?

La base de données est souvent la cause cachée des problèmes de mémoire. MySQL et MariaDB utilisent un pool de mémoire tampon pour conserver les index et les données fréquemment consultées en RAM, et une pratique courante consiste à régler la taille de ce pool entre 50 et 70 % de la mémoire que tu consacres à la base de données.

Un petit site avec quelques milliers de lignes ne pose pratiquement aucun problème. En revanche, une boutique en ligne avec un vaste catalogue de produits, un historique des commandes et des comptes clients peut faire grimper l'utilisation de la mémoire active de la base de données à plusieurs gigaoctets. Si ta base de données et tes workers PHP se disputent la même mémoire vive, les deux ralentissent, et la solution consiste généralement à augmenter la mémoire plutôt qu'à optimiser davantage le système.

En quoi le trafic et la charge simultanée influencent-ils tes besoins en mémoire vive ?

Le nombre total de visites mensuelles est moins important que le nombre de connexions simultanées, c'est-à-dire le nombre de personnes qui consultent ton site en même temps. La mémoire vive (RAM) est consommée par requête simultanée, et non par visiteur quotidien.

Un site qui reçoit 50 000 visites par mois réparties de manière uniforme a besoin de bien moins de mémoire qu'un site avec le même nombre total de visites, mais qui peut atteindre 300 utilisateurs simultanés lors du lancement d'un produit ou d'un envoi d'e-mails. Chacune de ces requêtes simultanées peut lancer un worker PHP, et chaque worker utilise de la mémoire.

Deux leviers permettent de réduire la pression :

• La mise en cache des pages permet de servir la plupart des visiteurs à partir du cache, ce qui évite complètement de lancer un worker PHP. C'est pour ça qu'un site bien mis en cache peut gérer les pics de trafic même avec peu de RAM.
• Les limites de workers déterminent le nombre de processus PHP pouvant s'exécuter simultanément. Si tu les définis à une valeur trop élevée, un pic de trafic risque d'épuiser la mémoire ; si tu les définis en fonction de ta mémoire vive, le serveur restera stable même sous charge.

De combien de RAM les applications pour développeurs ont-elles besoin ?

Au-delà des sites web, un VPS héberge souvent des charges de travail d'applications : une API Node.js, un service Python, des processus de file d'attente en arrière-plan, ou encore un ou deux conteneurs. Ces éléments ont une taille différente de celle d'une pile LAMP standard.

Une simple application Node.js ou Python avec une base de données et un cache fonctionne très bien avec 8 Go, même si un service allégé peut s'en sortir avec moins. Les charges de travail des conteneurs génèrent une surcharge, car chaque conteneur dispose de son propre environnement d'exécution, et l'orchestration, les workers de file d'attente et les couches de mise en cache réservent chacun de la mémoire, qu'il y ait ou non des requêtes en cours. Si tu fais tourner un serveur d'applications, une base de données et un cache en parallèle, 16 Go ou plus te donneront la marge nécessaire pour éviter les redémarrages en cas de charge importante. Note qu'un VPS est conçu pour la couche d'application et d'orchestration plutôt que pour l'entraînement de modèles, puisqu'il ne comprend pas de carte graphique (GPU).

Choisir la quantité de RAM pour un VPS en fonction de ton utilisation

Sers-t'en comme point de départ, puis adapte-le en fonction de ta configuration de mise en cache et de l'espace occupé par ta base de données.

Cas d'utilisation	Mémoire vive classique	Qu'est-ce qui fait grimper ce chiffre ?
Un simple blog ou un site vitrine	2 à 4 Go	Peu de code PHP, une petite base de données, une mise en cache minimale
Site professionnel avec des extensions	8 Go	Plus de travailleurs simultanés, une pile de plugins plus complète
WooCommerce ou site d'adhésion	16 Go	Paiement dynamique, sessions, mise en cache d'objets
Agence gérant plusieurs sites de clients	24 Go	Plusieurs bases de données et pools de travailleurs sur un seul serveur
Serveur d'applications + base de données + cache	32 Go	Environnement d'exécution de l'application, orchestration, cache réservé

Quels sont les signes qui indiquent que ta mémoire vive (RAM) n'est plus suffisante ?

Les problèmes de mémoire se manifestent avant que le site ne tombe en panne. Fais gaffe à ces signes :

• Des erreurs de mémoire insuffisante dans tes journaux, notamment des erreurs fatales PHP faisant référence à la limite de mémoire ou à des processus arrêtés par le système d'exploitation.
• Utilisation intensive de la mémoire virtuelle, que tu peux vérifier avec free -h via SSH. Une activité constante de la mémoire swap signifie que tu n'as plus assez de RAM physique.
• Les temps de réponse augmentent quand le serveur est sous charge, alors qu'un serveur au repos reste rapide. Cet écart indique un problème de concurrence sur la mémoire en cas de trafic intense, et non une lenteur générale du site.
• La base de données ou le serveur web redémarre tout seul, ce qui veut souvent dire que le « OOM killer » intervient pour récupérer de la mémoire.

En voir un ou deux lors d'un pic occasionnel, c'est normal. Si tu en vois chaque semaine, ça veut dire que la charge de travail dépasse ce qui est prévu dans le plan, et ajouter de la mémoire vive sera plus efficace que n'importe quel autre réglage.

Est-ce qu'un VPS géré ou autogéré change la façon dont tu calcules ta mémoire vive ?

C'est vrai, un peu. Un panneau de contrôle et une pile de sécurité consomment de la mémoire à eux, et ça surprend les gens qui pensent qu'un panneau, ça ne prend pas de place. cPanel WHM, ou Control Web Panel, exécutent des services en arrière-plan qui occupent déjà quelques centaines de mégaoctets avant même que ton site n'affiche la moindre page.

Sur un VPS géré, InMotion s'occupe du système d'exploitation, des mises à jour et du panneau de contrôle ; tu prévois donc un peu plus de RAM pour profiter de cette commodité et tu ne perds pas une seconde à gérer ton serveur. Sur un VPS autogéré, tu disposes d'un accès root complet et tu peux tout configurer toi-même, y compris le niveau de simplification de l'installation de base. Les deux options d'InMotion fonctionnent sur NVMe avec, au choix, cPanel Control Web Panel, et prennent en charge AlmaLinux 9, Ubuntu 22.04 LTS et Debian 12.

Comment choisir la formule VPS InMotion qui te convient

Commence par ton stack, pas par le prix. Fais le total de tout ce qui tourne en mémoire en même temps : le serveur web et les workers PHP, le pool de mémoire tampon de ta base de données, tes couches de mise en cache et tous les services de l'application. Choisis un forfait qui te laisse une marge de manœuvre pour évoluer, car si tu tournes à pleine capacité, tu n'auras plus rien pour faire face aux pics de trafic.

Une règle empirique pratique :

• Choisis entre 2 et 4 Go pour un site de contenu ou un site professionnel.
• Choisis 8 Go pour un site professionnel basé sur un CMS.
• Opte pour 16 Go si tu veux créer une boutique en ligne, un site d'abonnement ou un petit ensemble de sites pour tes clients.
• Opte pour 24 Go ou plus si tu as des charges de travail liées aux applications ou une configuration multisite très sollicitée.

L'hébergement VPS InMotion s'appuie sur NVMe au sein de clusters à haute disponibilité, avec un SLA garantissant une disponibilité de 99,99 % et une assistance humaine interne disponible 24 h/24 et 7 j/7 dans trois centres de données. Tu peux passer d'une formule plus petite à une plus grande à mesure que tes besoins en mémoire augmentent, et choisir entre une gestion prise en charge ou en autonomie selon le niveau d'implication que tu souhaites avoir. Si tu préfères qu’un spécialiste adapte la taille de ton environnement à ta charge de travail réelle, contacte notre équipe commerciale et on t’accompagnera pas à pas.

Prêt à choisir une formule ? Compare les caractéristiques actuelles de l'hébergement VPS InMotion, ou si ta boutique en ligne ou ton application à fort trafic a déjà dépassé les capacités des ressources virtualisées, jette un œil aux serveurs dédiés pour bénéficier d'un matériel garanti.