Overcommitment CPU : comment il ralentit les serveurs virtuels

Surcommande CPU ralentit les serveurs virtuels parce que l'hyperviseur alloue plus de vCPUs qu'il n'y a de noyaux physiques, ce qui entraîne des temps d'attente. Je montre les causes, des valeurs de mesure réelles comme le CPU Ready Time et des vis de réglage concrètes avec lesquelles je maintiens la stabilité des performances VPS.

Points centraux

Avant d'aller plus loin, je vais classer les aspects les plus importants et délimiter les malentendus typiques. De nombreux opérateurs confondent charge de travail élevée et efficacité, alors que les files d'attente caractérisent les temps de réponse. Ce sont les détails de l'ordonnanceur qui déterminent si les applications fonctionnent de manière fluide ou si elles sont bloquées. Je résume les thèmes clés sur lesquels je m'appuierai dans les chapitres suivants. Cette liste sert de référence compacte pour prendre des décisions rapides.

• planificateur et le time-slicing déterminent la manière dont les vCPU prennent leur tour.
• Prêt pour le CPU indique le temps d'attente et prévient rapidement des goulots d'étranglement.
• Invités de la SMP (plusieurs vCPU) aggravent l'overhead et la latence.
• Rightsizing et le monitoring permettent de maîtriser les pics de charge.
• Choix du fournisseur sans surréservation assure une performance constante.

Que signifie techniquement l'overcommitment du CPU ?

Overcommit signifie que j'alloue plus de cœurs virtuels que l'hôte n'en possède physiquement et que je m'appuie sur le planificateur de l'hyperviseur. KVM ou VMware allouent le temps de calcul via le Time-Slicing, ce qui semble discret en cas de faible charge et permet une densité apparemment élevée. Sous une charge parallèle, les temps d'attente augmentent toutefois, car plusieurs vCPU demandent du temps de calcul en même temps et l'ordonnanceur doit les planifier les uns après les autres. Red Hat avertit que les machines virtuelles SMP en particulier, avec de nombreux vCPU, perdent beaucoup dès que la somme des vCPU dépasse nettement les noyaux physiques [1]. Les experts de VMware quantifient cela par le biais du CPU Ready Time : 1000 ms de temps d'attente par vCPU correspondent à environ 5% de perte de performance, cumulée par cœur [3].

Pourquoi les serveurs virtuels sont ralentis

Files d'attente sont la principale raison pour laquelle les serveurs virtuels sont ralentis en cas de surréservation, même si l'utilisation du CPU semble élevée. Un vCPU ne peut fonctionner que lorsqu'un noyau physique est libre ; jusqu'à ce moment, le CPU Ready augmente et l'application attend. Dans le cas de plusieurs VM avec des pics parallèles, l'effet s'accentue car toutes sont „prêtes à fonctionner“ et l'ordonnanceur ne peut travailler que par tranches de temps. Ce sont surtout les charges de travail critiques en termes de latence, comme les bases de données, les API ou les backends de boutique, qui réagissent de manière sensible, car chaque changement de contexte supplémentaire et chaque retard déclenchent des effets en chaîne. J'observe alors des temps morts, des temps de réponse instables et une variance croissante qui irrite sensiblement les utilisateurs.

Les indicateurs de mesure : CPU Ready, Steal & Co.

Indicateurs comme CPU Ready, Co-Stop et Steal Time me montrent rapidement si l'overcommitment touche ma VM. CPU Ready dans les mesures de l'hyperviseur devrait rester en moyenne bien en dessous de 5% ; si la valeur atteint des pourcentages à deux chiffres, le débit s'effondre sensiblement [3]. Co-Stop signale que les machines virtuelles SMP ne peuvent pas être planifiées simultanément, ce qui ralentit le multi-threading. Je lis dans les invités Linux le Steal Time, qui indique combien de temps l'hôte soustrait à ma VM ; j'ai expliqué ici les raisons et le réglage de manière accessible : Temps d'utilisation du processeur. En combinant ces trois signaux, on reconnaît à temps les goulots d'étranglement et on évite que les problèmes de latence ne se propagent jusqu'à l'application.

Exemple réel : Quand 5:1 fait exploser la limite

