De combien de RAM aurez-vous réellement besoin pour vos serveurs et VPS en 2025 ?

Le dimensionnement de la mémoire vive (RAM) relève du calcul de la charge de travail, et non d’un benchmark. Si vous surdimensionnez, vous payez pour une capacité inutilisée. Si vous sous-dimensionnez, vos processus seront interrompus, votre base de données s’exécutera à partir du disque plutôt que de la mémoire, ou vos conteneurs seront bridés. Ce guide fournit des fourchettes de RAM concrètes pour les charges de travail les plus courantes (hébergement web, bases de données, virtualisation, conteneurs, inférence IA et serveurs de jeux), ainsi que les règles à appliquer pour dimensionner une charge de travail ne figurant pas dans la liste.

Rôle de la mémoire vive (RAM) dans un serveur

La RAM contient tout ce sur quoi le serveur travaille activement : la mémoire des processus pour les serveurs web, les moteurs de bases de données et les démons d’arrière-plan ; le cache de pages au niveau du système d’exploitation et les tampons d’E/S disque ; la mémoire d’exécution pour les applications et les conteneurs ; ainsi que les blocs de mémoire alloués aux machines virtuelles ou aux charges de travail des conteneurs.

Ce qui différencie le dimensionnement de la RAM de celui du processeur, c’est le mode de défaillance. À court de processeur, les processus ralentissent. À court de RAM, soit le noyau recourt au swap (lent), soit le « OOM killer » choisit une victime et la termine. La première situation est désagréable. La seconde entraîne une perte de données. Prévoir de la RAM avec une marge n’est pas un simple plus, c’est ce qui empêche le système de s’effondrer sous la charge.

Mémoire vive (RAM) en fonction de la charge de travail

Serveurs web et d’applications

• Pile LAMP ou LEMP allégée : 1 à 2 Go
• WordPress ou CMS avec mise en cache (par ex. Redis) : 2 à 4 Go
• E-commerce (Magento, WooCommerce) : 4 à 8 Go
• Applications Node.js, Django ou Rails : 2 à 6 Go

Les couches de mise en cache telles que Redis ou Varnish nécessitent de la mémoire vive qui leur est propre, en plus de la mémoire de base requise par l’application. Les workers PHP-FPM, les connexions aux bases de données et les proxys inversés consomment tous de la mémoire simultanément ; c’est donc le parallélisme de pointe qui importe, et non l’empreinte mémoire au repos.

Serveurs de bases de données (SQL et NoSQL)

• MySQL ou PostgreSQL (petit) : 4 à 8 Go
• MySQL ou PostgreSQL (de grande taille ou à fort trafic) : 16 à 64 Go
• MongoDB ou Redis (axés sur la mémoire) : 32 à 128 Go ou plus
• Nœuds Elasticsearch ou OpenSearch : 32 à 128 Go par nœud

L'objectif est de conserver en mémoire vive (RAM) le jeu de travail, les index et les lignes fréquemment consultées. Dès que l'un de ces éléments est transféré sur le disque, la latence augmente de plusieurs ordres de grandeur, quelle que soit la vitesse du SSD.

Hôtes de virtualisation (Proxmox, VMware, Hyper-V)

• Machines virtuelles Linux légères : 2 à 4 Go par machine virtuelle
• Machines virtuelles Windows : 8 à 12 Go par machine virtuelle
• Panneaux d’hébergement (cPanel, Plesk, DirectAdmin) : 4 à 8 Go par instance
• Hôtes de conteneurs KVM ou LXC : 32 à 128 Go ou plus

Réservez toujours 4 à 8 Go pour le système d’exploitation hôte lui-même, en plus des allocations allouées aux machines invitées. Les conteneurs utilisent moins de RAM par charge de travail que les machines virtuelles complètes, mais leur évolutivité est différente ; il faut donc prévoir une marge de densité et de pic de charge plutôt que de se baser sur la taille par conteneur. Si l’hôte utilise ZFS, tenez également compte de l’ARC, qui, par défaut, occupera silencieusement jusqu’à la moitié de la mémoire vive du système et entrera en concurrence avec les allocations des machines invitées (notre guide d’optimisation de l’ARC ZFS indique les limites appropriées pour les charges de travail des hyperviseurs).

