Entre un serveur dédié et une VM, la fiche produit peut paraître claire, puis les métriques se contredisent. Le nombre de cœurs annoncés ne dit pas si vous disposez d’un processeur physique réservé ou d’un partage discret.
Sur une plateforme virtualisée, les vCPU affichés correspondent à des unités de temps processeur, pas à des cœurs garantis. Une ressource virtuelle peut être plafonnée, mise en concurrence ou surallouée, ce qui influe sur la latence et le débit. Avec un hyperviseur moderne, l’ordonnancement privilégie l’équité globale, et votre charge varie selon les voisins.
Ce que recouvrent CPU et vCPU dans un environnement informatique
Sur un serveur, le CPU est une puce réelle, soudée ou enfichée, qui exécute les instructions. Son architecture processeur précise la gestion des caches, des interruptions et du parallélisme. Selon la charge, ses unités de calcul traitent les entiers, le chiffrement ou le vectoriel, sans que le système voie le détail matériel.
Dans une machine virtuelle, un vCPU n’est qu’un « siège » réservé auprès de l’hyperviseur, qui distribue des cycles entre plusieurs invités. Cette virtualisation des ressources rend le nombre affiché trompeur si l’hôte manque de marge. Pour relier besoins et matériel, viser le bon CPU du côté hôte reste plus parlant que la valeur vCPU.
Un vCPU correspond‑il vraiment à un cœur physique ?
Dans le cloud, un vCPU ne coïncide pas toujours avec un cœur dédié. Avec les cœurs et threads, l’hyperviseur peut placer deux vCPU sur un même cœur logique, et les faire tourner à tour de rôle selon le temps processeur disponible. Quand plusieurs VM réclament la CPU en même temps, des écarts apparaissent, par exemple :
- un hôte surchargé par d’autres VM
- une instance à qui l’on a attribué trop de vCPU
- des pics simultanés sur plusieurs services
- des limites de quotas appliquées par le fournisseur
Attribuer plus de vCPU peut accroître l’attente, car l’hyperviseur doit trouver des créneaux simultanés.
Sur des hôtes très chargés, un réglage fin peut stabiliser la latence. Le mappage vCPU (pinning) fixe des vCPU sur des cœurs précis, et une affinité CPU limite les migrations de threads. Le gain est réel pour des bases transactionnelles, mais la flexibilité globale diminue.
Allocation des vCPU par les hyperviseurs
Un hyperviseur expose des processeurs virtuels aux VM et décide, à chaque instant, quel cœur physique exécute quel thread. Sa politique d’allocation s’appuie sur un scheduler d’hyperviseur qui distribue des tranches de temps, parfois avec une réserve de CPU pour limiter les à-coups quand l’hôte sert plusieurs charges simultanées.
Quand plusieurs VM demandent un pic au même moment, l’hyperviseur place des vCPU en attente et alterne l’exécution. Le partage des cycles cherche un débit stable, mais une VM interactive peut ressentir des micro-pauses si l’hôte est déjà chargé. Exemple : deux VM de 4 vCPU sur un serveur 8 cœurs restent fluides tant que leurs pointes ne coïncident pas entre elles.
Comment le surprovisionnement affecte les performances ?
Le surprovisionnement apparaît quand la somme des vCPU attribués dépasse les cœurs réellement disponibles lors d’un pic. La contention CPU augmente, le temps « CPU ready » grimpe, et la latence d’exécution devient visible sur un serveur web, une compilation ou une base de données. Les applications temps réel, elles, supportent mal ces attentes même si les vCPU affichés semblent encore nombreux.
Quand l’hôte approche sa limite, les temps de réponse s’allongent et les threads se synchronisent moins bien. La saturation des ressources se répercute sur les files d’E/S, car des tâches CPU retardées libèrent plus tard leurs verrous et buffers. Réduire des vCPU inutilisés, ajuster les parts, ou isoler une VM sensible sur des cœurs dédiés atténue le phénomène.
Métriques utiles pour comparer CPU et vCPU
Les chiffres remontés par l’OS invité ne racontent pas toute l’histoire, car l’hyperviseur arbitre l’accès au processeur. Sur un tableau de bord, la utilisation CPU affichée par vCPU décrit la demande de la VM, pas la disponibilité réelle sur l’hôte. Un autre indicateur parle plus franchement, le temps volé mesuré par Linux en “steal”, qui grimpe quand d’autres VM passent avant vous. Au-delà de 5 %, la latence se ressent vite côté application.
Pour comparer des hôtes, observez la marge de calcul réellement disponible. Le ratio vCPU/CPU retenu éclaire le surbooking, puis les instructions par cycle lues via les compteurs matériels montrent le rendement à fréquence identique en pratique.
| Métrique | Où la lire | Unité | Repère chiffré |
|---|---|---|---|
| Utilisation CPU | OS invité / hyperviseur | % | 100 % correspond à 1 vCPU occupé |
| Temps volé (steal) | OS invité (Linux) | % | 0 % indique aucune attente liée au partage CPU |
| Surbooking (ratio vCPU/CPU) | Hyperviseur | ratio | 2:1 signifie 2 vCPU alloués pour 1 CPU logique |
| SMT / Hyper-Threading (si activé) | Hôte | threads par cœur | 2 threads par cœur sur la majorité des plateformes x86 |
Quelle configuration choisir pour une machine virtuelle ?
Le bon point de départ vient des mesures de l’application en production ou en test de charge. Selon le profil de charge, vous visez un dimensionnement vCPU modéré puis vous vérifiez la latence et la file d’attente. Pour guider l’ajustement, voici des repères simples. Ils évitent d’augmenter les cœurs si l’IO bloque déjà.
- Démarrer avec 2 à 4 vCPU, puis monter si la file CPU s’allonge.
- Comparer les temps de réponse quand plusieurs VM cohabitent sur le même hôte.
- Vérifier le stockage et le réseau avant d’ajouter des cœurs virtuels.
- Documenter les pics, par exemple exports, indexations ou batchs nocturnes.
Un ralentissement peut venir du stockage partagé ou d’une bande passante limitée, même si les cœurs sont libres. Le suivi de la mémoire et IO aide à écarter ces goulots. Si l’application scale mal, l’évolutivité verticale garde un chemin clair pour vos services.
Impact de la topologie CPU : cœurs, threads et sockets
Selon l’hyperviseur, la présentation du processeur à la machine virtuelle influence la latence. Sur un hôte à plusieurs sockets, la mémoire n’est pas uniforme : NUMA et sockets dictent où résident les données, et un vCPU mal placé paie des allers‑retours à chaque accès.
Le nombre de vCPU ne se résume pas à un chiffre : la façon dont ils sont mappés change le débit. Avec l’hyperthreading, deux threads partagent des unités, donc 8 vCPU n’offrent pas 8 cœurs pleins. Ajustez la topologie virtuelle pour coller au matériel, puis réservez l’affinité des cœurs aux applications sensibles, sous peine de brider le planificateur quand la charge varie d’une minute.
Un vCPU représente un temps d’exécution arbitré, pas un cœur physique réservé.
vCPU et licences logicielles : y a‑t‑il des pièges ?
Avant d’ajouter des vCPU, vérifiez le contrat qui encadre le logiciel installé dans la VM. Certains éditeurs appliquent des licences par cœur et considèrent chaque vCPU comme un cœur facturable, même si l’hôte mutualise le calcul, ce détail peut doubler la facture en production.
Les conditions changent selon la version, l’édition et le mode de virtualisation, et un audit arrive sans annonce. Pour tenir la conformité éditeur, alignez les vCPU sur les métriques de licensing du contrat et gardez une trace des plafonds CPU, des hôtes autorisés et du périmètre du cluster en cas de déplacement d’une VM.
Bonnes pratiques de monitoring et de tuning
Quand une VM paraît lente, regardez la latence, les files d’attente et le temps de réponse. Un simple graphe d’usage moyen masque les pointes courtes : elles suffisent à faire grimper la congestion et à brouiller le diagnostic global.
Un relevé ne tranche pas entre calcul saturé et attente d’I/O. Croisez un profilage système avec des métriques de performance telles que run queue et steal time. Ajustez l’affinité CPU et l’optimisation du scheduler quand des vCPU se heurtent sur un même cœur. Des alertes proactives sur tendances signalent le risque avant le pic.
CPU, vCPU et conteneurs : quelles différences d’approche ?
Un conteneur n’achète pas des vCPU à un hyperviseur : il partage le CPU du noyau hôte. La vraie question porte sur la part de cycles accordée à votre service, sans pénaliser les autres processus sur la machine au fil des pics.
Les tests de charge révèlent si une API se retrouve bridée ou trop gourmande. Paramétrez des quotas CPU, puis vérifiez les cgroups et leurs limites (cpu.max, cpu.shares) pour que le noyau applique la contrainte. L’isolation des workloads passe par des pools dédiés ou des nœuds Kubernetes séparés quand un batch perturbe la production réelle.
FAQ sur la différence entre CPU et vCPU
Quelle est la différence entre un CPU et un vCPU ?
Un CPU est un processeur physique installé dans un serveur, composé d’un certain nombre de cœurs matériels. Un vCPU est une unité de calcul virtuelle attribuée à une machine virtuelle. Il correspond en général à un thread ou à une part de temps processeur sur un cœur physique, partagée avec d’autres vCPU.
Combien de vCPU correspondent à un CPU physique ?
Le ratio vCPU/CPU varie selon l’hébergeur et la charge visée. On trouve fréquemment des ratios de 2:1 à 8:1, c’est‑à‑dire plusieurs vCPU par cœur physique. Plus le ratio est élevé, plus la puissance brute par vCPU peut diminuer en période de forte charge, car les ressources sont partagées.
Un vCPU est-il moins performant qu’un cœur CPU dédié ?
Un vCPU dispose d’une partie du temps de calcul d’un cœur physique, parfois partagée avec d’autres vCPU. Lorsque le serveur est peu chargé, les performances peuvent se rapprocher d’un cœur dédié. En cas de forte contention, la latence augmente et le vCPU délivre moins de puissance, surtout pour les applications très gourmandes.
Un vCPU équivaut-il toujours à un thread de CPU avec l’hyper-threading ?
Dans de nombreuses infrastructures, un vCPU est mappé à un thread logique issu de l’hyper-threading. Ce n’est pas une règle absolue : certains hyperviseurs peuvent lier un vCPU à un cœur complet ou modifier cette association selon la configuration. La performance d’un vCPU dépend donc de la topologie CPU et des réglages de l’hyperviseur.
Comment choisir le bon nombre de vCPU pour un serveur ?
Le choix du nombre de vCPU dépend des usages : applicatif web, bases de données, traitement batch, virtualisation de postes, etc. Une approche prudente consiste à démarrer avec un nombre modéré de vCPU, surveiller la charge (CPU steal, load average, temps de réponse) puis ajuster à la hausse ou à la baisse selon les besoins réels.