Cabinet médical bat la théorie dès que les charges de travail réelles se mélangent : Un hôte avec 4 cœurs physiques et 5 VMs à 4 vCPUs ne semble pas problématique à vide, mais montre des temps d'attente massifs sous charge. Si une VM démarre un traitement d'image ou des sauvegardes, l'ordonnanceur donne certes la priorité, mais les autres VM accumulent des valeurs CPU-Ready de plus de 2000 ms, ce qui représente environ 10% de perte de performance par cœur [3]. Lors d'un test documenté du serveur SQL, le débit a chuté de 25 200 transactions par minute à moins de la moitié lorsque le fonctionnement en arrière-plan est activé [3]. Les E/S sont également indirectement ralenties, car les vCPU sont préemptés pendant les accès aux périphériques en bloc et les pipelines se bloquent. J'assiste alors à un mélange de pics élevés, de longs tails et de gigue inattendue dans les temps de réponse.

Risques particuliers chez les hôtes SMP

SMP-VMs avec de nombreux vCPUs nécessitent des slots coordonnés sur plusieurs cœurs physiques, ce qui augmente les efforts d'ordonnancement et les temps d'attente. Plus une seule VM possède de vCPU, plus elle attend souvent que toutes les tranches horaires nécessaires soient réunies. Red Hat conseille donc de privilégier plusieurs petites VM avec peu de vCPU plutôt que de conduire des hôtes individuels „à voie large“ [1]. Un ratio d'overcommit de 10:1 est considéré comme une valeur maximale approximative ; j'estime qu'il est nettement moins judicieux dans les environnements de production, en particulier pour les services à forte charge permanente [1]. Ceux qui font de la latence leur priorité absolue limitent les vCPU par VM et optimisent les threads de manière à ce qu'ils puissent se contenter d'une charge de base moins importante.

Pratique de l'hébergement web : impact sur les sites web

Sites web sur des hébergeurs surbookés réagissent avec des temps de chargement plus longs, un temps au premier octet instable et de mauvaises vitales web de base. Les moteurs de recherche déclassent les pages lentes, les visiteurs rebondissent plus rapidement et les chaînes de conversion se brisent sur des microdélais peu visibles [2]. Dans les environnements partagés, beaucoup connaissent le „voisin bruyant“ ; sur les VPS avec overcommitment, cela se produit de manière plus subtile, car davantage de vCPU sont nominalement attribués. C'est pourquoi, en cas de pics de trafic, je commence toujours par vérifier si les valeurs Ready et Steal augmentent au lieu de bricoler à l'aveuglette sur le serveur web. Celui qui veut réduire les coûts devrait prendre en compte les risques de un hébergement web avantageux et exiger des limites claires contre le surbooking [2].

Overcommitment vs. bare metal

Comparaison montre que : Le bare metal fournit des latences planifiables et un débit linéaire, tandis que la virtualisation surbookée s'agite sous la charge. Pour les charges de travail sensibles à la latence comme les bases de données, les files d'attente, les piles d'observabilité et les API en temps réel, la dédicace est rapidement payante. Je préfère les cœurs dédiés ou le bare metal dès que le CPU Ready se fait remarquer ou que les invités SMP s'enlisent. Ceux qui ont besoin de flexibilité peuvent construire un pont avec des instances de CPU réservées ou des groupes d'hôtes sans overcommit. Le comparatif offre un aperçu structuré des options Hébergement en métal nu, Le rapport de la Commission européenne sur l'avenir de l'Union européenne, qui compare de manière succincte les points forts et les compromis, est un document important.

Dimensionnement des droits : combien de vCPU sont utiles ?

Rightsizing commence par la demande réelle : Je mesure le CPU, la file d'attente d'exécution, les IO disque et Net ainsi que les modèles de lock-wait sur plusieurs profils journaliers. Si les valeurs mesurées indiquent un pool de threads de pointe de quatre, j'attribue au début deux à quatre vCPU et je n'augmente le nombre que si Ready et Co-Stop restent discrets. La règle générale „10 vCPU maximum par cœur physique“ est un plafond, pas une valeur cible ; en production, je planifie de manière plus conservatrice [1]. Les grandes VM avec de nombreux vCPU semblent attrayantes, mais elles augmentent les efforts de coordination et les fluctuations de latence. Je fais évoluer horizontalement des petites VM bien découpées, ce qui permet de maintenir des files d'attente courtes et efficaces.

Surveillance et alertes : ce que je règle

