Que faire après l’épuisement des crédits CPU d’une machine virtuelle à capacité extensible en 2026 ?

Le site ralentit au moment où le solde de crédits CPU approche de zéro, mais cette coïncidence ne suffit pas à prouver la cause.

Cette analyse s’adresse aux personnes qui exploitent les machines virtuelles et doivent confirmer l’origine d’une dégradation.
Elle concerne aussi les responsables du budget qui comparent le maintien d’une instance à capacité extensible, son redimensionnement et un serveur dédié.
Les équipes applicatives et bases de données y trouveront les vérifications à réaliser avant de modifier leur infrastructure.

Dernière vérification : 2 novembre 2026. Les règles décrites ci-dessous sont vérifiées dans les documentations officielles de chaque plateforme et s’appliquent uniquement aux familles d’instances indiquées par ces documents.

Comprendre le symptôme avant de changer d’instance

Une machine virtuelle à capacité extensible peut fournir temporairement davantage de puissance CPU que son niveau de référence, selon un mécanisme de crédits défini par sa plateforme. Les crédits s’accumulent ou se consomment selon le modèle applicable à la famille et à la taille de l’instance. Ils ne constituent donc pas une réserve identique d’un fournisseur à l’autre.

Dans le modèle documenté pour la série B, le solde de crédits, leur accumulation et leur consommation déterminent la capacité à maintenir une activité CPU supérieure au niveau de référence. Lorsque le solde ne permet plus ce dépassement, le comportement dépend de la règle propre à l’instance ; il ne faut pas extrapoler le fonctionnement d’une série à toutes les machines virtuelles. La documentation officielle du modèle de crédits de la série B détaille ce mécanisme pour les instances concernées.

Un autre modèle de crédits distingue les modes d’utilisation de l’instance. En mode standard, les règles après épuisement ne sont pas les mêmes qu’en mode sans plafond, où des crédits excédentaires peuvent entraîner une facturation selon les conditions applicables. Consultez les principes officiels des crédits CPU des instances extensibles, puis les règles du mode standard ou du mode sans plafond et ses exemples de calcul selon la configuration réellement utilisée.

Il faut donc séparer trois observations : un solde qui diminue, une consommation CPU élevée et une dégradation visible pour l’application. Un seul de ces éléments ne suffit pas à conclure que la machine est limitée par ses crédits. Une hausse de la latence, une file de travaux qui s’allonge ou des requêtes de base de données plus lentes doivent apparaître au même moment pour renforcer le diagnostic.

Que se passe-t-il lorsque les crédits CPU sont épuisés ? La réponse dépend du modèle d’instance. Une plateforme peut ramener les performances vers le niveau de référence, tandis qu’une configuration distincte peut autoriser une consommation excédentaire payante. Il faut vérifier la documentation de la famille et du mode actifs avant d’interpréter une baisse de débit comme un comportement universel.

Relever les métriques et les relier aux symptômes

Le nom « CPU Credit Remaining » peut être utilisé dans une recherche ou une interface, mais il ne désigne pas nécessairement une métrique universelle. Pour une instance concernée, recherchez le nom exact des indicateurs dans la console et la documentation de la plateforme. Certaines interfaces exposent notamment un solde de crédits et une mesure de crédits consommés ; d’autres présentent des noms ou des définitions différents.

Les métriques de surveillance d’une machine virtuelle peuvent aussi varier selon la série. La référence officielle des métriques de surveillance des machines virtuelles et la liste officielle des métriques disponibles permettent de contrôler les définitions applicables. Pour les instances qui exposent des crédits dans l’autre modèle, consultez les indicateurs CPU documentés et leur consultation.

Procédez dans cet ordre :

• [ ] Identifiez la famille, la taille, le mode de fonctionnement et la politique de crédits de l’instance.
• [ ] Relevez le solde de crédits et la consommation CPU sur une même période que les lenteurs signalées.
• [ ] Ajoutez l’utilisation CPU, la latence applicative, la longueur des files de travaux et les requêtes lentes de la base de données.
• [ ] Notez les déploiements, sauvegardes, tâches planifiées et changements de trafic qui coïncident avec les variations.
• [ ] Vérifiez si les valeurs proviennent de métriques natives, d’un agent installé dans le système ou d’un agrégat calculé par votre outil.
• [ ] Conservez les courbes et journaux avant toute modification, afin de pouvoir comparer l’état initial et le résultat.

Une lecture ponctuelle risque de masquer le problème. Il est plus utile de comparer une période sans incident à une période où les utilisateurs constatent une dégradation, en gardant les mêmes définitions et la même granularité de collecte. Les seuils d’alerte doivent être adaptés à la charge et aux objectifs du service ; aucun seuil générique ne permet de diagnostiquer toutes les familles d’instances.

