Dimensionner un serveur cloud : combien de CPU, RAM et SSD ?
Dimensionner un serveur cloud commence par la charge de travail, pas par le matériel. Ce guide donne des plages de départ en vCPU, RAM et disque pour les charges courantes, les associe aux presets Small, Medium et Large de la page serveur cloud DCXV et montre comment vérifier le résultat après le déploiement avec quelques commandes. Toutes les plages ci-dessous sont des estimations et des points de départ, pas des mesures. Votre code, votre trafic et vos données fixent les vrais chiffres.
Partir de la charge de travail
Notez quatre éléments avant d'ouvrir un configurateur : ce qui tourne (serveur web, base de données, application Windows), combien de personnes ou de requêtes arrivent à l'heure la plus chargée, combien de données vous avez aujourd'hui et à quelle vitesse elles grossissent.
Cherchez ensuite la ressource qui manque en premier. Une boutique PHP manque de RAM avant de manquer de CPU. Un serveur de build manque de CPU. Une base de données manque de RAM, puis de vitesse de disque. Dimensionnez pour ce goulot d'étranglement et laissez le reste suivre.
Plages de départ par charge de travail
Les presets : Small offre 2 vCPU, 4 Go de RAM, 40 Go NVMe à partir de EUR 15.00/mois. Medium offre 4 vCPU, 8 Go, 80 Go NVMe à partir de EUR 18.43/mois. Large offre 8 vCPU, 16 Go, 160 Go NVMe à partir de EUR 36.88/mois. Prix vérifiés en 2026-10, chaque prix inclut une sauvegarde hebdomadaire. Avant de comparer, voyez ce qui détermine le prix.
| Charge de travail | Plage de départ (estimation) | Preset le plus proche |
|---|---|---|
| Dev/test, VPN, supervision, outils | 1-2 vCPU, 1-4 Go RAM, 20-40 Go disque | Small |
| Petit site ou blog, peu de trafic | 2 vCPU, 2-4 Go RAM, 20-40 Go disque | Small |
| Boutique en ligne, API ou MVP SaaS | 2-4 vCPU, 4-8 Go RAM, 40-80 Go disque | Medium |
| Application avec sa propre base de données | 4-8 vCPU, 8-16 Go RAM, 80-160 Go disque | Medium ou Large |
| Application métier Windows/RDP | D'abord la formule de l'éditeur. M.E.Doc terminal : CPU = 4 + utilisateurs, RAM = utilisateurs x 2 Go + 4 Go | Large jusqu'à 4 utilisateurs, sur mesure au-delà |
Hypothèses : Linux, une application principale, trafic normal avec des pics occasionnels, pas de GPU ni de gros traitements par lots. Pour la ligne Windows, la formule de l'éditeur prime sur toute table : c'est une exigence, pas une estimation, et elle varie selon le type de déploiement, lisez donc la page actuelle de l'éditeur. Si vos chiffres se situent entre deux presets ou au-dessus de Large, composez une configuration sur mesure dans le calculateur de la page serveur cloud.
Un budget RAM détaillé pour une petite boutique
Voici un budget illustratif pour une boutique en ligne sur un serveur. Les chiffres sont des hypothèses, pas des mesures.
- Système et services - 0.5 Go.
- PHP-FPM - 10 workers x 100 Mo = 1 Go.
- Tampon de la base de données - 2 Go.
- Cache Redis - 0.5 Go.
- Cache de fichiers et pics - 1 Go.
Le total avoisine 5 Go. Un serveur de 4 Go utiliserait le swap en charge. Un serveur de 8 Go garde environ 3 Go libres, soit un tiers. Remplacez chaque ligne par vos propres chiffres une fois la boutique en service : les commandes ci-dessous les affichent.
Marge, système et stockage
- CPU - visez une charge soutenue sous 70 % environ à l'heure la plus chargée, pour qu'un pic ne mette pas les requêtes en file.
- RAM - gardez 20 à 25 % disponibles. Un swap permanent signifie que le serveur est trop petit.
- Disque - restez sous 80 % de remplissage. Bases, journaux et mises à jour grossissent plus vite que prévu.
- Système - un Linux minimal tient en quelques centaines de Mo. Windows Server avec bureau demande quelques Go avant même le lancement de votre application (estimation).
La capacité de sauvegarde n'est pas du stockage de production
Le prix de chaque preset inclut une sauvegarde hebdomadaire. C'est une copie de secours du disque du serveur, pas de l'espace supplémentaire pour vos fichiers. Ne la comptez pas lors du dimensionnement du disque et ne prévoyez pas de garder archives, médias ou dumps "dans la sauvegarde". Les données de production vivent sur le disque du serveur : dimensionnez-le pour les données, la croissance et la marge. Avant un changement risqué, ajoutez un snapshot : voir snapshots de VM cloud.
Mesurer après le déploiement
Mesurez pendant une heure chargée normale, puis pendant un pic. Sous Debian ou Ubuntu, iostat vient du paquet sysstat. Pour échantillonner la RAM sur une semaine entière et obtenir une taille adaptée, utilisez le script ramuse.py de mesurer la RAM que vous utilisez vraiment pendant la pénurie de DRAM de 2026.
top -b -n 1 | head -n 15
free -h
vmstat 5 5
df -h
sudo apt install sysstat
iostat -xz 5 3
ps -eo pid,comm,%mem,%cpu --sort=-%mem \
| head -n 8
sudo du -xh --max-depth=1 /var \
| sort -h \
| tail -n 8
Comment lire la sortie :
- top - comparez la charge moyenne au nombre de vCPU. Une charge durablement supérieure indique une pression CPU. La valeur
stest le temps CPU pris par l'hôte. - free - lisez la colonne
available, pasfree. - vmstat - des valeurs non nulles de
sietsoindiquent du swap. - iostat - un
%utilélevé et unawaitcroissant montrent que le disque est le goulot.
Pour une application entière plutôt qu'une seule charge, suivez l'exemple détaillé dans Dimensionner un serveur cloud pour un SaaS : un budget mémoire par conteneur, un test de charge k6 et une fiche imprimable.
Choisir et vérifier
Prenez le preset le plus proche du tableau et faites-le tourner sous charge réelle. Un court test est la façon honnête de vérifier une estimation : voyez la liste de contrôle de l'essai. Écrivez à sales@dcxv.com pour demander un court essai ; il est laissé à la discrétion de DCXV et n'est pas garanti. Un doute sur vos chiffres ? Envoyez vos besoins à sales@dcxv.com, un ingénieur les examinera, ou ouvrez la page serveur cloud et choisissez un preset.