Suivi rend l'overcommitment visible avant que les utilisateurs ne le remarquent, c'est pourquoi je fixe des limites claires. Le CPU Ready en moyenne d'une minute doit idéalement rester en dessous de 5% par vCPU, le Co-Stop doit tendre durablement vers zéro et le Steal Time ne doit être perceptible que brièvement [3]. En cas de dépassement, je redimensionne horizontalement, je parque les tâches de fond à l'écart des VM productives ou je déplace les invités sur des hôtes avec de l'air. Je sépare les alertes en fonction de leur gravité : Alerte immédiate pour les fortes augmentations, ticket pour les augmentations modérées récurrentes. J'évite ainsi la lassitude des alertes et j'interviens de manière ciblée lorsque la latence devient vraiment critique pour l'entreprise.

Choisir un fournisseur d'accès : Ce à quoi je fais attention

Sélection d'un fournisseur de VPS est décisif pour la constance sous charge, c'est pourquoi je vérifie de manière critique les offres en matière de surréservation. Des indications transparentes sur les rapports vCPU/core, des engagements clairs sur les cœurs dédiés et des benchmarks cohérents sont obligatoires. Dans une comparaison 2025, les offres avec stockage NVMe, CPU de génération moderne et sans surréservation de CPU ont obtenu les meilleurs résultats, avec un uptime stable et une latence régulière [6]. Le prix seul conduit souvent à une survente cachée, ce qui, dans des scénarios productifs, revient plus cher que des ressources honnêtes. Le tableau suivant montre des paramètres clés que je mets côte à côte pour éviter les goulots d'étranglement.

Fournisseur	vCPU	RAM	Mémoire	Temps de fonctionnement	Prix/mois	Vainqueur du test
webhoster.de	4-32	8-128 GO	NVMe	99,99%	à partir de 1 €.	Oui
Hetzner	2-16	4-64 GO	SSD	99,9%	à partir de 3 €.	Non
Contabo	4-24	8-96 GO	SSD	99,8%	à partir de 5 €.	Non

Planification des capacités : dès que les pics de charge menacent

Planification je commence par les profils de charge de travail : Heures de pointe, durée des rafales, parallélisme et budgets de latence. En cas d'augmentation de la charge de base, j'augmente d'abord verticalement tant que le temps de disponibilité reste stable ; si la courbe s'incline, je divise les services en plusieurs VM plus petites. Je sépare systématiquement les tâches d'arrière-plan du front-end, afin que les processus de commande ou de passage en caisse ne soient pas en concurrence avec les rapports. L'auto-scaling aide, mais sans limites supérieures et métriques claires, il produit des erreurs de commutation coûteuses. Une logique par étapes est plus efficace : définir des seuils, tester des mesures, mesurer les résultats et ajuster ensuite les seuils avec précision.

Ce qu'est vraiment un vCPU : SMT et effets de fréquence

vCPU signifie généralement un thread matériel (SMT/hyper-threading), pas nécessairement un noyau physique complet. Deux vCPU peuvent se trouver sur un même noyau et se partager les décodeurs, les caches et les unités d'exécution. Sous une charge d'entiers ou de mémoire pure, SMT apporte des avantages sensibles, mais avec des pipelines saturés, les threads se font directement concurrence pour les ressources. Cela explique pourquoi les hôtes avec „beaucoup de vCPU“ ne s'adaptent pas de manière linéaire sous la charge : L'ordonnanceur peut certes distribuer des slots, mais ne peut pas créer davantage d'unités de calcul physiques. De plus, les politiques de puissance et de turbo ont un impact. Lorsque de nombreux threads fonctionnent en parallèle, les fréquences turbo diminuent et les performances des threads individuels baissent. Pour les classes de latence, j'envisage donc des cœurs dédiés, le SMT-Off ou le CPU pinning pour que les threads aient des fenêtres de performance prévisibles.

Conscience NUMA : la localisation de la mémoire est déterminante

NUMA sépare les hôtes modernes à sockets multiples en nœuds avec leur propre connexion mémoire. Les grosses VM SMP qui s'étendent sur plusieurs nœuds NUMA paient avec une latence de mémoire plus élevée, des accès à distance et une coordination supplémentaire. J'aligne l'allocation vCPU et RAM de manière à ce qu'une VM tienne de préférence dans un nœud. En pratique, cela signifie : moins de vCPU par VM, mais une mise à l'échelle horizontale. Dans l'invité, j'évite les pools de threads surdimensionnés et globalement synchronisés et je mise sur le sharding par instance. Celui qui virtualise des bases de données en profite doublement : meilleur taux d'utilisation du cache et moins de trafic cross-node. Le mauvais placement NUMA se camoufle souvent en „problèmes de CPU“, mais il est visible par l'augmentation de la latence de la mémoire et des erreurs de lecture, alors que CPU Ready n'a qu'un effet modéré.