Comment vérifier le solde et la vitesse de consommation ? Repérez d’abord l’indicateur de solde propre à l’instance, puis comparez son évolution à la mesure de consommation, si elle est disponible. Une diminution continue pendant une période de charge soutenue montre que l’instance dépense ses crédits plus vite qu’elle ne les reconstitue ; elle ne prouve pas, à elle seule, que cette consommation cause la lenteur. Il faut la rapprocher des symptômes applicatifs et des règles de l’instance.

Écarter les autres causes de ralentissement

Une baisse de crédits peut accompagner une période chargée sans en être l’unique cause. Avant de modifier la capacité CPU, vérifiez les changements de trafic, le nombre de requêtes concurrentes et les traitements qui se déclenchent à heure fixe. Un import, une génération de rapports, une tâche de maintenance ou une mise à jour peut augmenter l’activité sans que la charge habituelle du service ait changé.

Examinez ensuite les ressources et l’application :

• CPU : vérifiez si l’usage reste élevé, s’il concerne un processus précis et s’il correspond aux requêtes lentes.
• Mémoire : repérez les signes de pression mémoire, les arrêts de processus et les échanges avec le stockage.
• Disque : contrôlez les temps d’attente et les opérations d’entrée-sortie, en particulier pendant les traitements de base de données.
• Réseau : comparez le volume, les erreurs et les délais réseau avec les heures de dégradation.
• Application : recherchez les changements de version, les erreurs, les verrous, les appels externes lents et les files qui s’accumulent.

Ne confondez pas l’épuisement des crédits avec le « CPU steal ». Ce dernier concerne le temps pendant lequel une machine virtuelle attend que l’hyperviseur lui attribue du temps processeur ; les crédits, eux, relèvent du mécanisme de capacité extensible de certaines familles. Les deux sujets peuvent affecter les performances, mais ils ne se diagnostiquent pas avec le même indicateur. De même, une attente disque ou un manque de mémoire ne disparaît pas en augmentant la capacité CPU.

La procédure officielle de diagnostic d’une utilisation CPU élevée fournit des vérifications complémentaires pour le système concerné. Elle ne remplace pas l’analyse des crédits : les deux examens répondent à des questions différentes.

Une baisse continue des crédits impose-t-elle de changer de taille ? Pas nécessairement. Si elle apparaît pendant une charge brève et prévue, que l’application reste dans ses objectifs et que le solde se reconstitue ensuite, le modèle peut rester adapté. Si la charge dépasse souvent le niveau de référence et que les dégradations coïncident avec l’épuisement, comparez le coût d’une taille supérieure ou d’une instance à performances constantes avant de retenir une migration.

Définir la réponse selon la charge et les contraintes

Le choix dépend moins du seul solde que de la forme de la charge : pics courts ou activité soutenue, variations prévisibles ou imprévues, besoin d’élasticité, dépendances aux services gérés et capacité de l’équipe à exploiter une machine. Pour une plateforme qui autorise une facturation des crédits excédentaires, vérifiez aussi le mode activé et la ligne correspondante dans la facture ; ne supposez pas que l’épuisement entraîne automatiquement une facturation supplémentaire.

Appliquez les conditions suivantes :

• Si les pics sont courts, rares et suivis d’une baisse de charge, conservez l’instance après avoir confirmé que les indicateurs métier restent acceptables. Ajustez les alertes et réévaluez le profil de charge.
• Si la charge dépasse souvent le niveau de référence, mais que l’élasticité reste utile, comparez une taille supérieure ou une instance à performances constantes dans le même environnement. Vérifiez les coûts avec la même région, le même mode de facturation et les mêmes options.
• Si l’activité est stable, prévisible et exige une puissance soutenue, évaluez une capacité dédiée ou une location de serveur dédié, à condition que l’équipe puisse assumer l’exploitation et la reprise.
• Si la demande change fortement, doit s’étendre à plusieurs zones ou dépend étroitement de services gérés, gardez ces besoins dans l’analyse ; un serveur dédié n’est pas un remplacement automatique de l’élasticité ou de ces services.
• Si les métriques restent contradictoires, ne migrez pas sur la base d’une impression : poursuivez l’observation et testez l’hypothèse sur un environnement représentatif.

Une machine extensible convient-elle à un site ou à une base de données qui tourne en continu ? Elle peut convenir si le profil réel alterne activité et périodes plus calmes, et si la consommation de crédits ne provoque pas de limitation gênante. Si le service utilise constamment une part importante de CPU, le niveau de référence et le coût des dépassements éventuels deviennent des critères centraux ; il faut alors comparer une capacité constante et un serveur dédié avec des données de charge, plutôt que se fier au seul nombre de vCPU affiché.

Valider le changement avant de l’étendre

Une migration ou un redimensionnement ne doit pas être validé uniquement parce que le solde de crédits ne baisse plus. Définissez des critères observables avant le test : délais de réponse, taux d’erreur, durée des requêtes importantes, longueur des files, stabilité pendant les tâches planifiées et coût sur le cycle de facturation retenu.

