vCPU d'un VPS : pourquoi tous les hébergeurs ne se valent pas

Qu'est-ce qu'un vCPU ?

Un vCPU (virtual CPU) est une unité de calcul attribuée à un serveur virtuel par l'hyperviseur du serveur physique hôte. Contrairement à ce que les tableaux comparatifs laissent croire, un vCPU n'est pas une unité standardisée : sa puissance réelle dépend du processeur physique sous-jacent, du ratio de surallocation appliqué par l'hébergeur et du type de virtualisation utilisé.

Quand vous louez un VPS, vous obtenez un serveur virtuel hébergé sur du hardware partagé dans un data center. Le nombre de vCPU annoncé correspond à une allocation de ressources de calcul virtuelles, pas à une quantité de matériel physique dédié à votre environnement.

Sur un serveur équipé d'un processeur Intel avec Hyper-Threading ou AMD avec SMT, chaque coeur physique expose deux threads matériels. Dans la majorité des offres VPS, 1 vCPU = 1 thread matériel = la moitié d'un coeur physique. Google Cloud le formule clairement dans sa documentation : chaque vCPU est un thread matériel, et deux vCPU partagent un coeur physique par défaut.

Les processeurs ARM (Ampere Altra, AWS Graviton) ne disposent pas de SMT : 1 vCPU correspond alors à un coeur physique complet. De même, certaines gammes AMD EPYC récentes désactivent le SMT, offrant un coeur entier par vCPU.

Deux VPS affichant "4 vCPU" peuvent donc reposer sur des réalités matérielles très différentes : 4 threads sur un Xeon E5 de 2016, ou 4 coeurs complets sur un EPYC de dernière génération. La ligne "vCPU" d'un bon de commande ne dit rien de la puissance réelle sans connaître le modèle de processeur et la politique de partage de l'hébergeur.

Les cinq réalités derrière la mention "vCPU"

Pour comprendre pourquoi les performances varient autant entre serveurs virtuels, il faut distinguer cinq configurations matérielles (hardware) que les hébergeurs regroupent toutes sous le même terme :

Un hébergeur qui affiche "4 vCPU" peut vendre la troisième, la quatrième ou la cinquième ligne de ce tableau. Seule la lecture attentive des conditions, combinée à un test réel sur votre VPS, permet de savoir ce que vous achetez vraiment. Pour aller plus loin sur le choix entre VPS et serveur dédié : serveur dédié bare metal vs VPS.

Surallocation (overcommit) : le ratio qui change tout

La surallocation consiste à attribuer plus de vCPU à l'ensemble des serveurs virtuels hébergés sur un serveur physique qu'il n'a de coeurs réels. Le pari de l'hébergeur : tous les clients n'utilisent jamais 100 % de leur allocation en même temps.

Un ratio de 2:1 signifie que deux vCPU partagent un coeur physique. À 4:1, quatre VPS se disputent le même coeur. Les ratios courants dans l'industrie :

• 1:1 à 2:1 : offres premium ou dédiées, performances prévisibles ;
• 3:1 à 4:1 : offres standard, performances correctes en usage courant ;
• 6:1 à 10:1 : offres à bas prix, ralentissements fréquents en heure de pointe.

Plus le ratio est élevé, plus vous dépendez de la charge des autres VM sur le même hôte. C'est le phénomène du voisin bruyant (noisy neighbor) : un autre VPS sur le même serveur physique consomme ses coeurs au maximum, et votre propre serveur virtuel se retrouve en attente de temps CPU.

Dans un data center, chaque serveur physique peut héberger plusieurs dizaines de serveurs virtuels. La densité de placement et la politique de surallocation varient d'un hébergeur à l'autre, ce qui explique les écarts de performances entre des offres de prix comparables.

CPU steal : détecter la surallocation sur votre VPS

Le steal time (affiché %st dans top ou vmstat) mesure le pourcentage de temps pendant lequel votre vCPU était prêt à exécuter du code mais n'a pas reçu de temps processeur de la part de l'hyperviseur. C'est l'indicateur le plus direct de la surallocation, visible depuis le système d'exploitation de votre serveur virtuel.

Comment le lire :

• Sous 2 % : situation normale, pas de contention significative ;
• 2 à 5 % : surallocation modérée, acceptable pour la plupart des usages ;
• Au-dessus de 5 % : surallocation excessive, vos processus subissent des latences imprévisibles ;
• Au-dessus de 20 % : le serveur hôte est en surcharge, les performances sont fortement dégradées.

Pour surveiller le steal time en continu depuis votre système d'exploitation Linux :

