Il est 10h17. Quelqu’un écrit sur Slack « Le CPU est bloqué à 95% sur le serveur de fichiers. » Aucune autre information. Aucune mise en production récente (dit-on). Les utilisateurs disent « tout est lent », ce qui est la métrique la moins actionnable jamais inventée.
Si vous êtes confronté à un « CPU élevé » sous Windows sans indice, vous n’avez pas besoin d’un millier de réglages. Vous avez besoin d’un triage discipliné qui vous indique quel type de problème CPU vous avez en quelques minutes, et quoi faire ensuite sans transformer la machine en foire scientifique.
Ce que « CPU élevé » signifie réellement (et ce que ça ne signifie pas)
« Le CPU est élevé » n’est pas un diagnostic. C’est un symptôme qui peut correspondre à au moins quatre classes de problèmes :
- Saturation de calcul réelle : un ou plusieurs processus effectuent un travail légitime (ou illégitime, comme du spin). Vous verrez un temps CPU élevé au niveau du processus.
- Surcharge noyau/pilotes : le CPU est occupé, mais pas « dans un processus » comme vous l’attendez — tempêtes d’interruptions, temps DPC élevé, pilotes filtres, pilotes stockage/réseau, hooks antivirus.
- Contention ordonnanceur/virtualisation : l’OS veut du CPU mais n’arrive pas à l’obtenir de manière fiable (ready time, surallocation, contention sur l’hôte). À l’intérieur de la VM, cela ressemble à « CPU élevé » ou « lenteur sans raison ».
- Confusion de mesure : vous regardez le mauvais compteur, ou le bon compteur avec de mauvaises attentes (arithmétique multicœur, processus « System », « Idle », ou outils qui échantillonnent trop lentement).
L’objectif du triage est simple : classer dans quelle catégorie vous êtes, puis approfondir. Ne commencez pas par réinstaller « la chose », désactiver la sécurité ou changer le plan d’alimentation parce qu’un blog vous l’a conseillé. Vous pouvez causer de vrais dégâts rapidement, et vous n’aurez toujours aucune idée de ce qui s’est passé.
Règle de production : vous ne « réparez » pas le CPU élevé. Vous identifiez le goulot, puis vous décidez d’atténuer, de revenir en arrière, ou de chercher la cause racine avec une trace.
Plan de diagnostic rapide : vérifications première/seconde/troisième
Voici la séquence que j’utilise sur des systèmes en production, car elle évite les deux pertes de temps classiques : fixer les graphiques du Gestionnaire des tâches et discuter des « changements récents ».
Première étape : Est-ce un processus, le noyau, ou « pas vraiment du CPU » ?
- Vérifier le CPU total + principaux consommateurs : si un processus domine, vous êtes en zone calcul/processus.
- Vérifier le temps noyau et les interruptions/DPC : si « System » est élevé ou si aucun processus n’explique le CPU, suspectez les pilotes/interruptions/hooks de filtre.
- Vérifier la fréquence CPU/le throttling : si tout est « élevé » mais le travail accompli est faible, vous fonctionnez peut‑être à une fraction de la fréquence attendue.
Deuxième étape : La machine progresse-t‑elle réellement ?
- Cherchez les files d’attente : file d’attente CPU, changements de contexte, CPU ready (VM), files d’attente stockage, pertes réseau.
- Corrélez avec la latence : latence disque, latence RPC, temps de requête DB, p95 web. Un CPU élevé est parfois la conséquence, pas la cause.
Troisième étape : Décidez « atténuer maintenant » vs « capturer des preuves »
- Atténuer si les utilisateurs sont affectés : redémarrer un service bloqué, limiter un job, basculer, monter temporairement, bloquer le client bruyant, ou revenir sur le changement.
- Capturer des preuves si possible : trace WPR, compteurs PerfMon, et un dump du processus incriminé.
Une phrase à garder en tête : si vous ne pouvez pas expliquer le CPU avec une liste de processus, c’est généralement les pilotes, la contention de virtualisation, ou le throttling.
Les seuls outils dont vous avez besoin (principalement intégrés)
Windows vous donne beaucoup d’instruments ; le problème est que les gens utilisent le plus bruyant (Gestionnaire des tâches) et ignorent les plus précis.
- Gestionnaire des tâches : identification rapide des gros consommateurs, mais superficiel.
- Moniteur de ressources : meilleure corrélation CPU par processus + disque/réseau.
- PerfMon / typeperf : compteurs faisant autorité que vous pouvez consigner et comparer.
- PowerShell : requêtes rapides et triage reproductible.
- WPR + WPA : quand il faut prouver où va le temps CPU (et il faut le prouver).
- Observateur d’événements : la vérité ennuyeuse sur mises à jour, pilotes et plantages.
Une idée paraphrasée de Gene Kim (auteur opérations/fiabilité) : L’amélioration vient de la visibilité du travail et de sa limitation — sinon vous créez simplement plus de chaos plus vite.
Tâches pratiques : commandes, sorties, décisions (12+)
Tout ce qui suit est conçu pour être exécutable et reproductible. Lancez ces commandes dans un PowerShell élevé quand c’est indiqué. Pour chaque tâche : commande, ce que signifie une sortie typique, et la décision que vous prenez.
Tâche 1 : Confirmer la saturation CPU et identifier les principaux processus (PowerShell)
cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name,Id,CPU,WorkingSet | Format-Table -Auto"
Name Id CPU WorkingSet
---- -- --- ----------
sqlservr 4216 18234.5 12488929280
MsMpEng 1832 2210.9 468135936
w3wp 6120 1402.1 913756160
svchost 1024 812.6 164184064
System 4 700.3 10289152
Ce que cela signifie : La colonne CPU est le cumul de secondes CPU depuis le démarrage du processus, pas l’utilisation instantanée. Mais la liste des principaux indique quand même qui a travaillé.
Décision : Si un processus est clairement dominant et correspond au moment présent, approfondissez ce processus (threads, piles d’appels, journaux applicatifs). Si « System » est en tête, passez aux vérifications interruptions/DPC et pilotes.
Tâche 2 : Échantillonnage CPU instantané (boucle PowerShell)
cr0x@server:~$ powershell -NoProfile -Command "1..5 | % { Get-Counter '\Processor(_Total)\% Processor Time' | Select-Object -ExpandProperty CounterSamples | Select-Object CookedValue; Start-Sleep 1 }"
96.3125
94.875
97.0625
95.53125
96.0
Ce que cela signifie : Le CPU est effectivement bloqué, pas un pic transitoire ou un graphique obsolète.
Décision : Si c’est soutenu, poursuivez. Si c’est en pointes, il vous faudra peut‑être une trace pour attraper le coupable ou vérifier les tâches planifiées/analyses antivirus.
Tâche 3 : Ventiler temps utilisateur vs privilégié (noyau)
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% User Time','\Processor(_Total)\% Privileged Time' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path CookedValue
---- -----------
\\server\processor(_total)\% user time 35.125
\\server\processor(_total)\% privileged time 60.8125
Ce que cela signifie : Un temps privilégié élevé signifie du travail en mode noyau : pilotes, pilotes filtres antivirus, système de fichiers, pile réseau, commutations de contexte importantes.
Décision : Si le temps privilégié domine, ne perdez pas une heure à incriminer un processus applicatif. Passez à « System », interruptions/DPC, et inventaire des pilotes/filtres.
Tâche 4 : Vérifier les interruptions et le temps DPC
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% Interrupt Time','\Processor(_Total)\% DPC Time' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path CookedValue
---- -----------
\\server\processor(_total)\% interrupt time 12.4375
\\server\processor(_total)\% dpc time 18.25
Ce que cela signifie : Des temps d’interruption/DPC à deux chiffres sont un indicateur net pointant vers un pilote, typiquement stockage, réseau ou un pilote filtre.
Décision : Capturez une trace WPR pour échantillonnage CPU et analyse DPC/ISR, puis vérifiez les mises à jour récentes de pilotes et les paramètres NIC/storage.
Tâche 5 : Identifier les threads du processus « System » consommant du CPU (vérification rapide)
cr0x@server:~$ powershell -NoProfile -Command "$p=Get-Process -Id 4; $p.Threads | Sort-Object TotalProcessorTime -Descending | Select-Object -First 10 Id,ThreadState,WaitReason,TotalProcessorTime | Format-Table -Auto"
Id ThreadState WaitReason TotalProcessorTime
-- ----------- ---------- ------------------
3120 Running 00:08:12.5310000
1984 Running 00:05:44.8120000
4028 Running 00:03:19.1090000
Ce que cela signifie : Vous pouvez voir les threads « chauds » mais pas les piles d’appels noyau avec ceci. C’est un indice, pas une preuve.
Décision : Si les threads System sont chauds et que privilégié/interrupt/DPC sont élevés, arrêtez les suppositions : prenez une trace (Tâche 10).
Tâche 6 : Vérifier la fréquence CPU et le throttling (compteurs Perf)
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor Information(_Total)\% Processor Performance','\Processor Information(_Total)\% Processor Utility' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path CookedValue
---- -----------
\\server\processor information(_total)\% processor performance 38.0
\\server\processor information(_total)\% processor utility 96.5
Ce que cela signifie : Utility élevé avec Performance bas peut indiquer que le CPU est occupé mais fonctionne à une fréquence réduite (plan d’alimentation, throttling thermique, politique firmware, gestion puissance de l’hôte).
Décision : Vérifiez le plan d’alimentation, les paramètres du BIOS, les politiques d’hôte de virtualisation et les événements thermiques/refroidissement. N’optimisez pas le code pour un CPU consigné à trotter.
Tâche 7 : Vérifier le plan d’alimentation (et arrêter de laisser ça au hasard)
cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e (Balanced)
Ce que cela signifie : Balanced est souvent acceptable sur du matériel moderne, mais sur certaines charges serveurs cela peut introduire une latence d’augmentation de fréquence et des performances inconsistantes.
Décision : Si vous observez du throttling ou une sensibilité à la latence, envisagez High performance ou le plan recommandé par le fournisseur. Changez de façon délibérée, avec mesure.
Tâche 8 : Vérifier les tâches planifiées hors de contrôle
cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | ? {$_.State -eq 'Running'} | Select-Object TaskName,TaskPath | Format-Table -Auto"
TaskName TaskPath
-------- --------
\Microsoft\Windows\UpdateOrchestrator\Reboot
\Microsoft\Windows\Defender\MP Scheduled Scan
\Vendor\DailyIndexMaintenance
Ce que cela signifie : « CPU élevé tous les jours à 10:00 » n’est généralement pas un fantôme. C’est un horaire.
Décision : Si une tâche de maintenance correspond au pic, déplacez son horaire, réduisez sa portée, ou exécutez‑la sur une réplique/secondaire. Ne désactivez pas simplement sans accepter le risque associé.
Tâche 9 : Vérifier l’activité Windows Update (commun, ennuyeux, réel)
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 20 | ? {$_.ProviderName -match 'WindowsUpdate|Servicing|TrustedInstaller'} | Select-Object TimeCreated,ProviderName,Id,Message | Format-Table -Wrap"
TimeCreated ProviderName Id Message
----------- ------------ -- -------
02/04/2026 10:03:12 Microsoft-Windows-Servicing 1 The update installation started.
02/04/2026 10:04:01 Microsoft-Windows-Servicing 2 The update installation completed.
Ce que cela signifie : Les activités de servicing et de mise à jour peuvent solliciter fortement le CPU (et le disque), surtout sur des images plus anciennes ou des machines avec bloat du magasin de composants.
Décision : Si c’est la cause, cessez de traiter cela comme « aléatoire ». Corrigez les fenêtres de patch, la mise en scène et l’hygiène d’image.
Tâche 10 : Capturer une trace CPU avec WPR (le geste mature)
cr0x@server:~$ wpr -start CPU -start GeneralProfile
WPR started with profile(s): CPU, GeneralProfile
cr0x@server:~$ timeout /t 30
Waiting for 30 seconds, press a key to continue ...
cr0x@server:~$ wpr -stop C:\Temp\highcpu.etl
WPR stopped. Trace file saved to: C:\Temp\highcpu.etl
Ce que cela signifie : Vous disposez maintenant d’une trace ETL que vous pouvez ouvrir dans Windows Performance Analyzer (WPA) pour voir l’utilisation CPU par processus, thread, pile, DPC/ISR, I/O disque, et plus.
Décision : Si le problème n’est pas trivialement évident, arrêtez. Ne changez pas cinq paramètres. Analysez la trace ou confiez‑la à quelqu’un qui sait le faire.
Tâche 11 : Inventaire rapide du pilote réseau / NIC (les accusations de pilotes exigent des preuves)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,LinkSpeed | Format-Table -Auto"
Name InterfaceDescription Status LinkSpeed
---- -------------------- ------ ---------
Ethernet Intel(R) Ethernet Controller X710 Up 10 Gbps
cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterDriver -Name 'Ethernet' | Select-Object Name,DriverVersion,DriverDate | Format-Table -Auto"
Name DriverVersion DriverDate
---- ------------ ----------
Ethernet 2.1.4.0 06/12/2025
Ce que cela signifie : Vous avez le NIC exact et la version du pilote. Cela compte quand DPC/ISR est chaud ou après des cycles de patch.
Décision : Si un pilote a changé récemment et que DPC est élevé, envisagez un rollback/mise à jour, et vérifiez les paramètres d’offload (avec prudence et contrôle de changement).
Tâche 12 : Vérifier la latence disque et la file d’attente (le CPU est‑il la victime ?)
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write','\PhysicalDisk(_Total)\Current Disk Queue Length' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path CookedValue
---- -----------
\\server\physicaldisk(_total)\avg. disk sec/read 0.045
\\server\physicaldisk(_total)\avg. disk sec/write 0.120
\\server\physicaldisk(_total)\current disk queue length 18
Ce que cela signifie : Des écritures à 120ms et une file d’attente à 18 : le stockage est mal en point. Un CPU élevé peut être secondaire (threads en attente, retries, surcharge compression/chiffrement, ou timeouts applicatifs provoquant des tempêtes).
Décision : Traitez le disque comme suspect de premier plan. Vérifiez qui émet les I/O, la santé du chemin de stockage, et si un « problème CPU » n’est en réalité qu’un backlog I/O.
Tâche 13 : Corréler le CPU avec les changements de contexte (indicateur de surcharge)
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\System\Context Switches/sec','\System\Processor Queue Length' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path CookedValue
---- -----------
\\server\system\context switches/sec 145000
\\server\system\processor queue length 28
Ce que cela signifie : Des changements de contexte très élevés plus une longue file d’attente processeur suggèrent une contention : trop de threads prêt à s’exécuter, contention de verrous, ou une machine occupée à faire beaucoup de petits travaux.
Décision : Si le processus principal est un runtime (java, dotnet, sqlservr) cela peut indiquer une pression sur le pool de threads ou des spinlocks — encore une fois, une trace et/ou un profilage applicatif battent la devinette.
Tâche 14 : Vérifier les indices de virtualisation (Hyper‑V Integration Services & synchronisation temps)
cr0x@server:~$ powershell -NoProfile -Command "systeminfo | findstr /I /C:'System Manufacturer' /C:'System Model'"
System Manufacturer: Microsoft Corporation
System Model: Virtual Machine
Ce que cela signifie : Vous êtes dans une VM. Le CPU peut alors être du « ready time » (contention hôte) ou lié à la gestion d’énergie sur l’hôte.
Décision : Si vous êtes invité avec une lenteur inexpliquée en tant qu’invité, coordonnez‑vous avec l’équipe virtualisation : surallocation CPU hôte, voisins bruyants, et politiques d’ordonnancement comptent.
Tâche 15 : Trouver les services chauds dans svchost (parce que « svchost est haut » est un cri à l’aide)
cr0x@server:~$ tasklist /svc /fi "imagename eq svchost.exe"
Image Name PID Services
========================= ======== ============================================
svchost.exe 1024 DcomLaunch, PlugPlay
svchost.exe 1200 wuauserv, bits
svchost.exe 1468 Dhcp, dnscache
Ce que cela signifie : Vous pouvez mapper un PID svchost chaud aux services qu’il héberge.
Décision : Si le PID 1200 brûle du CPU et contient wuauserv, vous parlez alors du comportement de Windows Update, pas d’un « svchost aléatoire ». Ciblez votre correction.
Blague n°1 : Le Gestionnaire des tâches est comme un détecteur de fumée qui crie aussi l’adresse — utile, mais il ne vous dira toujours pas quelle pièce est en feu.
Quand ce n’est pas « un processus » : interruptions, DPC, pilotes
Les interruptions sont des signaux matériels disant « hé, traite ça ». Les DPC (Deferred Procedure Calls) sont la façon dont Windows reporte une partie du travail d’interruption pour l’exécuter plus tard, quand c’est plus sûr. Quand l’un ou l’autre devient sauvage, vous pouvez obtenir un CPU élevé qui ne se mappe pas proprement à un processus en mode utilisateur.
Causes typiques en production :
- Pilotes NIC et offloads : mauvaise configuration RSS, offload checksum bogué, large send offload problématique, ou régression de pilote après une mise à jour.
- Pilotes stockage et multipath : problèmes HBA/RAID, basculements de chemin, inadéquation de profondeur de file, incohérences de firmware.
- Pilotes filtres : antivirus, DLP, chiffrement, snapshots de sauvegarde — tout ce qui intercepte opérations fichier/réseau.
- USB et « qui a branché ça » : moins fréquent sur serveurs, plus sur postes, mais réel.
Comment ne pas se laisser tromper : si le temps privilégié est élevé et que le temps interruptions/DPC est significatif, ne poursuivez pas « l’appli en tête ». L’appli est souvent en attente derrière du travail noyau. Votre tâche est de trouver la pile de pilotes qui réalise le travail et corriger le périphérique/pilote/config sous‑jacent.
Dans WPA, vous basculerez typiquement via :
- CPU Usage (Sampled) par Processus/Thread/Pile
- DPC/ISR par Module/Pile
- Réseau envoi/réception et coût CPU (si capturé)
Angle ingénierie stockage : CPU qui ressemble à de l’I/O (et inversement)
Le stockage et les pannes CPU s’aiment se déguiser. Un problème de stockage peut gonfler le CPU via retries, timeouts, surcharge de compression/chiffrement et thrashing de caches. Inversement, un problème CPU peut augmenter la latence I/O en privant les threads qui alimentent la file, en retardant le traitement des interruptions, ou en retardant le traitement des complétions.
Mode de panne : « CPU élevé » mais la vraie douleur est la latence disque
Commun avec les fenêtres de sauvegarde, l’indexation, l’antivirus et les jobs de dédup/compression « utiles ». Le CPU effectue du travail, oui, mais les utilisateurs sont affectés parce que la file de stockage est saturée.
Schéma de décision : Si Avg. Disk sec/Read ou Write monte et que la longueur de file augmente avec le CPU, traitez le disque comme le goulot principal. Votre atténuation est de réduire la concurrence d’I/O et les écritures aléatoires, pas de chercher une montée en CPU.
Mode de panne : pilotes filtres augmentant le coût CPU par I/O
L’analyse en temps réel est le classique. Chaque ouverture de fichier devient « ouvrir + analyser + vérification de réputation + éventuellement dépaquetage ». Le CPU monte, le temps privilégié monte, et votre stockage semble « occupé » parce que les opérations sont ralenties et mises en file.
Que faire : validez les exclusions pour bases de données, magasins VM, caches de build et dépôts de sauvegarde. Si vous ne savez pas quoi exclure, demandez au propriétaire de l’application et à l’équipe sécurité et documentez‑le. Puis testez. Puis mesurez.
Mode de panne : serveurs SMB et CPU
Les serveurs de fichiers peuvent brûler du CPU pour faire du chiffrement/signature, gérer des tempêtes de métadonnées, ou traiter des clients bavards. Parfois la solution est embarrassante mais efficace : mettre à jour les pilotes NIC, vérifier RSS, valider la configuration SMB multichannel, et arrêter l’analyse continue de tout le partage.
Faits intéressants et contexte historique (édition CPU Windows)
- « Processus d’inactivité système » n’est pas un vrai processus. Il représente le CPU qui ne fait rien. Un « Idle » élevé est une bonne nouvelle, même si beaucoup paniquent en le voyant.
- Windows a évolué vers l’isolation par service. Historiquement, de nombreux services partageaient
svchost.exe; les versions modernes peuvent scinder les services plus finement, améliorant la diagnostique. - La latence DPC est devenue célèbre via les coupures audio. Les mêmes mécanismes qui provoquent du son saccadé peuvent aussi saboter le débit serveur — avec des symptômes moins dramatiques.
- Les compteurs PerfMon précèdent la plupart des outils d’observabilité modernes. Ils existent depuis des décennies ; ils restent l’une des sources de vérité les plus fiables sur un hôte Windows.
- ETW (Event Tracing for Windows) est l’épine dorsale du travail sérieux sur les performances Windows. WPR/WPA sont des portes conviviales vers ETW, qui est un mécanisme de traçage central depuis la maturation de la lignée NT.
- Le passage au plan « balanced » n’était pas que du marketing. Les CPUs modernes ont un scaling de fréquence rapide, mais des charges serveurs avec des budgets de latence serrés peuvent encore souffrir sous des économies d’énergie agressives.
- L’intégration antimalware a changé la donne. Defender et les AV tiers s’intègrent de plus en plus via des hooks noyau et des pilotes filtres, ce qui fait qu’ils peuvent apparaître comme du CPU noyau, pas un coupable propre en espace utilisateur.
- La virtualisation a transformé le CPU en ressource partagée et politique. Une fois invité, le temps CPU dépend des voisins et des politiques hôtes ; « ma VM est lente » est parfois « quelqu’un d’autre a acheté tout le CPU ».
Trois mini-histoires d’entreprise issues du terrain
Mini-histoire 1 : L’incident causé par une fausse hypothèse
L’alerte était simple : « Windows Server : CPU > 90% pendant 15 minutes. » C’était un serveur applicatif de niveau intermédiaire, rien d’exotique. La personne de garde a regardé le Gestionnaire des tâches, vu w3wp.exe en haut, et déclara : « IIS fond. » Ils ont recyclé le pool d’applications. Le CPU a baissé. Tout le monde a soufflé. Deux minutes plus tard, CPU remontait en flèche.
Ils ont enchaîné les rituels habituels : redémarrer le service, vider les fichiers temporaires, recycler encore plus fort. Ce n’est pas un vrai plan, c’est une danse interprétative. Pendant ce temps, le temps privilégié était stratosphérique, mais personne n’a regardé parce que le Gestionnaire des tâches ne le montrait pas assez fort.
Après une heure de whack‑a‑mole, quelqu’un a lancé quelques compteurs : % Privileged Time dominait, et % DPC Time était dans les dizaines. Le CPU « IIS » était collatéral : les threads de requête tournaient en boucle et expiraient pendant que le noyau traitait des interruptions réseau.
La cause racine était une mise à jour du pilote NIC poussée dans un bundle fournisseur « routine ». Sur ce modèle particulier, avec cette configuration d’offload, cela produisait un schéma lourd en DPC sous certaines formes de trafic. Revenir au pilote précédent a corrigé le problème instantanément. La mauvaise hypothèse était de penser qu’un processus en tête implique causalité. Ce n’est pas le cas. Cela implique proximité de la douleur.
La correction durable n’a pas été « ne jamais mettre à jour les pilotes ». Ce fut : figer des versions testées, surveiller les compteurs DPC/interrupt, et traiter les bundles fournisseurs comme de véritables changements avec une zone d’impact.
Mini-histoire 2 : L’optimisation qui s’est retournée contre eux
Une équipe voulait un accès fichier plus rapide sur une VM Windows hébergeant des artefacts de build. Quelqu’un a suggéré d’activer une analyse temps réel agressive « pour la sécurité », puis de compenser en augmentant le nombre de vCPU. En environnement calme, ça semblait ok. En production, ce fut un désastre : CPU montait, opérations fichiers ralentissaient, et la ferme de build commença à expirer.
Ils ont ensuite « optimisé » en activant plus de parallélisme dans le build pour « mieux utiliser le CPU ». C’est ainsi qu’on crée une bousculade. Le pilote filtre antivirus rendait chaque accès fichier plus coûteux. Plus de parallélisme a multiplié la surcharge et ajouté des changements de contexte. Le CPU a atteint le plafond, les files disques se sont remplies, et les agents de build ont recommencé, aggravant la situation.
Quand ils ont finalement tracé, les piles coûteuses se trouvaient dans les chemins de filtre système de fichiers. Ce n’était pas une régression mystérieuse de l’appli. C’était une surcharge auto‑infligée avec une bonne intention et une mauvaise mesure.
La correction fut ennuyeuse et efficace : exclure correctement les répertoires d’artefacts et caches de build, et déplacer les analyses lourdes vers une fenêtre programmée sur une réplique. Ils ont conservé la sécurité et regagné des performances. La leçon clé : augmenter les vCPU pour masquer une surcharge n’est pas une optimisation ; c’est acheter une poubelle plus grande au lieu de sortir les déchets.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une autre organisation exploitait des serveurs de bases de données Windows qui faisaient occasionnellement monter le CPU lors du traitement de fin de mois. La différence était : ils avaient l’habitude de collecter un petit ensemble de compteurs PerfMon en continu et de le conserver pour une période de rétention raisonnable. Pas pour toujours. Juste assez pour répondre à « est‑ce nouveau ? »
Quand le pic est revenu, la personne de garde n’a pas commencé par des opinions. Ils ont comparé les compteurs au cycle précédent. Cette fois, le CPU était élevé mais % Processor Performance était anormalement bas, et le pic corrélait avec une hausse d’erreurs matérielles corrigées journalisées par la plateforme.
Il s’est avéré que le serveur avait un problème de refroidissement après une fenêtre de maintenance : une politique de courbe de ventilateur avait changé dans le firmware. Le CPU throttlait sous charge. Le moteur de base de données faisait le même travail, plus lentement, plus longtemps, avec plus de temps passé en « CPU élevé ».
La correction n’était pas une reconstruction d’index ou une réécriture de requête. Ce fut restaurer la politique thermique attendue du firmware et vérifier la télémétrie environnementale. Ils ont évité une semaine d’optimisations inutiles parce qu’ils avaient des baselines et la discipline de les consulter.
Blague n°2 : Le CPU élevé est la façon dont l’univers vous demande si vous avez des baselines. Si vous n’en avez pas, il redemande, plus fort.
Erreurs courantes : symptôme → cause racine → correction
C’est la partie où vous arrêtez de perdre des heures sur les mêmes pièges.
1) « Le Gestionnaire des tâches affiche 100% CPU, mais le principal processus n’est qu’à 5% »
Cause racine : Le CPU est consommé en temps noyau : interruptions/DPC, travail pilote, ou vous échantillonnez trop lentement / regardez la mauvaise vue.
Correction : Vérifiez % Privileged Time, % DPC Time, % Interrupt Time. Prenez une trace WPR. Validez les versions de pilotes et les mises à jour récentes.
2) « Le processus System est élevé, donc Windows est cassé »
Cause racine : « System » est un bac pour l’activité noyau, souvent déclenchée par un comportement matériel/pilote ou des pilotes filtres.
Correction : Dans WPA, analysez les piles CPU échantillonnées et DPC/ISR par module. Inventoriez les pilotes filtres (AV, sauvegarde, DLP), pilotes NIC/HBA, et procédez aux changements avec précaution.
3) « svchost.exe est le coupable »
Cause racine : svchost héberge plusieurs services ; vous blâmez l’immeuble.
Correction : Utilisez tasklist /svc pour mapper PID vers services, puis enquêtez le service spécifique (Update, BITS, cache DNS, etc.).
4) « CPU élevé après patch, donc revenir les MAJ OS »
Cause racine : servicing post‑patch, scans Defender, maintenance du magasin de composants, ou une mise à jour de pilote fournie avec les patches.
Correction : Vérifiez les journaux d’événements pour l’activité de servicing, validez les tâches Defender, et gérez explicitement les mises à jour de pilotes. Revenir sur des MAJ OS est un dernier recours, pas un réflexe.
5) « On a ajouté des vCPU et c’est pire »
Cause racine : La parallélisation accrue a amplifié la contention de verrous, les changements de contexte, ou l’hôte est sur‑commis.
Correction : Mesurez les changements de contexte, la longueur de file processeur, et (dans les outils de virtualisation) le CPU ready/steal. Envisagez moins de vCPU plus rapides plutôt que beaucoup de vCPU lents. Profilez avant d’augmenter.
6) « CPU élevé signifie besoin d’un serveur plus gros »
Cause racine : Cela peut être un thread chaud unique, un mauvais plan de requête, un spinlock, ou une tempête de pilotes — scaler n’arrange pas un comportement cassé.
Correction : Identifiez si c’est lié à un seul cœur, au noyau, ou au calcul multi‑cœur. Utilisez des traces et l’analyse par thread avant de redimensionner.
7) « La latence disque est élevée, donc seul le stockage est en cause »
Cause racine : La privation CPU peut retarder le traitement des complétions I/O ; AV/filtre CPU peut ralentir les opérations fichiers ; un problème réseau peut se manifester comme symptôme stockage (retries SMB).
Correction : Corrélez le temps privilégié CPU, DPC/ISR, et la file/latence disque. Réparez le goulot primaire, pas la métrique la plus bruyante.
8) « On a désactivé l’antivirus et le CPU a chuté, donc c’est réglé »
Cause racine : Vous avez retiré un contrôle critique sans traiter les caractéristiques de la charge qui l’ont déclenché.
Correction : Mettez en place des exclusions correctes, ajustez les fenêtres d’analyse, et validez les performances avec la sécurité activée. Si le produit est pathologique, remplacez‑le avec un plan mesuré.
Listes de contrôle / plan étape par étape
Checklist A : Triage en garde de 10 minutes (sans héroïsme)
- Confirmez le CPU soutenu avec un échantillon rapide de compteur (Tâche 2). Si ce n’est pas soutenu, ne traitez pas ça comme une panne.
- Identifiez le processus principal (Tâche 1). Si c’est clairement une appli, commencez par là.
- Séparez utilisateur vs privilégié (Tâche 3). Une prédominance privilégiée signifie noyau/pilote/filtre.
- Vérifiez interruptions et DPC (Tâche 4). Des valeurs à deux chiffres signifient « arrêtez de deviner, tracez. »
- Vérifiez latence/queue disque (Tâche 12). Si le stockage est saturé, le CPU peut être secondaire.
- Vérifiez power/throttling (Tâche 6 + Tâche 7). Une faible % Processor Performance est un signal évident.
- Vérifiez les tâches planifiées en cours (Tâche 8). Alignez les timelines.
- Mappez les services svchost si pertinent (Tâche 15).
- Décidez atténuation vs capture : si le service est dégradé, atténuez avec un changement minimal. Si stabilisé, capturez WPR (Tâche 10).
- Notez ce que vous avez vu : compteurs, timestamps, ce qui a changé. Votre vous futur est une personne différente.
Checklist B : Si c’est un processus applicatif (chemin saturation calcul)
- Confirmez si c’est un cœur ou plusieurs (vue par processeur logique du Gestionnaire des tâches ; vérifiez aussi si un thread domine dans la télémétrie appli).
- Collectez une trace d’échantillonnage CPU WPR (Tâche 10) durant le hotspot.
- Cherchez la pression GC (runtimes managés), boucles serrées, journalisation excessive, crypto/compression, ou regex/serialisation pathologiques.
- Vérifiez les dépendances aval : des timeouts peuvent créer des tempêtes de retries qui ressemblent à du « calcul ».
- Atténuez : limitez le job, réduisez la concurrence, revenez en arrière, scale‑out uniquement si ça achète du temps et que vous comprenez pourquoi.
Checklist C : Si c’est noyau/pilote (chemin privilégié/DPC)
- Capturez WPR avec CPU + General profile (Tâche 10). Si sûr, capturez un peu plus longtemps (60–120 secondes) pendant le pic.
- Inventoriez les NIC et pilotes (Tâche 11) et vérifiez les changements récents.
- Vérifiez les pilotes filtres impliqués : AV, sauvegarde, chiffrement, DLP. Confirmez périmètre et exclusions.
- Validez la santé du chemin de stockage : stabilité multipath, alignement pilote/firmware HBA, et comportement des files.
- Atténuez : revenez sur des changements de pilote, basculez vers des chemins redondants, réduisez la complexité d’offload NIC seulement si vous pouvez tester et mesurer.
Checklist D : Si c’est une VM (chemin contention)
- Confirmez que la machine est virtuelle (Tâche 14).
- Collectez des preuves dans l’invité : compteurs CPU, longueur de file, changements de contexte, indicateurs de throttling.
- Escaladez avec des éléments précis : timestamps, durée soutenue, et quel type de CPU (utilisateur/privilégié/DPC).
- Côté hôte (avec l’équipe virtualisation) : vérifiez contention CPU/ready time et bruit des co‑locataires.
- Atténuez : migrez à chaud, réduisez la surallocation, réservez des ressources pour VMs critiques, ou isolez les charges bruyantes.
FAQ
Q1: Pourquoi le Gestionnaire des tâches affiche « 100% CPU » alors que le système semble inactif ?
Parce que le CPU peut être consommé par du travail noyau (interruptions/DPC) ou par de courtes rafales qui donnent une moyenne élevée alors que le débit reste faible (throttling, contention). Vérifiez % Privileged Time, % DPC Time, et les compteurs de performance CPU.
Q2: Un CPU élevé est‑il toujours mauvais ?
Non. Si le système respecte les objectifs de latence et de débit, un CPU élevé signifie simplement que vous utilisez le serveur pour lequel vous avez payé. Le mauvais cas est CPU élevé plus files d’attente plus SLOs manqués.
Q3: Quelle est la manière la plus rapide de trouver le processus coupable ?
Utilisez Gestionnaire des tâches/Moniteur de ressources pour un premier aperçu, puis PowerShell pour lister les processus et capturez une trace WPR. Si le coupable change rapidement, la traçabilité bat l’observation visuelle.
Q4: Et si « System » est le principal consommateur CPU ?
Traitez‑le comme une enquête noyau/pilote. Vérifiez le temps privilégié et le temps DPC/interrupt. Puis capturez WPR et analysez dans WPA pour voir quel pilote/module consomme les cycles.
Q5: Comment savoir si c’est un goulot mono‑thread ?
Si le CPU global n’est pas saturé mais que la performance est mauvaise, ou si un processeur logique est saturé tandis que les autres sont bas, vous avez probablement un thread chaud unique. Les piles échantillonnées de WPA et le CPU par thread le confirmeront.
Q6: L’antivirus peut‑il vraiment causer un « CPU élevé » sur des serveurs ?
Absolument. L’analyse en temps réel et les vérifications de réputation ajoutent un coût CPU à chaque opération fichier et peuvent apparaître comme du temps privilégié. La solution est généralement des exclusions correctes et une planification, pas désactiver la sécurité.
Q7: Quels compteurs dois‑je consigner en continu pour des environnements « CPU élevé inconnu » ?
Au minimum : \Processor(_Total)\% Processor Time, % User Time, % Privileged Time, % DPC Time, % Interrupt Time, \System\Processor Queue Length, \System\Context Switches/sec, et des compteurs basiques de latence/queue disque.
Q8: Combien de temps faut‑il exécuter WPR ?
Assez pour capturer le hotspot (typiquement 30–120 secondes). Les traces courtes sont plus faciles à analyser et moins risquées. Si le pic est périodique, capturez pendant le pic, pas après.
Q9: Dois‑je changer le plan d’alimentation Windows en High performance sur des serveurs ?
Seulement si vous avez observé du throttling ou une sensibilité à la latence, et que vous pouvez mesurer l’amélioration. C’est un outil, pas une superstition. Validez avec % Processor Performance et les métriques de la charge.
Q10: Quelle est la cause la plus courante d’un « CPU élevé sans indice » en entreprise Windows ?
Les pilotes filtres et les tâches de maintenance : analyses antivirus, servicing de mises à jour, indexation, agents de sauvegarde, et régressions de pilotes après des cycles de patch. Le thème courant : le CPU fait du travail que vous n’aviez pas budgété.
Conclusion : quoi faire la prochaine fois avant que ce soit « urgent »
Quand quelqu’un dit « CPU élevé », votre travail est de refuser l’encadrement vague et de le remplacer par une classification : calcul processus, noyau/pilote, contention, ou confusion de mesure. Ensuite prenez le chemin le plus court vers la preuve.
Étapes pratiques à faire cette semaine :
- Standardisez un petit baseline PerfMon sur les hôtes Windows critiques. Conservez assez d’historique pour répondre à « est‑ce nouveau ? »
- Faites de la capture WPR une habitude. Une trace de 60 secondes pendant la douleur vaut dix heures d’opinions après.
- Figez et gérez les versions de pilotes pour NIC/storage sur les serveurs. Traitez‑les comme des dépendances, pas du bruit d’arrière‑plan.
- Documentez les exclusions AV et les fenêtres de maintenance avec les propriétaires applicatifs. Si c’est non documenté, ça tournera au pire moment.
- Définissez un paquet d’escalade : compteurs, timestamps, processus en tête, privilégié/DPC/interrupt, latence disque, et si c’est une VM. Cela transforme « aide » en « action ».
Le CPU élevé sans indice n’est pas un mystère. C’est généralement une habitude manquante : mesurez la bonne chose, au bon moment, et changez une variable à la fois. Le reste n’est que du bruit avec un numéro de ticket.