Pour tester sans transformer une hypothèse en incident :

• Reproduisez une charge représentative dans un environnement de test, ou préparez une modification réversible selon les procédures de l’équipe.
• Gardez la même version de l’application, les mêmes données représentatives et les mêmes tâches planifiées lorsque cela est possible.
• Collectez les métriques système, les indicateurs de la plateforme et les mesures métier pendant des périodes comparables.
• Documentez les dépendances, les accès, la supervision et les procédures de restauration avant de déplacer une base de données ou un service critique.
• Fixez les conditions de retour à l’état précédent avant le changement, et vérifiez que la restauration a été répétée ou au moins préparée de manière opérationnelle.

Le bilan doit distinguer la performance, la stabilité, le coût et le travail d’exploitation. Une amélioration sur un indicateur ne suffit pas si elle transfère une charge de maintenance non maîtrisée à l’équipe. Pour préparer la partie matérielle de cette comparaison, le guide d’estimation de configuration d’un serveur peut servir à structurer les besoins en calcul, mémoire, stockage et réseau ; les ressources effectivement disponibles et leur tarif doivent ensuite être vérifiés dans les informations du site.

Comparer les options et consigner les preuves

Le tableau de suivi ci-dessous est à remplir avec les mesures de l’environnement concerné. Il sert à relier les crédits, la charge et l’expérience utilisateur ; il ne fixe pas de seuil arbitraire.

Le tableau de comparaison des solutions doit reprendre la facture réelle et les prix officiels de la région concernée, consultés à la date du calcul. Pour un serveur dédié, remplacez les champs de coût par les tarifs réellement proposés et disponibles ; n’ajoutez pas d’estimation non vérifiée.

Les comparaisons doivent inclure les coûts souvent oubliés : stockage, adresses réseau, transferts sortants, sauvegardes, supervision, temps d’administration et procédure de reprise. Une instance au prix affiché inférieur peut devenir plus coûteuse une fois ces postes et les éventuels frais de dépassement ajoutés. À l’inverse, une machine dédiée n’est pas automatiquement moins chère : le calcul dépend du tarif du site, de l’utilisation réelle et du niveau de responsabilité accepté.

Préparer la migration et la reprise

La puissance CPU ne représente qu’une partie de la capacité nécessaire. Avant de transférer un site, une API ou une base de données, établissez un inventaire des dépendances : services managés, files, stockage objet, résolution de noms, certificats, règles réseau et mécanismes de déploiement. Vérifiez que les données tiennent dans la mémoire et le stockage réellement prévus, et que les besoins réseau sont compatibles avec l’offre étudiée.

Il faut aussi décider qui est responsable de chaque étape : surveillance du matériel, mises à jour du système, sécurité, sauvegarde, restauration, remplacement de configuration et diagnostic. Un serveur physique dédié apporte des ressources dédiées ; il ne fournit pas à lui seul une haute disponibilité, une copie de sauvegarde hors machine ni une prestation d’administration. Les modalités de sauvegarde et de restauration doivent être conçues et testées séparément. Le guide de gestion et de protection des données aide à préparer cette responsabilité avant de déplacer des données.

Une architecture fortement élastique, répartie sur plusieurs régions ou dépendante de services gérés peut justifier de conserver une partie des charges dans le cloud. Il en va de même lorsque l’équipe ne dispose pas des compétences ou du temps nécessaires pour exploiter une machine et organiser sa reprise. Le bon résultat peut être une migration partielle, ou l’absence de migration, plutôt qu’un remplacement intégral.

Choisir à partir des preuves, pas du seul solde

L’épuisement des crédits CPU est une piste utile si la documentation de l’instance, les métriques et les symptômes métier concordent. Si la charge est principalement ponctuelle, l’instance extensible peut rester pertinente ; si elle dépasse durablement son niveau de référence, comparez le redimensionnement, les performances constantes et la location de serveur dédié avec les factures et les responsabilités réelles.

Les machines virtuelles partagées peuvent exposer une charge soutenue à un niveau de référence inadéquat, à des règles de dépassement ou à des coûts difficiles à anticiper ; un changement d’instance n’efface cependant ni les dépendances aux services gérés ni le besoin de sauvegardes. Pour une charge stable et une équipe capable d’assumer l’exploitation, les ressources dédiées de XFP Cloud peuvent mériter une évaluation face à ces contraintes, sans présumer d’une économie ou d’une amélioration avant vérification.

La prochaine étape consiste à confronter les besoins mesurés à une configuration et à un plan de reprise adaptés. Si les preuves confirment qu’une infrastructure dédiée est à étudier, utilisez le guide de configuration des serveurs de XFP Cloud pour organiser cette évaluation, puis vérifiez les caractéristiques et les montants dans les informations produit applicables.