vmstat 1 10

La colonne st (dernière colonne de la section CPU) affiche le steal time en pourcentage. Un pic ponctuel n'est pas inquiétant, mais un steal time régulièrement au-dessus de 5 % signale un problème côté hébergeur. Pour surveiller l'ensemble des ressources de votre VPS : surveiller les ressources avec htop et btop.

Vérifier le processeur réel de votre VPS

Avant toute comparaison, identifiez le hardware réel qui se cache derrière vos vCPU. Connectez-vous en SSH (en root ou via un utilisateur sudo) à votre serveur virtuel et exécutez :

lscpu

Les lignes à regarder :

• Model name : le modèle exact du processeur hôte (ex. AMD EPYC 7763, Intel Xeon Gold 6348) ;
• CPU(s) : le nombre de vCPU attribués à votre VM ;
• Thread(s) per core : 1 = pas de SMT (coeur complet par vCPU), 2 = SMT actif (thread par vCPU) ;
• Hypervisor vendor : KVM, VMware, Microsoft, Xen (indique la technologie de virtualisation) ;
• CPU MHz : la fréquence effective actuelle, utile pour détecter un bridage.

Si lscpu affiche un modèle générique comme "QEMU Virtual CPU", l'hébergeur masque le processeur réel. Essayez cat /proc/cpuinfo | grep "model name" pour obtenir plus de détails sur le hardware sous-jacent.

Mesurer les performances réelles avec sysbench

sysbench est l'outil de référence pour comparer les performances CPU entre serveurs virtuels. Il calcule des nombres premiers et mesure le débit en événements par seconde, ce qui permet une comparaison directe entre machines.

Installation sur Debian/Ubuntu :

sudo apt update && sudo apt install -y sysbench

