vCPU dédiée vs vCPU partagée : les trois raisons pour lesquelles vous subissez une limitation de performances

Presque toutes les explications concernant les vCPU partagés et dédiés se résument à : « Vous partagez des cœurs avec d'autres clients, donc les performances varient. » C'est vrai, mais inutile, car cela ne précise pas la nature du ralentissement ni comment identifier le type de ralentissement rencontré.

Il existe trois mécanismes distincts qui rendent un vCPU partagé plus lent qu'un vCPU dédié. Ils produisent des symptômes différents, sont diagnostiqués par des commandes différentes, et seul l'effet de voisinage bruyant dont tout le monde parle en est un.

Si vous savez déjà que vous avez besoin de cœurs dédiés et que vous souhaitez simplement savoir où en trouver, notre comparatif de VPS avec processeur dédié couvre le marché et les surcoûts. Cet article explique le fonctionnement interne de ces solutions.

Mécanisme 1 : Quota strict du SFC

Il s'agit du mécanisme de contrôle de bande passante propre au noyau Linux, et c'est le mécanisme le plus courant dans les conteneurs et sur de nombreuses plateformes VPS.

Le planificateur fonctionne par périodes , généralement de 100 millisecondes. Votre instance se voit allouer un quota de temps CPU par période, exprimé en microsecondes. Un demi-cœur correspond à un quota de 50 000 µs sur une période de 100 000 µs : vous pouvez utiliser 50 ms de temps CPU toutes les 100 ms.

Lorsque ce budget est épuisé, le noyau met vos processus en pause jusqu'au début de la période suivante. La documentation du noyau est sans équivoque à ce sujet :

« Pour chaque période (en microsecondes), un groupe de tâches se voit allouer un quota de temps CPU. […] Une fois ce quota atteint, toute demande supplémentaire entraînera la limitation du débit des threads concernés. Ces threads ne pourront pas s'exécuter à nouveau avant la prochaine période, lorsque le quota sera reconstitué. »

C'est brutal plutôt que progressif : vos fils ne ralentissent pas, ils s'arrêtent jusqu'à ce que l'horloge passe à la suivante.

Voici la partie qui surprend les gens, et qui explique beaucoup de latences mystérieuses :

Une limite de processeur impose un budget de pointe, et non un budget moyen. Une charge de travail qui dépasse cette limite pendant un intervalle de 100 ms est bridée durant cet intervalle, même si son utilisation moyenne sur la minute est bien inférieure à la limite.

Ainsi, une application affichant « 20 % d'utilisation du processeur » sur un graphique peut tout de même subir une limitation de bande passante plusieurs fois par seconde, car le graphique représente une moyenne et le quota est appliqué par période. On observe des pics de latence des requêtes ; l'utilisation moyenne du processeur semble correcte ; rien dans votre système de surveillance ne permet de l'expliquer.

Comment le prouver ? La limitation de bande passante est comptabilisée par le noyau, vous pouvez donc la lire directement :

cat /sys/fs/cgroup/cpu.stat

