Comment définir le ratio de surallocation CPU de Proxmox en 2026 ?

Le 21 mai 2026, Proxmox a publié Proxmox VE 9.2, sans définir pour autant de ratio universel de surallocation CPU (annonce officielle. La règle opérationnelle est donc simple : attribuez les vCPU en fonction des charges simultanées, puis ajustez après observation des pics et des signes d’attente. Si la contention persiste, réduisez les quotas inutiles ou réorganisez les charges avant d’évaluer un serveur plus puissant.

Repère temporel : Proxmox VE 9.2 est le jalon de version cité ici, pas une garantie de capacité. Action à mener cette semaine : relevez les périodes de pointe de l’hôte et des VM, puis comparez ces observations aux vCPU attribués avant de modifier les quotas.

Cet article s’adresse aux administrateurs Proxmox qui préparent de nouvelles VM sans vouloir recopier un ratio trouvé en ligne.
Il concerne aussi les MSP et les petites équipes qui gèrent plusieurs clients, ainsi que les services informatiques qui doivent distinguer une capacité mal répartie d’un hôte réellement saturé.

Le ratio de surallocation CPU de Proxmox est un indicateur, pas une promesse

La somme des vCPU affectés aux VM peut dépasser le nombre de threads logiques du processeur hôte. Cette situation est possible parce que des VM peuvent être inactives, en attente d’E/S ou occupées par des tâches qui ne sollicitent pas continuellement le processeur. Elle ne signifie pas que toutes disposeront en même temps de leur capacité maximale.

Pour une première lecture, calculez :

Ce quotient résume une allocation planifiée. Il ne mesure ni la charge réellement exécutée, ni la qualité de service pendant une pointe. Il faut donc le compléter par deux éléments : le nombre de VM qui travaillent réellement en même temps et la durée de leur activité CPU. Une machine de développement peu sollicitée et un serveur de calcul continu ne doivent pas être planifiés comme s’ils avaient le même profil.

La distinction entre cœurs physiques et threads est également importante. Les threads logiques exposent des contextes d’exécution supplémentaires, mais ils ne constituent pas une promesse équivalente à des cœurs physiques indépendants. Consignez les deux valeurs et évitez de présenter un ratio calculé à partir des threads comme une mesure universelle de capacité. Les discussions communautaires sur la surallocation vCPU et les charges CPU constamment élevées illustrent des expériences d’exploitation ; elles ne définissent pas une recommandation officielle.

Comparez les profils de charge avant de dimensionner

La moyenne CPU masque souvent le problème qui compte : les VM prioritaires se gênent-elles pendant la même période ? Une tâche de compilation, des tests automatisés ou un traitement de données peuvent concentrer leur demande sur une courte fenêtre. Des services internes peu actifs en journée peuvent, eux, avoir des pointes au moment des traitements planifiés. Pour les workloads audio ou vidéo, les étapes de rendu ou d’encodage peuvent également produire des phases très différentes du reste de l’activité.

Cette grille ne donne volontairement pas de seuil chiffré : aucun nombre de VM ni ratio unique ne permet de promettre un résultat indépendant du processeur, des tâches et du niveau de service attendu. Elle sert à choisir quoi observer avant d’accorder davantage de vCPU. Pour une activité multi-tenant, la décision doit aussi tenir compte des pics simultanés, pas seulement du nombre d’invités installés.

Les réglages Proxmox ne jouent pas tous le même rôle

Le nombre de vCPU exposés à une VM, sa limite CPU et son poids dans l’arbitrage sont des paramètres distincts. Une allocation plus élevée ne rend pas automatiquement un invité plus rapide : elle peut lui permettre de demander davantage de temps CPU, mais l’hôte doit encore pouvoir le planifier.

Dans Proxmox VE, les options de configuration doivent être vérifiées dans le guide d’administration de la branche 9.x. La référence des commandes décrit également les options de gestion des VM, notamment celles qui concernent les cœurs et les limites CPU (documentation de qm). Les noms et le comportement exacts sont à vérifier pour la version installée ; une commande adaptée à une autre version ne doit pas être recopiée sans contrôle.

• Nombre de vCPU : définit la capacité CPU présentée au système invité. Il ne faut pas l’augmenter par réflexe pour corriger une application lente ; celle-ci peut être limitée par le stockage, la mémoire ou son propre fonctionnement.
• Limite CPU : sert à plafonner l’utilisation d’une VM lorsque le partage d’une capacité contrainte l’exige. Une limite trop basse peut pénaliser un service qui doit absorber une pointe.
• Poids ou priorité : aide à arbitrer l’accès au CPU lorsque plusieurs VM sont en concurrence. Il ne crée pas de capacité physique supplémentaire.
• Affinité : contraint l’exécution à certains processeurs logiques. Elle peut répondre à un besoin mesuré, mais l’appliquer sans connaître le placement des charges risque de réduire la souplesse de l’ordonnanceur.

Une grande VM n’est pas toujours préférable à plusieurs VM plus petites. Le résultat dépend du parallélisme de l’application, de ses tâches simultanées et du délai acceptable. Il vaut mieux exposer le nombre de vCPU dont le service a besoin, puis contrôler son comportement, plutôt que de « donner tous les cœurs » à chaque invité.

Première étape : établissez une base de mesure fiable

Avant de changer les allocations, définissez les services prioritaires et leurs périodes de pointe. Notez les heures de début des traitements planifiés, les incidents de lenteur signalés et les VM concernées. Une moyenne journalière ne remplace pas un relevé pris pendant un pic.

Sur l’hôte, relevez la charge CPU et observez son évolution dans le temps. Dans chaque système invité, vérifiez l’utilisation CPU, les processus actifs et, lorsque la mesure est disponible, le temps « steal », qui peut signaler que l’hyperviseur n’a pas fourni immédiatement du temps processeur demandé. Une valeur isolée ne suffit pas : confrontez-la à l’activité réelle et à la latence du service.

Sous Linux, /proc/loadavg rapporte des valeurs de charge qui ne se limitent pas à une mesure directe du temps CPU ; sa documentation explique notamment que la charge inclut des tâches en attente non interruptible (description de /proc/loadavg). Il ne faut donc pas interpréter une hausse de cette valeur seule comme une preuve de surallocation CPU.

Ajustez les ressources avec une procédure réversible

Une démarche de vCPU resource planning doit relier chaque modification à une observation, plutôt qu’à un ratio recopié. Procédez de manière contrôlée :

1. Inventoriez les VM et les conteneurs. Pour chaque charge, indiquez le rôle, la priorité, les périodes d’activité et les traitements qui consomment beaucoup de CPU. Distinguez les services permanents des environnements de test.
2. Relevez la capacité physique de l’hôte. Consignez les cœurs physiques et les threads logiques du processeur. Utilisez ces données pour décrire la capacité disponible, sans assimiler les threads à des cœurs physiques équivalents.
3. Mesurez les pointes représentatives. Examinez l’hôte et les invités au moment où les tâches importantes se chevauchent. Une période calme n’est pas représentative si les lenteurs apparaissent uniquement lors des traitements planifiés.
4. Vérifiez la taille des VM. Si une VM reçoit beaucoup de vCPU mais n’en exploite qu’une partie, réduisez progressivement son allocation, après avoir vérifié les besoins de l’application. Ne réduisez pas une VM critique uniquement parce que l’hôte affiche une charge moyenne basse.
5. Ajustez limites et priorités séparément. Réservez les limites aux situations où un plafonnement est nécessaire et les poids à l’arbitrage entre charges concurrentes. Consultez le guide officiel de la version avant d’appliquer les options.
6. Comparez avant et après. Reprenez les mêmes indicateurs, sur les mêmes types de périodes chargées. Notez l’heure, la modification et les effets sur la latence ou les tâches. Si la situation empire, revenez à la configuration consignée.

Pour les interventions qui touchent à la configuration de l’hôte, gardez une voie de retour vérifiée et ne cumulez pas plusieurs changements sans mesure intermédiaire. Modifier en même temps le nombre de vCPU, les limites et l’affinité rend le résultat difficile à interpréter.

Choisissez la prochaine action selon les signaux observés

La décision peut se prendre avec des conditions explicites plutôt qu’un ratio prétendument standard :

• Si les lenteurs sont brèves et coïncident avec une tâche secondaire, déplacez ou planifiez cette tâche à un autre moment avant d’acheter davantage de capacité.
• Si une VM dispose de vCPU inutilisés et que les autres montrent des signes d’attente, réduisez d’abord l’allocation trop généreuse, puis vérifiez si les VM prioritaires répondent mieux.
• Si les VM critiques manquent de temps CPU pendant les pics malgré une allocation raisonnable, augmentez leur priorité ou réorganisez les charges, puis répétez la mesure.
• Si la contention persiste après ces ajustements, alors que les tâches de calcul restent soutenues, comparez la demande mesurée à la capacité d’un hôte plus grand ou répartissez les charges sur plusieurs machines.
• Si les lenteurs ne coïncident pas avec une attente CPU, recherchez un autre goulot, par exemple le stockage, la mémoire ou le réseau. Changer le CPU sans confirmer le diagnostic peut laisser le problème intact.

Cette logique répond aussi au choix entre réduire les vCPU et changer de serveur : la réduction est appropriée lorsque les quotas sont manifestement disproportionnés ou mal priorisés. L’évolution matérielle devient pertinente lorsque la demande réelle reste supérieure à la capacité disponible après une répartition raisonnable.

Faites correspondre la charge observée à un serveur indépendant

Pour l’independent server virtualization, il faut comparer le besoin réel à une configuration disponible, sans transformer les spécifications en promesse de performances. La page des offres et tarifs NodeKVM indique une configuration AMD EPYC 7543P à 32 cœurs et 64 threads, avec 128 Go ou 256 Go de mémoire ECC. Le stockage comprend deux NVMe de 1 To directement connectés, avec possibilité d’ajouter jusqu’à deux NVMe de 2 To. Le débit proposé est de 250 Mbit/s, 1 Gbit/s ou 2 Gbit/s, sans limite de trafic ; Proxmox VE 8 et 9 figurent dans les systèmes disponibles. Ces caractéristiques décrivent les options, pas les performances d’une charge donnée.

La mémoire, le stockage et le réseau doivent être vérifiés avec le CPU. Une charge qui manque de mémoire ou attend son stockage ne sera pas corrigée par davantage de vCPU. De même, une bande passante supérieure ne résout pas une contention processeur. Avant de retenir une configuration, comparez les pics mesurés, l’espace nécessaire aux VM et aux données, ainsi que le trafic réellement attendu.

FAQ : les décisions qui reviennent souvent

Peut-on attribuer plus de vCPU que l’hôte n’a de threads ?
Oui. La somme des vCPU attribués aux VM peut dépasser le nombre de threads logiques de l’hôte, car tous les invités ne sollicitent pas nécessairement le processeur au même moment. Cette allocation ne garantit toutefois pas que chaque VM disposera simultanément de toute sa capacité. Vérifiez les périodes de pointe et les signes d’attente avant d’augmenter les quotas.

Faut-il calculer la surallocation à partir des cœurs physiques ou des threads ?
Consignez les deux valeurs, mais ne traitez pas un thread logique comme l’équivalent garanti d’un cœur physique. Le nombre de threads aide à décrire la capacité d’exécution exposée par le processeur ; les cœurs physiques restent un repère utile pour planifier les charges soutenues. Le bon dénominateur dépend donc du profil des tâches et des objectifs de service.

Quels signes montrent qu’une VM attend le processeur dans Proxmox ?
Un hôte régulièrement chargé n’est pas une preuve suffisante. Comparez les périodes de pointe côté hôte et côté invités, observez l’évolution de la latence et recherchez des indices d’attente CPU, dont le temps « steal » dans un système invité quand il est disponible. Croisez ces mesures avec les journaux et l’activité réelle des VM avant de conclure.

Quand faut-il réduire les vCPU plutôt que changer de serveur ?
Réduisez d’abord les vCPU inutiles ou modifiez les priorités si les invités sont surdimensionnés et que la contention est limitée à certaines charges. Si les tâches prioritaires restent lentes pendant les pics malgré une allocation raisonnable et une réorganisation des charges, comparez alors la capacité physique requise à celle du serveur envisagé.

Quand la capacité dédiée devient plus adaptée

Une instance partagée peut convenir à une charge légère, temporaire ou facilement redimensionnable. En revanche, selon l’offre, le partage du processeur peut rendre la capacité disponible moins prévisible ; la facturation au trafic ou aux ressources peut aussi compliquer le calcul d’un coût stable, et certains environnements offrent moins de liberté sur le stockage ou le système. Il faut examiner ces limites dans le contrat de service choisi, sans supposer qu’elles sont identiques partout.

Pour des VM exploitées durablement, avec des pointes mesurées et un besoin de contrôle sur la répartition CPU, un serveur physique AMD dédié peut être plus cohérent qu’un hôte partagé. NodeKVM propose notamment les options matérielles décrites plus haut ; il reste nécessaire de confronter les relevés CPU, la mémoire, les disques et le débit aux exigences du service, sans déduire de performances garanties des seules spécifications. Lorsque ces éléments sont rapprochés du plan de charge et que la capacité convient, les options de commande NodeKVM permettent d’examiner la configuration avant toute migration.

Questions

1. Q
   Peut-on attribuer plus de vCPU que le serveur n’a de threads ?

   Oui. La somme des vCPU attribués aux VM peut dépasser le nombre de threads logiques de l’hôte, car tous les invités ne sollicitent pas nécessairement le processeur au même moment. Cette allocation ne garantit toutefois pas que chaque VM disposera simultanément de toute sa capacité. Vérifiez les périodes de pointe et les signes d’attente avant d’augmenter les quotas.

2. Q
   Faut-il calculer la surallocation à partir des cœurs physiques ou des threads ?

   Consignez les deux valeurs, mais ne traitez pas un thread logique comme l’équivalent garanti d’un cœur physique. Le nombre de threads aide à décrire la capacité d’exécution exposée par le processeur ; les cœurs physiques restent un repère utile pour planifier les charges soutenues. Le bon dénominateur dépend donc du profil des tâches et des objectifs de service.

3. Q
   Quels signes montrent qu’une VM attend le processeur dans Proxmox ?

   Un hôte régulièrement chargé n’est pas une preuve suffisante. Comparez les périodes de pointe côté hôte et côté invités, observez l’évolution de la latence et recherchez des indices d’attente CPU, dont le temps « steal » dans un système invité quand il est disponible. Croisez ces mesures avec les journaux et l’activité réelle des VM avant de conclure.

4. Q
   Quand faut-il réduire les vCPU plutôt que changer de serveur ?

   Réduisez d’abord les vCPU inutiles ou modifiez les priorités si les invités sont surdimensionnés et que la contention est limitée à certaines charges. Si les tâches prioritaires restent lentes pendant les pics malgré une allocation raisonnable et une réorganisation des charges, comparez alors la capacité physique requise à celle du serveur envisagé.