Test monocoeur (mesure la puissance d'un seul vCPU) :

sysbench cpu --threads=1 --time=30 run

Test multicoeur (utilise tous les vCPU attribués) :

sysbench cpu --threads=$(nproc) --time=30 run

Repères pour le test monocoeur :

• Plus de 5 000 événements/s : processeur récent (EPYC Genoa/Milan, Xeon Gold/Platinum récent), excellent ;
• 3 000 à 5 000 événements/s : processeur de génération intermédiaire, bon ;
• Moins de 2 000 événements/s : processeur ancien ou surallocation importante, insuffisant pour des charges exigeantes.

Exécutez le benchmark à différentes heures (matin, soirée, week-end) pour évaluer la stabilité. Sur un VPS correctement dimensionné, les résultats ne devraient pas varier de plus de 10 à 15 %. Des écarts supérieurs signalent une surallocation qui affecte les performances de façon imprévisible.

Pour diagnostiquer une surcharge CPU sur un serveur de jeu : diagnostiquer une surcharge CPU.

Coeurs partagés vs coeurs dédiés : quelle différence en pratique ?

Avec des coeurs partagés, l'hyperviseur distribue le temps CPU entre plusieurs serveurs virtuels. Les performances fluctuent selon l'activité des voisins sur le même serveur physique. C'est le modèle de la plupart des offres VPS d'entrée de gamme.

Avec des coeurs dédiés, les coeurs physiques sont épinglés (pinned) à votre VM. Aucun autre client ne partage ces coeurs : les performances sont constantes et prévisibles. C'est le modèle des offres VPS premium et des serveurs dédiés.

En pratique, les benchmarks montrent des écarts importants entre ces deux modèles :

• Un VPS à coeurs dédiés peut atteindre des performances proches d'un serveur bare metal ;
• Un VPS suralloué à 4:1 peut perdre jusqu'à 40 % de performances CPU par rapport au même matériel en dédié ;
• La latence (temps de réponse) est plus touchée que le débit brut : sur des serveurs de jeu ou des bases de données, les micro-coupures causées par le steal time provoquent des saccades ou des ralentissements visibles.

Pour un serveur de jeu FiveM, Minecraft ou Rust avec des joueurs connectés en permanence, des coeurs dédiés ou un ratio de surallocation faible sont indispensables pour maintenir un tick rate stable.

Le rôle de l'hyperviseur

L'hyperviseur est le logiciel qui crée et gère les environnements virtuels sur le serveur physique. Les trois principaux dans l'hébergement VPS :

• KVM (Kernel-based Virtual Machine) : intégré au noyau Linux, c'est le standard de l'industrie pour les VPS. Il offre une virtualisation matérielle complète avec un overhead minimal. C'est l'hyperviseur utilisé par la plupart des hébergeurs sérieux ;
• VMware ESXi : hyperviseur propriétaire, utilisé principalement en entreprise. Performances proches de KVM, mais les licences augmentent le coût des offres ;
• Xen / Citrix Hypervisor : historiquement populaire (AWS l'a longtemps utilisé), progressivement remplacé par KVM dans les nouvelles infrastructures.

L'hyperviseur influence les performances par son overhead de virtualisation (le coût de la couche de traduction entre la VM et le hardware) et par sa politique d'ordonnancement CPU (comment il distribue le temps processeur entre les serveurs virtuels). Un KVM bien configuré avec du CPU pinning et un alignement NUMA correct ajoute moins de 2 % d'overhead.

Avec l'essor du cloud computing, KVM s'est imposé comme la référence pour héberger des serveurs virtuels à toutes les échelles, de l'hébergement mutualisé aux clusters haute disponibilité en passant par les offres VPS classiques.

Critères à vérifier avant de comparer deux offres VPS

Les tableaux comparatifs se limitent souvent au nombre de vCPU, à la RAM et au stockage. Ces chiffres ne suffisent pas. Voici les critères réellement discriminants :

1. Modèle de processeur : un vCPU sur un EPYC 9004 (Genoa, Zen 4) n'a rien à voir avec un vCPU sur un Xeon E5 v3 de 2014. L'IPC (instructions par cycle) et la fréquence varient du simple au double ;
2. Type de coeurs : partagés (shared) ou dédiés (dedicated). Certains hébergeurs ne le précisent pas, ce qui signifie généralement des coeurs partagés ;
3. Ratio de surallocation : rarement annoncé, mais mesurable via le steal time. Testez avant de vous engager ;
4. Hyperviseur et technologie : KVM avec virtualisation matérielle est le standard de référence ;
5. Fréquence et génération CPU : un processeur à 3,5 GHz de 2024 est plus rapide par cycle qu'un processeur à 3,5 GHz de 2017 ;
6. Stockage SSD : NVMe en accès direct ou SAN partagé. Les I/O disque impactent indirectement les performances CPU (un processus bloqué en attente d'I/O libère du CPU, mais un stockage lent peut devenir le goulot d'étranglement). L'espace disque disponible et le type de support (SSD NVMe vs disques durs) influencent directement la réactivité du système d'exploitation. Voir diagnostiquer les I/O disque avec iostat ;
7. Bande passante et réseau : la bande passante allouée et la qualité du réseau du data center déterminent les performances réseau de votre serveur virtuel. Un VPS avec d'excellents vCPU mais une bande passante bridée sera limité pour héberger un serveur web à fort trafic ;
8. Sauvegardes et redondance : vérifiez si l'hébergeur inclut des sauvegardes automatiques (backup) et quel niveau de redondance est assuré au sein du data center. Un incident matériel sans backup ni redondance signifie une perte de données ;
9. Système d'exploitation et accès root : confirmez que le VPS permet l'installation du système d'exploitation de votre choix avec un accès root complet, indispensable pour exécuter vos propres benchmarks et diagnostics ;
10. Évolutivité : possibilité d'ajouter des vCPU, de la RAM ou de l'espace disque sans migration vers un autre serveur. La flexibilité de mise à l'échelle évite de devoir migrer manuellement vos données vers un nouveau VPS.

La seule façon fiable de comparer : commander un VPS chez chaque hébergeur, exécuter les mêmes benchmarks (sysbench, fio), mesurer le steal time sur plusieurs jours, et comparer les résultats à prix égal.

Checklist : évaluer un VPS avant de s'engager

Avant de souscrire une offre VPS pour héberger un projet en production, vérifiez ces points :

1. Connectez-vous en SSH (en root) et exécutez lscpu pour identifier le processeur réel ;
2. Lancez vmstat 1 60 et relevez le steal time moyen ;
3. Exécutez sysbench cpu --threads=1 --time=30 run et comparez avec les repères ci-dessus ;
4. Répétez le test à différentes heures pour mesurer la variabilité ;
5. Vérifiez que l'hébergeur annonce le modèle de processeur et le type de coeurs (partagés ou dédiés) ;
6. Confirmez les options de sauvegardes automatiques (backup) et de restauration proposées ;
7. Évaluez la bande passante incluse et les éventuels frais de dépassement ;
8. Vérifiez la possibilité de migrer vers une offre supérieure (évolutivité) sans interruption prolongée ;
9. Consultez les conditions pour savoir si un engagement minimum est requis avant de tester.

Pour la configuration réseau et l'accès SSH initial : configurer une clé SSH sur un VPS Linux.