Chercher nr_throttled (combien de périodes ont été étranglées) et throttled_usec (temps total d'immobilisation). Sur cgroup v1, le fichier est cpu.cfs_throttled_time. Si nr_throttled Si votre connexion internet est lente alors que le taux de clics grimpe, vous avez trouvé la solution — et notez que Le temps de vol sera nul.Parce que personne n'a rien volé. Vous avez atteint un plafond, vous avez été vendu.

Mécanisme 2 : Crédits CPU à débit variable

Le modèle de crédits est celui popularisé par la série T d'AWS, et il produit le comportement spécifique qui rend les tâches longues mystérieuses : pleine vitesse pendant un certain temps, puis ralentissement.

Votre instance possède un niveau de performance de base et accumule des crédits en continu à un taux fixe. Un niveau de performance inférieur à la base permet d'accumuler des crédits ; un niveau supérieur les consomme. Tant que vous disposez d'un solde, vous bénéficiez de performances optimales. Lorsque le solde atteint zéro, le comportement dépend du mode :

• Mode Standard — votre puissance est réduite à la valeur de base, qui peut ne représenter qu'une petite fraction de la puissance maximale du processeur.
• Mode illimité — tu continues à exploser excédent Les crédits sont remboursables ultérieurement lorsque l'utilisation descend en dessous du niveau de base. Les instances T3 et T3a sont par défaut illimitées.

Il est important de lire attentivement la documentation d'AWS concernant le règlement des excédents, car la période comptable est plus longue qu'on ne le pense généralement : la plateforme calcule la moyenne de l'utilisation de votre processeur sur une période glissante de 24 heures. et « si le processeur moyen usage Si la consommation dépasse le seuil de référence sur une période de 24 heures, l'instance est facturée pour les heures supplémentaires.sage à un taux supplémentaire fixe par heure vCPU. Leur exemple concret est un t3.large Avec une consommation de base de 30 %, si vous utilisez le système à une moyenne de 40 % sur la journée, les 10 % supplémentaires vous seront facturés. (Ce tarif forfaitaire est généralement estimé à environ 0.05 $/vCPU-heure, bien que ce chiffre ne figure pas sur cette page.)

Le calcul de la moyenne sur 24 heures est un avantage : un pic de consommation passager est absorbé par une période calme l'après-midi. Ce n'est pas le cas pour une charge soutenue.

C’est pourquoi l’encodage vidéo ou l’exécution d’une boucle d’agent de longue durée peut prendre trois fois plus de temps que prévu. Les dix à quarante premières minutes s’exécutent à pleine vitesse grâce aux crédits accumulés. Ensuite, ces crédits s’épuisent et les performances reviennent à la normale pour le reste du processus. Aucun dysfonctionnement n’a été constaté ; la machine a parfaitement rempli sa fonction.

Comment le prouver. Les crédits ne sont pas visibles depuis l'intérieur de l'instance ; consultez les indicateurs du fournisseur (sur AWS, CPUCreditBalance et CPUSurplusCreditBalanceUn solde tendant vers zéro au moment où votre activité a ralenti est sans équivoque.

Le piège de la facturation en mode Illimité : vous ne subissez pas de ralentissement, vous êtes facturé. Une charge de travail soutenue sur une instance à capacité extensible en mode Illimité peut, sans que vous vous en rendiez compte, coûter plus cher qu’une instance dédiée, même si vous cherchiez à l’éviter.

Mécanisme 3 : Sursouscription — le véritable voisin bruyant

C'est celle que tout le monde appelle « partagée », et c'est la seule qui permette de voler du temps.

L'hôte alloue plus de vCPU à ses machines virtuelles invitées que de cœurs physiques, partant du principe raisonnable que toutes ne fonctionnent pas simultanément à pleine charge. Si cette hypothèse n'est plus vérifiée, l'hyperviseur doit faire un choix, et votre machine virtuelle attend qu'un cœur physique se libère avant de pouvoir s'exécuter.

Cette attente est du temps volé , et contrairement aux deux premiers mécanismes, il ne s'agit pas d'une limite documentée — il n'y a pas de quota publié, pas de solde créditeur, et généralement aucune confirmation que cela s'est produit.

Comment le prouver :

vmstat 1 10        # the st column
mpstat -P ALL 1 5  # %steal per core

Voici le calcul concret : 8 vCores avec un temps de vol de ressources de 50 % offrent 4 cœurs effectifs. Un nombre élevé de cœurs sur un hôte sollicité se traduit par un coût supplémentaire sur la facture.

Le tableau de diagnostic

Voici le bénéfice pratique : trois pannes qui semblent identiques et qui se distinguent en une minute environ :

Cette dernière ligne est plus importante que les trois autres réunies. De nombreux « problèmes de processeur » sont en réalité liés aux E/S disque ou à la mémoire virtuelle, et l'achat de cœurs dédiés ne résout aucun de ces problèmes. Vérifiez. iostat -x 1 5 pour l'utilisation du disque et free -h Pour éviter la pression de la mémoire avant de tirer des conclusions.

Qu'est-ce qu'un vCPU dédié garantit réellement ?

Un vCPU dédié est associé à un cœur physique non partagé avec un autre locataire. En pratique, cela supprime les mécanismes 1 et 3 (absence de plafond de quota et de vol de temps d'exécution), et le mécanisme 2 ne s'applique pas en l'absence de système de crédits.

Ce que cela ne fait pas , c'est augmenter la vitesse d'un cœur. Un cœur dédié à 2.5 GHz utilise la même puce qu'un cœur partagé à 2.5 GHz ; vous investissez dans la stabilité, pas dans la vitesse . Si votre application est suffisamment rapide lorsqu'elle s'exécute et que ses performances sont simplement irrégulières, un cœur dédié résout le problème. Si elle est trop lente à pleine fréquence, un cœur dédié ne change rien et vous avez besoin de plus de cœurs ou de meilleurs cœurs.

C'est pourquoi la vraie question n'est pas « partagé ou dédié » mais « mon cycle d'utilisation est-il suffisamment élevé pour qu'une limite de capacité soit problématique ? » Les charges de travail ponctuelles (une application web avec des pics de trafic, un outil d'intégration continue, un environnement de développement) sont précisément conçues pour cela, et elles y sont parfaitement adaptées. C'est en cas de charge continue que les mécanismes mentionnés précédemment se déclenchent.

Qui utilise quel modèle

De manière générale, et il est conseillé de vérifier ces informations auprès de la documentation actuelle avant d'acheter :

• Hébergeurs VPS traditionnels Hetzner, DigitalOcean, Vultr, Linode et d'autres plateformes similaires allouent des ressources par forfait plutôt que de fonctionner avec un système de crédits. Leurs offres partagées sont soumises à la sursouscription et, sur certaines plateformes, à des quotas ; leurs offres dédiées s'affranchissent de ces deux contraintes.
• familles hyperscaler à explosion — AWS série T notamment — utilise le modèle de crédit avec les modes Standard et Illimité.
• Plateformes de conteneurs et PaaS géré — tout ce qui exécute votre charge de travail dans un cgroup — utilise un quota CFS, c'est pourquoi les limites de CPU de Kubernetes sont une source si courante de latence inexpliquée.

La dénomination reste le piège que nous abordons dans notre guide dédié aux processeurs : la gamme CPX de Hetzner est partagée malgré un prix plusieurs fois supérieur à celui de la gamme CX, seul le CCX est dédié, et la « High Frequency » de Vultr correspond à une fréquence d'horloge plus élevée plutôt qu'à une fréquence isolée. Le mot clé est « dédié », et rien d'autre ne compte.

Que faire à ce sujet

Si vous atteignez votre quota CFS : augmentez la limite si vous pouvez la contrôler, ou passez à un forfait sans limite. Dans Kubernetes en particulier, envisagez de supprimer la limite de CPU tout en conservant la limite de requêtes ; c’est cette limite qui limite les ressources.

Si vous épuisez vos crédits : soit dimensionnez votre instance pour que votre charge en régime permanent reste inférieure à la charge de base, soit optez pour un forfait sans interruption. Si vous êtes en mode Illimité, vérifiez les frais de dépassement avant de conclure à des économies.

Si vous perdez du temps à cause de problèmes de connexion : les seules solutions efficaces sont de passer à des cœurs dédiés ou à un serveur moins gourmand en ressources. Aucune configuration au sein de la machine virtuelle ne permet de récupérer ce temps perdu. Si vous préférez éviter de devoir diagnostiquer ce problème à nouveau, Liquid Web propose du matériel dédié avec un service d'assistance dédié ; le coût par gigaoctet est élevé, mais vous n'aurez plus à vous soucier des conflits d'accès aux ressources. Notre comparatif de processeurs dédiés présente les solutions les plus économiques.

Si les trois tests sont concluants : le problème ne vient pas du processeur. Notre guide sur les VPS NVMe traite de la partie disque, notamment des raisons pour lesquelles les fournisseurs limitent les IOPS bien en deçà des capacités du disque, et notre guide sur l’offre 8 Go aborde la question de la gestion de la mémoire.

Comment nous avons sélectionné les explications

Les mécanismes décrits ici proviennent de la documentation sur le contrôle de la bande passante CFS du noyau Linux, de la documentation sur les instances à capacité variable d'AWS et de la documentation du plan du fournisseur, consultées en août 2026.

Nous n'avons pas effectué de tests de charge soutenus chez différents fournisseurs pour établir des courbes de limitation de bande passante. C'est la mesure la plus demandée, mais aussi la moins reproductible : les résultats dépendent du serveur physique sur lequel vous êtes connecté, de l'activité de vos voisins et de la génération de votre plan d'hébergement. Un chiffre mesuré le mois dernier ne serait pas valable pour vous. Les diagnostics ci-dessus s'exécutent sur votre instance en moins d'une minute et vous fournissent des informations fiables sur la machine que vous payez réellement.

QFP

Quelle est la différence entre un vCPU dédié et un vCPU partagé ?

Un vCPU dédié est lié à un cœur physique non utilisé par d'autres utilisateurs, vous garantissant ainsi des performances constantes, sans limite de quota ni perte de temps. Un vCPU partagé peut être soumis à un quota strict, à un solde de crédits ou à des conflits avec les autres utilisateurs. Le choix d'un vCPU dédié privilégie la stabilité à la vitesse brute : le cœur lui-même n'est pas plus rapide.

Pourquoi mon VPS partagé est-il rapide au début puis lent ?

C'est la caractéristique du modèle de crédit. Vous démarrez avec des crédits disponibles et fonctionnez à plein régime ; lorsque le solde est épuisé, vous revenez à la normale. Consultez l'indicateur de crédit de votre fournisseur — sur AWS, il s'agit de CPUCreditBalance — et vérifier si elle a atteint zéro au début du ralentissement.

Mon processeur usage Le taux est bas, mais mon application est lente. Pourquoi ?

Il s'agit très probablement d'une limitation du quota CFS. Les limites sont appliquées par période de 100 ms, et non en moyenne. Par conséquent, une charge de travail moyenne de 20 % peut dépasser la limite ponctuellement et entraîner une mise en attente. Vérifiez. nr_throttled in /sys/fs/cgroup/cpu.stat — Si ça grimpe, c'est votre cause, et le temps volé affichera zéro.

Un temps de vol d'informations élevé signifie-t-il que j'ai besoin d'un processeur dédié ?

Si le taux d'utilisation se situe constamment au-dessus de 5 à 10 % pendant les heures critiques, oui : aucun mécanisme interne à la machine virtuelle ne récupère les cycles volés. En dessous de 2 %, la contention n'est pas en cause et l'ajout de cœurs dédiés représenterait un surcoût de 2 à 5 fois sans gain notable.

Les vCPU partagés sont-ils une mauvaise chose ?

Non, leur capacité est adaptée aux charges de travail irrégulières, ce qui représente la plupart des cas. Une application web, un bot, un environnement de préproduction ou un poste de développement passent la majeure partie de leur temps quasiment inactifs ; payer pour des cœurs dédiés qui restent inutilisés est donc un gaspillage. Ce modèle devient inadapté lorsque la charge devient continue.

Comment savoir quel modèle de limitation de bande passante utilise mon fournisseur ?

Consultez la documentation de votre offre : recherchez les termes « extensible », « crédits » ou « performance de base ». Il s’agit alors d’un modèle à crédits. Les offres VPS classiques, qui indiquent un nombre fixe de vCPU sans performance de base, sont généralement basées sur des quotas ou la sursouscription. Si la documentation ne mentionne rien, exécutez les trois diagnostics ci-dessus en charge et observez le comportement de votre machine.