Guide
Combien de RAM pour un serveur dédié ?
Une méthode pour estimer la mémoire nécessaire poste par poste (système, PHP, base de données, cache), un exemple chiffré et les moyens de vérifier la consommation réelle.
La mémoire vive est souvent le premier goulot d’étranglement d’un serveur web : quand elle manque, le système commence à utiliser le disque (swap) et tout ralentit. À l’inverse, payer 128 Go pour un site qui en utilise 6 n’a pas de sens. Plutôt qu’une règle universelle, voici une méthode pour estimer votre besoin, puis le vérifier.
L’essentiel
- Additionnez la mémoire du système, du serveur web et de PHP (ou de votre application), de la base de données et du cache, puis ajoutez une marge.
- La base de données est souvent le poste le plus important : c’est elle qui profite le plus de la mémoire disponible.
- Mesurez ensuite la consommation réelle : l’estimation n’est qu’un point de départ.
À quoi sert la mémoire d’un serveur ?
La RAM conserve tout ce que le serveur est en train de traiter : le système d’exploitation, les processus qui répondent aux visiteurs, les données de la base les plus consultées et les caches. Plus une donnée est en mémoire, moins le serveur doit la lire sur disque, ce qui accélère les réponses. Une mémoire insuffisante se traduit par des temps de réponse qui s’allongent sous la charge, voire par l’arrêt de processus par le système.
La méthode de calcul, poste par poste
Le système d’exploitation
Une distribution Linux de serveur sans interface graphique consomme peu : comptez de l’ordre de 1 Go pour le système et les services de base (journalisation, supervision, SSH).
Le serveur web et PHP
Avec PHP-FPM, chaque requête PHP simultanée est traitée par un processus. Le paramètre pm.max_children fixe le nombre maximal de ces processus, donc le nombre de requêtes PHP traitées en parallèle. La mémoire nécessaire est d’environ : nombre de processus × mémoire moyenne d’un processus.
La limite par défaut de PHP (memory_limit) est de 128 Mo par script ; la consommation réelle d’un processus est souvent inférieure, et varie beaucoup selon l’application. Mesurez-la sur votre site plutôt que de supposer.
La base de données
C’est généralement le poste qui gagne le plus à disposer de mémoire. La documentation de MySQL indique que, sur un serveur dédié à la base de données, jusqu’à 80 % de la mémoire physique est souvent attribué au buffer pool d’InnoDB. Celle de PostgreSQL recommande de commencer avec environ 25 % de la mémoire pour shared_buffers, le reste profitant au cache du système. Si la base partage le serveur avec le site, réservez-lui une part cohérente avec sa taille : idéalement, les données consultées fréquemment doivent tenir en mémoire.
Le cache applicatif
Redis ou Memcached stockent sessions et fragments de pages. Leur besoin dépend du volume mis en cache ; il se configure explicitement (limite de mémoire), ce qui facilite l’estimation.
La marge
Ajoutez une marge pour les pics de trafic, les tâches planifiées (sauvegardes, imports) et la croissance. Un serveur qui fonctionne en permanence à la limite de sa mémoire n’a aucune réserve en cas de pic.
Exemple de calcul : une boutique WooCommerce
Hypothèses à adapter à votre cas : 20 processus PHP-FPM consommant en moyenne 100 Mo chacun, une base de données de 3 Go, 512 Mo de cache Redis.
| Poste | Estimation |
|---|---|
| Système et services | 1 Go |
| PHP-FPM (20 × 100 Mo) | 2 Go |
| Base de données (données chaudes en mémoire) | 3 à 4 Go |
| Redis | 0,5 Go |
| Marge | 2 à 3 Go |
| Total | environ 8 à 10 Go |
Dans cet exemple, un VPS de 8 à 12 Go ou un petit serveur dédié de 16 Go conviennent. Un dédié de 32 Go laisserait de la place pour la croissance ou pour d’autres sites.
Des ordres de grandeur, à valider par la mesure
Ces fourchettes sont indicatives : elles servent à éviter les erreurs grossières, pas à remplacer un calcul.
| Usage | Ordre de grandeur |
|---|---|
| Site vitrine, blog | 2 à 4 Go |
| Boutique en ligne de taille moyenne | 8 à 16 Go |
| Plusieurs sites clients (agence) | 16 à 32 Go |
| Application SaaS, base de données importante | 32 à 64 Go et plus |
| Virtualisation de plusieurs environnements | 64 Go et plus |
Mesurer la consommation réelle
- À un instant donné : les commandes
free -h,topouhtopmontrent la mémoire utilisée, le cache et le swap. - Dans la durée : un outil de supervision (Netdata, Prometheus, Zabbix, ou celui de votre hébergeur) trace l’évolution et révèle les pics.
- Signal d’alerte : une utilisation régulière du swap ou des processus arrêtés par manque de mémoire indiquent qu’il faut optimiser ou augmenter la RAM.
Sous Linux, une mémoire « utilisée » en grande partie par le cache n’est pas un problème : le système libère ce cache dès qu’un programme en a besoin.
Ce qu’il faut vérifier dans une offre
- Type de mémoire : DDR4 ou DDR5 ; la mémoire ECC, qui détecte et corrige certaines erreurs, est préférable pour un usage professionnel.
- Évolutivité : sur un serveur dédié, augmenter la mémoire n’est pas toujours possible sans changer de serveur. Vérifiez les options proposées à la commande.
- Équilibre : beaucoup de mémoire avec un processeur ou des disques lents ne donnera pas un serveur rapide. Voir nos guides sur le processeur et le stockage NVMe.
Pour trouver une configuration correspondant à votre estimation, filtrez le comparateur par mémoire minimale.
Sources
- MySQL 8.4 Reference Manual, « Buffer Pool » : dev.mysql.com
- Documentation PostgreSQL, « Resource Consumption » (shared_buffers) : postgresql.org
- Manuel PHP, configuration de FPM (pm.max_children) : php.net
- Manuel PHP, directives du php.ini (memory_limit) : php.net