Conteneurs et microservices (Docker, Kubernetes)

• Piles Docker simples (web, application, base de données) : 8 à 16 Go
• Nœuds périphériques Docker Swarm ou K3s : 16 à 32 Go
• Nœuds de travail Kubernetes : 32 à 128 Go
• Exécuteurs CI/CD et agents de build (GitLab, Jenkins) : 8 à 32 Go par exécuteur

Surveillez les fuites de mémoire sur les conteneurs s’exécutant sur de longues durées. Les charges de travail basées sur la JVM, telles que Kafka et Elasticsearch, nécessitent des seuils de base plus élevés, car le tas de mémoire s’étend autant que vous le lui permettez, ce qui est souvent supérieur à ce que vous aviez prévu.

Inférence IA et ML

• Petits modèles (BERT quantifié, Llama 7B) : 16 à 32 Go
• Modèles de taille moyenne (de 13B à 30B, quantifiés) : 64 à 128 Go
• Grands modèles (40 milliards et plus ou modèles de taille moyenne non quantifiés) : 128 à 512 Go ou plus
• Inférence sur GPU (Stable Diffusion, Whisper) : de 32 à 128 Go selon le niveau de déchargement

La quantification transfère la charge mémoire du GPU vers la RAM du CPU ; les spécifications du système varient donc considérablement selon que vous traitez des données en fp16 sur le GPU ou en 4 bits sur le CPU. La taille des lots et la longueur des prompts font également augmenter ces chiffres. Notre guide sur l’hébergement de l’inférence IA aborde plus en détail l’adéquation entre le matériel et la taille des modèles.

Serveurs de jeux

• Minecraft (version standard) : 2 à 4 Go
• Minecraft (moddé) : 6 à 16 Go
• Rust, ARK ou 7 Days to Die : 8 à 16 Go
• Nœuds d’hébergement multi-instances : 32 à 64 Go

Charges de travail spécialisées

• Transcodage vidéo (FFmpeg, Plex) : 16 à 64 Go
• Serveurs de sauvegarde ou de snapshots : 8 à 16 Go, voire plus en cas d’exécution de moteurs de déduplication
• Pare-feu ou IDS (pfSense, Suricata) : 2 à 8 Go, voire davantage pour NetFlow ou la journalisation complète des paquets

Ne comptez pas sur la mémoire swap

La mémoire swap est 10 à 100 fois plus lente que la RAM. Elle sert de filet de sécurité pour que le noyau ait un endroit où se rabattre en cas de pics de pression sur la mémoire, et non comme moyen d’étendre la mémoire utilisable. Si un serveur utilise la mémoire swap sous une charge normale, c’est qu’il est sous-dimensionné, point final. L’article « Comment la mémoire swap sous Linux, l’OOM killer et les cgroups interagissent » traite en détail des modes de défaillance.

Comment dimensionner correctement la mémoire vive (RAM)

1. Mesurez les pics, pas la moyenne. Utilisez htop, free -m, vmstat 1ou de vos métriques Kubernetes pour déterminer l’utilisation de pointe sur un cycle de trafic complet. Les pics quotidiens, les lots hebdomadaires et les cycles de facturation mensuels sont tous pris en compte.
2. Prévoyez une marge de manœuvre pour la croissance : entre 20 % et 50 % pour la mise à l’échelle des applications. Pour les bases de données, adaptez la mémoire à la taille des ensembles de données, et non au taux de requêtes. Pour les plateformes multi-locataires, calculez l’empreinte mémoire par client et multipliez ce chiffre.
3. Prévoyez en fonction du mode de défaillance que vous pouvez tolérer. Une réplique de lecture à court de RAM voit ses performances se dégrader. Une base de données principale à court de RAM corrompt les requêtes et peut entraîner la panne des applications. Allouez la RAM là où l’impact est le plus important.

La RAM est la ressource pour laquelle un manque est plus préjudiciable qu’un excès. Ajouter de la mémoire ne rendra pas plus rapide une application limitée par le processeur, mais une configuration trop juste nuit à la stabilité. Déterminez la taille en fonction d’une surveillance réelle et de vos pics testés, puis prévoyez une marge.

FDC propose des serveurs dédiés et des VPS dotés de configurations à mémoire vive élevée et d’une bande passante illimitée dans plusieurs régions.