Modèles de burst et de crédit : limites cachées

Instances de burst avec des crédits CPU fournissent de bonnes valeurs au ralenti, mais ralentissent lorsque les crédits sont vides, bien que CPU Ready reste discret. Pour les opérateurs, c'est pernicieux, car des pics de latence apparaissent „à partir de rien“. Je vérifie donc si un tarif utilise des crédits ou des règles de „fair share“ et si une performance minimale est garantie. Les charges de travail avec des pics périodiques (Cron, ETL, batch de facturation) mangent rapidement les crédits et tombent ensuite dans un frein dur. La solution : soit passer à des cœurs réservés, soit découpler les bursts - par exemple en créant un profil de batch séparé avec sa propre plage horaire, afin que les API productives ne soient pas prises dans le frein. L'overcommitment plus le credit throttle est la combinaison la moins favorable pour des temps de réaction prévisibles.

Conteneurs sur le VPS : éviter le double scheduling

Orchestration de conteneurs dans une VM déjà surbookée conduit facilement à un „double surcommit“. L'ordonnanceur hôte donne la priorité aux VM, l'ordonnanceur invité aux conteneurs - tous deux sans connaître la disponibilité réelle du cœur. C'est pourquoi je fixe des quotas de CPU clairs et utilise des cpuset, Je peux ainsi lier des conteneurs critiques à des vCPU spécifiques. En même temps, je maintiens la somme des threads des conteneurs en dessous du budget réaliste disponible de la VM, et non en dessous de la valeur nominale du vCPU. Pour les conteneurs de construction ou de traitement par lots, je définis des partages inférieurs afin de donner la priorité aux services frontaux. Important : irqbalance et la pile réseau ne doivent pas écraser les vCPU critiques avec des flots d'interruptions ; dans le doute, j'isole un ou deux vCPU pour les interruptions réseau et stockage afin d'atténuer les pics de latence.

Pratique de mesure : comment lire les bons chiffres

Dans l'hyperviseur je vérifie le CPU Ready (total et par vCPU), le co-stop et la longueur de la file d'attente d'exécution par hôte. Sur KVM, je corrige les domstats des VM avec le chargement des hôtes et la charge des IRQ. Dans l'hôte j'observe %steal, %iowait, Run-Queue (r) et le changement de contexte. Un schéma récurrent est le suivant : file d'attente d'exécution élevée + %steal en hausse + latence fluctuante = overcommitment. Si le %steal reste bas, mais que les L3-Misses et les Syscalls augmentent, j'indique plutôt des problèmes de lock-contention ou de NUMA. Je compte également les threads de requêtes actifs et les compare au nombre de vCPU : si les pools Web ou Worker dépassent en permanence le budget de base, je crée moi-même des files d'attente. Il est préférable de limiter et de refuser les files d'attente d'entrée plutôt que de les traiter avec retard - cela améliore la perception des utilisateurs et stabilise les systèmes.

Leviers concrets de tuning chez l'hôte et l'invité

Gains rapides je l'obtiens en quelques étapes précises : Dans le BIOS, je mise sur les profils de performance, je désactive les C-States profonds et je maintiens une mise à l'échelle cohérente des fréquences. Sur l'hôte, je règle le gouverneur de CPU sur „performance“ et je réduis les bruits parasites des services d'arrière-plan. Dans la VM, j'abaisse les vCPU à la valeur réellement nécessaire, j'épingle les processus critiques (par ex. les threads IO de la base de données) à des vCPU fixes et je limite les pools de threads de l'application. Pour les serveurs web et les runtimes worker_processes (Nginx), pm.max_children (PHP-FPM) ou les pools d'exécuteurs JVM ne dépassent pas le budget total disponible, moins les frais généraux du système. Les grandes pages et les sources de temporisateurs cohérentes réduisent le surcoût d'ordonnancement ; en même temps, j'évite de surcharger agressivement la RAM afin de ne pas ajouter de latence d'échange dans le pipeline.

Design d'application : Backpressure au lieu d'encombrement

Pression de retour est la réponse propre à la pénurie de noyaux. Au lieu de mettre en mémoire tampon des flots de requêtes dans d'énormes files d'attente, je limite les requêtes traitées en parallèle aux cœurs plus la réserve. Les services signalent „busy“ lors des pics d'utilisation ou fournissent des réponses dégradées mais rapides (par ex. des caches plus courts, moins de détails). Les bases de données reçoivent des lock-timeouts plus courts et des transactions plus légères ; les requêtes de recherche et d'analyse sont décalées dans le temps. Dans les paysages de microservices, je freine sur le bord, pas en profondeur : les passerelles API et les limites Ingress empêchent l'effondrement des dépendances internes. Il en résulte des files d'attente ordonnées avec des queues courtes - exactement ce qui sauve l'expérience utilisateur en cas d'overcommitment.

Migration en direct et charge de travail en arrière-plan : les pierres d'achoppement cachées

vMotion/migration en direct ou les fenêtres de maintenance de l'hôte provoquent des latences accrues à court terme, même si l'overcommitment est modéré. Pendant que la mémoire est copiée et que les états du processeur sont synchronisés, les tranches de temps et les chemins d'E/S se décalent. Si l'événement coïncide avec des fenêtres de traitement par lots, les retards s'accumulent. Je planifie des fenêtres de migration en dehors des heures de pointe et je parque les tâches exécutées en parallèle. De même, je sépare strictement la sauvegarde/l'antivirus/l'indexation des chemins de latence - idéalement sur mes propres VM à faible priorité. J'évite ainsi que des opérations de maintenance „bien intentionnées“ ne faussent les mesures de performance ou ne touchent des flux d'utilisateurs.

Liste de contrôle : Un diagnostic clair en 15 minutes

• Sélectionner la période, reproduire la charge (test de charge ou fenêtre de pic).
• Hyperviseur : CPU Ready par vCPU, Co-Stop, vérifier la file d'attente d'exécution de l'hôte.
• Invité : %steal, %iowait, file d'attente d'exécution, changement de contexte, mesure de la charge IRQ.
• Faire correspondre les pools de threads et de travailleurs de l'application avec le nombre de vCPU.
• Identifier et déplacer les jobs d'arrière-plan et les exécutions Cron.
• Test : diviser le nombre de vCPU par deux ou l'épingler, mesurer à nouveau Ready/Steal.
• Lorsque les valeurs baissent et que la latence se lisse : Fractionner horizontalement, fixer les limites.
• Si aucune amélioration : changer d'hôte/plan, vérifier les noyaux dédiés.

10 hypothèses erronées typiques qui coûtent de la performance

Erreurs je vois régulièrement : plus de vCPU ne signifie pas automatiquement plus de vitesse si l'hôte est déjà étroitement cadencé. Une valeur élevée de CPU dans la VM n'occupe pas la totalité des cœurs tant que Ready est élevé et que Steal augmente. Les grandes VM SMP ne fournissent pas nécessairement un meilleur parallélisme si la synchronisation et les verrous dominent. Les fonctions de priorisation de l'hyperviseur ne suppriment pas les limites physiques ; elles ne font que déplacer les retards. Et le réglage de la base de données ou de PHP ne dissimule que brièvement les goulots d'étranglement si l'ordonnanceur reste le véritable goulet d'étranglement.

Étapes concrètes : des symptômes à la cause

Procédure je démarre de manière reproductible : je définis d'abord un scénario de charge, puis j'enregistre les temps d'attente CPU Ready, Co-Stop, Steal et IO dans la même fenêtre temporelle. Si les métriques montrent des signatures typiques d'overcommit, je réduis le nombre de vCPU par VM, je répartis les charges de travail SMP et je déplace les processus d'arrière-plan. Si les valeurs restent élevées, je déplace la VM sur un hôte avec un faible ratio ou des cœurs réservés. Si la latence ne change qu'à ce moment-là, je sauvegarde le nouveau profil en tant que base de référence et j'ancre des alarmes sur des valeurs en pourcentage et en millisecondes. De cette manière, je ne résous pas les symptômes, mais je m'adresse à la cause dans l'ordonnancement.

En bref

RésuméCPU Overcommitment : cela semble efficace, mais cela génère des files d'attente sous charge qui ralentissent les serveurs virtuels. Des mesures telles que le CPU Ready Time, le Co-Stop et le Steal Time indiquent clairement le problème et fournissent des seuils objectifs. Red Hat recommande des ratios conservateurs et des VM plus petites avec peu de vCPU, tandis que des données pratiques provenant d'environnements VMware prouvent l'influence sur le débit et les temps de réponse [1][3]. Pour les sites web et les API, des pertes de classement, des sauts et des processus sujets aux erreurs menacent lorsque la latence varie [2]. Je mise donc sur le rightsizing, un monitoring propre, des seuils clairs et - si nécessaire - des cœurs dédiés ou du bare metal pour maintenir des performances VPS fiables.