Processus « System » utilise beaucoup de CPU ? C’est souvent un pilote — comment le prouver

Ce qu’est réellement le processus « System » (et ce qu’il n’est pas)

Le System (PID 4 sur la plupart des systèmes) n’est pas « un programme » comme votre service. C’est un conteneur pour le travail en mode noyau :
des threads s’exécutant dans le noyau Windows et des pilotes noyau. Lorsqu’il utilise beaucoup de CPU, quelque chose en mode noyau brûle des cycles — souvent en traitant des interruptions,
en exécutant des DPC (Deferred Procedure Calls), ou en parcourant des chemins d’E/S.

Quelques clarifications qui évitent de mauvaises décisions dès le départ :

• System avec CPU élevé n’est pas une preuve de malware. Un malware peut en être la cause, mais « System » est plus souvent votre pilote de stockage ou de carte réseau qui fait des siennes.
• System avec CPU élevé n’est pas un bug applicatif — jusqu’à ce que ça le soit. Les applications peuvent déclencher des chemins noyau (p. ex. tempêtes d’E/S, écritures minuscules, thrashing mmap) qui exposent un défaut de pilote ou une mauvaise config.
• « System interrupts » dans le Gestionnaire des tâches est un symptôme, pas un processus. C’est du temps passé à servir des interruptions matérielles, ce qui reste souvent une histoire de « pilote ou matériel ».
• Désactiver des services au hasard aide rarement. Le temps noyau se moque de votre indexeur Windows Search quand la file de DPC fond.

L’objectif n’est pas « réduire le CPU du System » par esthétique. L’objectif est d’identifier quel composant noyau consomme du temps et pourquoi,
puis choisir l’action corrective la moins risquée : mise à jour/rollback du pilote, correction de firmware, réglage d’offload, suppression d’un filtre, ajustement de la profondeur de file,
ou remplacement d’un périphérique défaillant.

Faits intéressants et un peu d’histoire (parce que ce n’est pas nouveau)

1. Le processus « System » existe depuis la lignée NT — une conception qui mettait l’accent sur la séparation claire entre mode utilisateur et mode noyau, avec des modèles de pilotes stables.
2. Les DPC existent parce qu’on ne peut pas tout faire au moment de l’interruption. Les handlers d’interruption doivent être rapides ; le travail lourd est différé aux DPC, qui s’exécutent quand même à haute priorité.
3. ETW (Event Tracing for Windows) existe depuis Windows 2000 et reste le moyen le plus fiable pour prouver où le temps noyau a été consommé.
4. Storport a remplacé les anciens drivers port de stockage pour la performance et l’évolutivité, mais lorsqu’il dysfonctionne, il le fait bruyamment : CPU élevé, réinitialisations et pics de latence.
5. Les offloads NDIS sont une bénédiction pour la productivité et une malédiction pour le débogage : checksum offload, LSO, RSC, RSS. Super quand tout va bien ; dramatique quand c’est buggé.
6. Les drivers filtres sont partout : antivirus, DLP, agents de sauvegarde, chiffrement, snapshot, monitoring. Ils se trouvent sur les chemins chauds et peuvent transformer « ok » en « mystérieux ».
7. Le scheduler et le routage des interruptions de Windows ont changé notablement selon les versions (et les générations matérielles). Un pilote qui marche sur 2016 peut se comporter différemment sur 2022 avec des cœurs modernes et NUMA.
8. La modulation des interruptions s’est généralisée parce que le réseau à pleine ligne noierait sinon les CPU. Mal faite, elle crée de la latence ; trop agressive, elle crée des interruptions en continu.
9. Un CPU élevé masque parfois un problème d’alimentation/firmware. Les états C, le microcode BIOS et un firmware bogué peuvent se manifester par un comportement d’interruption étrange ou des tempêtes de timers.

Un modèle mental utile : le CPU noyau est rarement « aléatoire ». C’est presque toujours une boucle, une file, une tempête ou une répétition.
Votre travail est de trouver la file.

Playbook de diagnostic rapide (premiers/seconde/troisième contrôles)

Premier : classer la combustion CPU (user vs kernel vs interrupts)

• Le CPU global est-il élevé, ou juste un cœur saturé ?
• Le temps est-il en Temps noyau (privileged) ou Temps utilisateur ?
• Le Gestionnaire des tâches montre-t-il un System élevé et/ou un System interrupts élevé ?

Si le temps noyau domine, cessez de regarder les flamegraphs applicatifs et commencez à collecter des preuves côté noyau.

Second : décider si c’est I/O, réseau ou « matériel bizarre »

• Suspects stockage : latence disque élevée, longueur de file élevée, warnings Storport, réinitialisations, drivers filtres, changements multipath.
• Suspects réseau : pertes, retransmissions, interruptions élevées sur la NIC, basculements d’offload, warnings NDIS.
• Suspects matériel bizarre : périphériques USB, audio, GPU, chipset, timers de gestion d’alimentation.

Troisième : capturer une preuve à présenter au vendor ou au comité de changement

• Trace ETW (WPR/WPA) ciblant l’utilisation CPU par pilote, ISR, DPC.
• Compteurs Perf pour taux d’interruptions/DPC, latence disque/file, paquets réseau/interruptions.
• Journaux d’événements : canal Système pour Storport, disk, NVMe, NDIS, WHEA erreurs matérielles.

Si vous ne pouvez pas produire une chronologie qui corrèle « pic CPU » avec « routine de pilote dominant DPC/ISR » ou « tempête de resets storport », vous n’avez pas de preuve — vous avez des impressions.

Comment prouver que c’est un pilote : la chaîne de preuves

« C’est un pilote » est une affirmation. Pour en faire une preuve, vous voulez une chaîne de preuves qui tienne en salle de crise :
symptômes → mesures → attribution → changement contrôlé → résultat.

1) Symptômes : ce que les utilisateurs remarquent correspond aux modes de défaillance noyau

• RDP lent, délai clavier : souvent une pression d’interruptions/DPC privant les threads normaux.
• Pics de latence stockage : Storport, stornvme, firmware HBA, basculement multipath, drivers filtres.
• Gigue réseau : interruptions NIC, problèmes d’offload, mauvaise configuration RSS, bugs de files pilote.
• Pops audio (sur postes) : symptômes classiques de latence DPC.

2) Mesures : confirmer que le temps noyau est réellement le problème

Utilisez compteurs et traces. Ne vous fiez pas à une seule capture du Gestionnaire des tâches comme diagnostic médical.

3) Attribution : identifier le composant noyau qui effectue le travail

C’est là qu’ETW gagne. Vous voulez voir des piles CPU échantillonnées qui atterrissent dans un module pilote (p. ex. storport.sys, stornvme.sys, ndis.sys,
driver NIC vendeur, filtre de chiffrement, minifilter antivirus).

4) Changement contrôlé : isoler sans casser la production

Choisissez des changements réversibles et sûrs : rollback d’un pilote, basculer un offload, désactiver un filtre en fenêtre de maintenance,
changer de port NIC, déplacer une VM sur un autre hôte, ou modifier la profondeur de file. Puis re-mesurer.

5) Résultat : montrer avant/après avec les mêmes outils

Si le taux de DPC diminue, le CPU noyau baisse et la latence se normalise après votre changement, vous avez la causalité. Sinon, continuez d’explorer.

Idée paraphrasée de Werner Vogels (fiabilité/ops) : Tout échoue éventuellement ; les systèmes résilients supposent la défaillance et récupèrent automatiquement.
Dans ce contexte : supposez que les pilotes peuvent échouer, et entraînez-vous à produire des preuves répétables et à savoir revenir en arrière.

Tâches pratiques : commandes, sorties, sens et décisions (12+)

Celles-ci sont délibérément orientées vers ce que vous pouvez faire sur un vrai Windows Server sans installer des outils mystérieux. Certaines tâches utilisent des utilitaires intégrés,
d’autres des composants de Windows Performance Toolkit souvent présents dans les images d’entreprise. Exécutez-les en Administrateur sauf indication contraire.

Task 1: Confirm kernel vs user CPU quickly (typeperf)

cr0x@server:~$ typeperf "\Processor(_Total)\% Privileged Time" "\Processor(_Total)\% User Time" -sc 5
"(PDH-CSV 4.0)","\\SERVER\Processor(_Total)\% Privileged Time","\\SERVER\Processor(_Total)\% User Time"
"02/04/2026 09:12:01.123","42.187500","7.031250"
"02/04/2026 09:12:02.125","45.312500","6.250000"
"02/04/2026 09:12:03.126","44.531250","5.468750"
"02/04/2026 09:12:04.128","46.093750","6.640625"
"02/04/2026 09:12:05.129","43.750000","6.250000"

Ce que cela signifie : Le temps privilégié dépasse largement le temps utilisateur. C’est de l’exécution noyau — pilotes, routines noyau, interruptions.

Décision : Cessez d’optimiser les applis. Commencez à attribuer le CPU noyau (DPC/ISR, pilotes, chemins d’E/S).

Task 2: Check interrupts and DPC rate (typeperf)

cr0x@server:~$ typeperf "\Processor(_Total)\Interrupts/sec" "\Processor(_Total)\% DPC Time" "\Processor(_Total)\% Interrupt Time" -sc 5
"(PDH-CSV 4.0)","\\SERVER\Processor(_Total)\Interrupts/sec","\\SERVER\Processor(_Total)\% DPC Time","\\SERVER\Processor(_Total)\% Interrupt Time"
"02/04/2026 09:13:10.111","182345.000000","28.125000","6.250000"
"02/04/2026 09:13:11.112","190220.000000","30.468750","6.640625"
"02/04/2026 09:13:12.114","188900.000000","29.687500","6.250000"
"02/04/2026 09:13:13.116","191450.000000","31.250000","6.640625"
"02/04/2026 09:13:14.117","187300.000000","29.296875","6.250000"

Ce que cela signifie : Interrupts/sec est énorme ; le temps DPC est élevé. C’est le territoire classique d’une « tempête d’interruptions/DPC ».

Décision : Identifiez quel périphérique/pilote génère les interruptions (souvent NIC ou stockage). Passez à ETW et à la corrélation avec le périphérique.

Task 3: Spot per-core skew (single core pinned by interrupts)

cr0x@server:~$ typeperf "\Processor(0)\% Interrupt Time" "\Processor(1)\% Interrupt Time" "\Processor(2)\% Interrupt Time" "\Processor(3)\% Interrupt Time" -sc 3
"(PDH-CSV 4.0)","\\SERVER\Processor(0)\% Interrupt Time","\\SERVER\Processor(1)\% Interrupt Time","\\SERVER\Processor(2)\% Interrupt Time","\\SERVER\Processor(3)\% Interrupt Time"
"02/04/2026 09:14:30.010","18.750000","0.000000","0.000000","0.000000"
"02/04/2026 09:14:31.011","20.312500","0.000000","0.000000","0.000000"
"02/04/2026 09:14:32.013","19.531250","0.000000","0.000000","0.000000"

Ce que cela signifie : Un CPU effectue le travail d’interruption. Cela pointe souvent vers des problèmes d’affinité/routage d’interruptions, une mauvaise configuration RSS, ou un périphérique bloqué sur un seul cœur.

Décision : Inspectez RSS du NIC, la modulation d’interruptions et les pilotes ; envisagez aussi BIOS/firmware et drivers chipset.

Task 4: Find noisy System log events (storage/network/hardware)

cr0x@server:~$ wevtutil qe System /q:"*[System[(Level=2 or Level=3) and TimeCreated[timediff(@SystemTime) <= 3600000]]]" /f:text /c:20
Event[0]:
  Log Name: System
  Source: storport
  Date: 2026-02-04T09:02:11.0000000Z
  Event ID: 129
  Level: Warning
  Description:
    Reset to device, \Device\RaidPort3, was issued.

Event[1]:
  Log Name: System
  Source: Disk
  Date: 2026-02-04T09:02:12.0000000Z
  Event ID: 153
  Level: Warning
  Description:
    The IO operation at logical block address ... was retried.

Ce que cela signifie : Réinitialisations Storport et retries disque se corrèlent fortement avec des pics de CPU noyau et de la latence. Les tempêtes de resets sont coûteuses.

Décision : Traitez-le comme un problème du chemin de stockage jusqu’à preuve du contraire : pilote/firmware, HBA, multipath, SAN, câblage, firmware NVMe, drivers filtres.

Task 5: Check WHEA hardware errors (silent saboteurs)

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger'] and TimeCreated[timediff(@SystemTime) <= 86400000]]]" /f:text /c:10
Event[0]:
  Log Name: System
  Source: Microsoft-Windows-WHEA-Logger
  Date: 2026-02-04T02:44:19.0000000Z
  Event ID: 17
  Level: Warning
  Description:
    A corrected hardware error has occurred.

Ce que cela signifie : Les erreurs corrigées coûtent quand même du temps et peuvent déstabiliser les pilotes (surtout stockage et périphériques PCIe).

Décision : Récupérez les versions de firmware, vérifiez la santé PCIe/NVMe, et ne « pas ignorer » les erreurs corrigées sur une flotte.

Task 6: List drivers and versions (quick blame shortlist)

cr0x@server:~$ driverquery /v /fo table | findstr /i "storport stornvme ndis wdf01000"
storport.sys                10.0.20348.1      Kernel Driver
stornvme.sys                10.0.20348.1      Kernel Driver
ndis.sys                    10.0.20348.1      Kernel Driver
Wdf01000.sys                10.0.20348.1      Kernel Driver

Ce que cela signifie : Cela montre seulement les composants Microsoft de base. Vous voulez aussi les drivers vendeurs (NIC/HBA) et les drivers filtres (AV, sauvegarde).

Décision : Énumérez ensuite les drivers non-Microsoft ; si un driver vendeur a été mis à jour récemment, vous avez un suspect prioritaire.

Task 7: Enumerate non-Microsoft drivers (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_PnPSignedDriver | ? {$_.DriverProviderName -notmatch 'Microsoft'} | select DeviceName,DriverProviderName,DriverVersion,InfName | sort DriverProviderName | ft -Auto"
DeviceName                      DriverProviderName   DriverVersion     InfName
Intel(R) Ethernet Controller    Intel                2.1.4.0           oem42.inf
Vendor NVMe Controller          Contoso Storage Inc.  1.9.12.3          oem18.inf
Virtual Bus Enumerator          Fabrikam Virtual      3.2.0.7           oem77.inf

Ce que cela signifie : Vous avez maintenant les noms et versions des drivers vendeurs. Faites correspondre cela avec votre timeline de changements.

Décision : Si le timing coïncide avec un déploiement, testez un rollback sur un nœud (ou déplacez la charge) et mesurez de nouveau.

Task 8: Check filter drivers in the storage stack (fltmc)

cr0x@server:~$ fltmc filters
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------    --------    -----
WdFilter                        12              328010      0
FileInfo                        12              45000       0
ContosoDlpFilter                12              370000      0
FabrikamBackupSnap              12              385000      0

Ce que cela signifie : Les minifilters interceptent les E/S fichiers. Si le CPU noyau est élevé lors d’une forte activité disque, les filtres sont des coupables fréquents.

Décision : Si vous voyez des filtres non essentiels sur des serveurs (surtout des agents), planifiez un test de désactivation/désinstallation contrôlé sur un hôte.

Task 9: See which volumes and instances filters attach to (fltmc instances)

cr0x@server:~$ fltmc instances
Filter                      Volume Name                     Instance Name                 Altitude    Frame
--------------------------  ------------------------------  ----------------------------  --------    -----
ContosoDlpFilter            \Device\HarddiskVolume3         ContosoDlpFilter Instance     370000      0
FabrikamBackupSnap          \Device\HarddiskVolume3         FabrikamBackupSnap Instance   385000      0
WdFilter                    \Device\HarddiskVolume3         WdFilter Instance             328010      0

Ce que cela signifie : Si le volume chaud est celui qui a une forte empilement de filtres, vous avez un mécanisme plausible d’amplification du chemin chaud.

Décision : Décidez si la valeur métier de chaque filtre justifie le risque performance/fiabilité ; si oui, adaptez et excluez des chemins.

Task 10: Capture an ETW trace with WPR for CPU + DPC/ISR

cr0x@server:~$ wpr -start CPU -start DiskIO -start Network -filemode
WPR started. Logging to file...

Ce que cela signifie : Vous enregistrez des événements noyau. Reproduisez le problème pendant 30–120 secondes, puis arrêtez.

Décision : Si vous pouvez reproduire, vous pouvez prouver. Si vous ne pouvez pas reproduire, loggez plus longtemps et corrélez avec les horodatages des plaintes.

Task 11: Stop the trace and save it (WPR)

cr0x@server:~$ wpr -stop C:\Temp\system-highcpu.etl
WPR stopped. ETL saved to: C:\Temp\system-highcpu.etl

Ce que cela signifie : Vous avez maintenant un fichier ETL que vous pouvez ouvrir dans Windows Performance Analyzer (WPA) pour voir l’utilisation CPU par pile et module.

Décision : Ouvrez l’ETL dans WPA et regardez CPU Usage (Sampled), DPC/ISR, et les call stacks. Si la pile chaude pointe vers un pilote, vous avez l’attribution.

Task 12: Quick performance counter snapshot for disk latency and queue

cr0x@server:~$ typeperf "\PhysicalDisk(_Total)\Avg. Disk sec/Read" "\PhysicalDisk(_Total)\Avg. Disk sec/Write" "\PhysicalDisk(_Total)\Current Disk Queue Length" -sc 5
"(PDH-CSV 4.0)","\\SERVER\PhysicalDisk(_Total)\Avg. Disk sec/Read","\\SERVER\PhysicalDisk(_Total)\Avg. Disk sec/Write","\\SERVER\PhysicalDisk(_Total)\Current Disk Queue Length"
"02/04/2026 09:18:01.000","0.035","0.120","48.000"
"02/04/2026 09:18:02.000","0.041","0.140","52.000"
"02/04/2026 09:18:03.000","0.038","0.131","49.000"
"02/04/2026 09:18:04.000","0.040","0.152","56.000"
"02/04/2026 09:18:05.000","0.039","0.145","54.000"

Ce que cela signifie : Les écritures sont lentes et les files profondes. Le CPU noyau peut augmenter à cause de retries, resets et tempêtes de complétions.

Décision : Confirmez avec les événements Storport/Disk et ETW Disk I/O ; investiguez le pilote/firmware de stockage et l’empilement de filtres.

Task 13: Check network errors and offload state (netsh)

cr0x@server:~$ netsh int tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Receive Segment Coalescing State    : enabled
Chimney Offload State               : disabled
NetDMA State                        : disabled
Direct Cache Access (DCA)           : disabled

Ce que cela signifie : Les états RSC/RSS importent. Si vous voyez des interruptions élevées et du CPU, des offloads bogués ou des réglages incompatibles sont suspects.

Décision : Si ETW pointe vers NDIS/driver NIC, testez le basculement d’un offload à la fois sur un hôte, puis re-mesurez.

Task 14: Verify RSS queues and CPU mapping (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | ft -Auto"
Name           Enabled  NumberOfReceiveQueues  MaxNumberOfReceiveQueues  ProcessorGroup  BaseProcessorNumber
----           -------  ---------------------  ------------------------  --------------  -------------------
Ethernet0      True     2                      16                        0               0

Ce que cela signifie : Si une NIC 25/40/100Gb tourne avec 1–2 queues, vous pouvez subir la taxe du cœur unique.

Décision : Augmentez les queues (dans les limites du vendor), assurez la compatibilité VMQ/RSS, et validez la distribution des interruptions ensuite.

Task 15: Correlate “System” CPU with a specific driver module via live kernel sampling (xperf)

cr0x@server:~$ xperf -on PROC_THREAD+LOADER+PROFILE -stackwalk Profile -buffersize 1024 -MaxFile 256 -FileMode Circular -f C:\Temp\cpu-kernel.etl
xperf: Tracing session started.

cr0x@server:~$ timeout /t 60
Waiting for 60 seconds, press a key to continue ...

cr0x@server:~$ xperf -d C:\Temp\cpu-kernel.etl
xperf: Tracing session stopped.
xperf: Trace merged and written to C:\Temp\cpu-kernel.etl

Ce que cela signifie : C’est une trace d’échantillonnage CPU que vous pouvez ouvrir dans WPA. « CPU Usage (Sampled) » avec les piles mettra souvent en évidence la routine pilote chaude.

Décision : Si les piles convergent vers un module pilote, vous êtes passé de « probable » à « prouvé ».

Task 16: Identify runaway services triggering kernel paths (I/O storm check)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | sort CPU -desc | select -first 10 Name,Id,CPU,WorkingSet64 | ft -Auto"
Name            Id    CPU  WorkingSet64
----            --    ---  ------------
System           4  942.2  287031296
sqlservr      2312  120.4  7423913984
MsMpEng       1880   88.7  514883584
svchost       1020   40.1  221421568

Ce que cela signifie : « System » est en tête, mais des processus utilisateur comme AV ou base de données peuvent générer la charge qui déclenche le surcoût noyau.

Décision : Si ETW montre de fortes E/S fichiers avec un coût de minifilter, ajustez les exclusions ; si des resets stockage existent, concentrez-vous d’abord sur le chemin.

Blague #1 : Le processus « System » est le collègue au travail qui dit toujours « je suis en réunion » — et d’une manière ou d’une autre votre projet échoue quand même.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une fintech moyenne exploitait une flotte de VM Windows Server traitant l’ingestion de messages et le chiffrement. Un lundi, après une fenêtre de changement habituelle du week-end,
l’astreinte a vu le CPU saturé sur plusieurs nœuds. Le Gestionnaire des tâches pointait « System » et « System interrupts ». La théorie réflexe : « Notre service d’ingestion fuit des threads. »

L’équipe a élargi le service, doublé les workers de file, et même ajusté les paramètres GC. Rien n’a amélioré. La flotte est devenue plus instable parce qu’ils ont augmenté le débit vers un goulet noyau.
Pendant ce temps, les clients signalaient des timeouts intermittents ; les dashboards montraient une montée de la latence d’écriture disque.

La mauvaise hypothèse était simple : « Si le CPU est élevé, c’est l’espace utilisateur. » Ils n’ont pas mesuré le temps privilégié. Ils n’ont pas vérifié le taux DPC/interruption.
Ils n’ont pas regardé les logs Système parce que « ils sont toujours bruyants ».

Quand quelqu’un a enfin fait un rapide check des compteurs, le temps privilégié dominait et les interruptions étaient absurdes. Les logs ont montré des resets Storport.
Les traces ETW ont montré des piles CPU passant du temps dans les routines de complétion de stockage — cohérent avec un pilote resetant le chemin à répétition.

Cause racine : une mise à jour de firmware du stockage sur le cluster hôte sous-jacent interagissait mal avec une configuration particulière de HBA virtuel. Revenir au firmware précédent
(ou déplacer les VM vers des hôtes non affectés) a stabilisé l’environnement. Le service d’ingestion était correct ; il criait juste dans un chemin de stockage cassé.

Leçon durable : avant de toucher votre appli, classifiez le CPU. Si c’est du temps noyau, traitez votre application comme un générateur de charge, pas comme un suspect.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une entreprise retail avait un pipeline interne de traitement de fichiers sur des serveurs Windows avec un fort débit réseau. Quelqu’un a proposé d’activer « toutes les fonctionnalités d’offload » sur les NIC pour réduire le CPU hôte.
Le changement a été approuvé parce que ça semblait gratuit.

Au début, le CPU a baissé dans les benchmarks. Puis le trafic de production a frappé : tailles de paquets aléatoires, rafales, mélange TLS/plaintext. En quelques heures,
plusieurs nœuds montraient un « System » CPU élevé, et la latence empirait. Les dashboards réseau montraient des micro-rafales et des pertes périodiques.

Les traces ETW ont clarifié : le temps brûlait dans NDIS et le driver NIC vendeur, dominé par le traitement DPC. La modulation d’interruptions avait été trop agressivement réglée pour le débit,
et un chemin d’offload était bogué avec la forme de trafic du pipeline. Le système n’était pas « plus rapide » ; il oscillait entre des rafales coalescées et des arriérés de DPC.

L’équipe a annulé les changements, puis réintroduit les offloads un par un, en vérifiant avec des compteurs : interrupts/sec, temps DPC, et latence end-to-end.
Ils ont conservé RSS activé et ajusté le nombre de queues, mais ont désactivé l’offload problématique. Le CPU a légèrement augmenté, mais la gigue a fortement diminué — et la gigue était le vrai SLO critique.

Leçon durable : « optimisation CPU » qui ignore la latence de queue est la façon d’obtenir un système rapide qui semble lent. Et basculer dix paramètres NIC à la fois n’est pas une expérience scientifique ; c’est une danse interprétative.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Un SaaS santé exploitait des serveurs applicatifs Windows avec un contrôle strict des changements. Leur équipe SRE maintenait une matrice de drivers et firmwares approuvés : versions pour NIC,
contrôleur de stockage, chipset, plus une procédure documentée de rollback. Ce n’était pas glamour. C’était surtout des tableurs et « non, vous ne pouvez pas mettre à jour ça aujourd’hui. »

Un trimestre, un vendor a poussé un nouveau driver NIC pour résoudre une alerte de sécurité. L’équipe sécurité voulait le déployer de toute urgence.
Ops a accepté — mais seulement après l’avoir stagé sur un canari avec une procédure ETW standard pendant une charge synthétique.

Le canari a immédiatement montré une augmentation mesurable du temps DPC et des interrupts/sec sous un profil de trafic spécifique. Pas catastrophique, mais la tendance était mauvaise.
Ils ont stoppé le déploiement, ouvert un ticket vendor avec preuves ETW, et ont continué sur la version approuvée tout en appliquant des mitigations alternatives.

Deux semaines plus tard, le vendor a fourni une build corrigée. Le canari était propre. Le déploiement a été complété sans incident.
Personne n’a écrit de postmortem héroïque parce que rien n’a cassé. C’est bien là le but.

Leçon durable : des contrôles ennuyeux — matrices de versions, canaris, traces répétables — battent l’adrénaline à chaque fois.

Blague #2 : Si vous ne collectez pas de trace, votre cause racine est « les vibes étaient mauvaises », et la finance n’acceptera absolument pas ça comme justificatif budgétaire.

Stockage et CPU « System » : les suspects habituels (Storport, filtres, files)

Les problèmes de stockage apparaissent de manière disproportionnée comme « System » CPU. Le noyau effectue la gestion des E/S : routines de complétion, retries, timeouts,
gestion des files, vidanges de cache et récupération d’erreurs. Quand la pile de stockage est mécontente, elle peut brûler du CPU tout en livrant une latence pire. Efficace.

Réinitialisations et timeouts Storport : pourquoi ça coûte du CPU

Une réinitialisation Storport (ID d’événement 129 courant) n’est pas juste « un warning ». Cela signifie que Windows a dit à une miniport de stockage : « je ne reçois pas de réponses à temps ; réinitialise le device/chemin. »
Les resets peuvent conduire à des aborts de commandes, requeues, invalidation de cache, événements multipath, et une tempête de complétions. Tout en contexte noyau.

Si vous voyez un schéma comme : pic de latence → event 129/153 → pic CPU System, traitez-le comme corrélé jusqu’à preuve du contraire.

Empilement de filtres : la taxe du chemin chaud que vous n’avez pas budgétée

Les minifilters peuvent être corrects et quand même coûteux. Ajoutez deux ou trois en série — AV, inspection DLP, filtre de snapshot de sauvegarde — et vous pouvez multiplier le coût par I/O.
Sous charge, cela devient CPU noyau et pression DPC, surtout si le filtre fait du travail synchrone ou provoque des lectures metadata supplémentaires.

Profondeur de file et « tiny I/O » : douleur auto-infligée

Certains workloads émettent beaucoup de petites écritures aléatoires et des fsync. Ce n’est pas une faute morale ; c’est le fonctionnement de certaines bases et files de messages.
Mais si le chemin de stockage est réglé pour du streaming, vous pouvez forcer l’OS et le pilote à gérer un taux massif d’IOPS avec un overhead élevé par opération.

La correction peut être un changement d’agrégation côté appli. Ou bien « arrêtez d’utiliser une combinaison contrôleur/driver qui réinitialise sous pression. »
N’assumez pas que c’est votre code tant que vous n’avez pas de piles ETW.

Réseau et CPU « System » : NDIS, offloads, RSS et tempêtes de paquets

Les drivers réseau vivent dans un monde d’interruptions, de DPC et de batching soigné. Quand ça va mal, le CPU passe rapidement en temps noyau.
Si votre pic CPU System coïncide avec des rafales de trafic, des pertes de paquets ou des retransmissions, vous êtes probablement en territoire NDIS.

Schémas classiques

• Taux d’interruptions/sec très élevé avec un cœur faisant la majorité du travail d’interruption : problème d’affinité d’interruption/RSS/config de queues.
• Le temps DPC grimpe quand le débit augmente : le pilote a du mal avec le traitement des réceptions ou le chemin de coalescence/segmentation.
• Après une mise à jour de pilote : le comportement des offloads change ; des défauts apparaissent seulement avec votre mix de trafic.
• Switches virtuels et overlays : vSwitch, encapsulation et agents de sécurité ajoutent des couches qui peuvent amplifier l’overhead.

Offloads : traitez-les comme des feature flags, pas des commandements

Les offloads peuvent être bénéfiques, mais « activés partout » n’est pas une stratégie. L’approche correcte :
activez un ensemble minimal, mesurez sous une charge représentative, puis étendez prudemment. Si un réglage réduit le CPU mais augmente la latence de queue, ce n’est pas un gain.

RSS et mise en file : répartir le travail ou payer la taxe du cœur unique

Les NIC modernes peuvent répartir le traitement des réceptions sur plusieurs cœurs via RSS. Mais les valeurs par défaut ne sont pas toujours sensées, surtout en VM ou quand d’autres fonctionnalités (VMQ, SR-IOV)
sont impliquées. Si vous voyez un cœur saturé par des interruptions, RSS/affinité est un suspect immédiat.

Virtualisation et hyperviseurs : quand l’hôte est innocent et quand même coupable

Dans les environnements virtualisés, « pilote » peut signifier :

• Drivers invités (pilotes NIC/stockage virtuels)
• Drivers hôtes (NIC/HBA physiques) provoquant une latence que le guest voit comme des resets/timeouts
• Couches de switch virtuel/filtre dans la pile hôte
• Ordonnancement CPU et particularités de virtualisation des interruptions

Une VM invitée montrant un System CPU élevé dû à des resets stockage peut être causée par des files de stockage côté hôte ou des problèmes de fabric.
Votre preuve commence toujours dans l’invité (ETW, journaux d’événements), mais la remédiation peut nécessiter l’équipe plateforme.

Conseil pratique : si vous pouvez reproduire le problème en migrant la VM en direct vers un autre hôte, c’est une preuve puissante.
Ce n’est pas une causalité parfaite, mais c’est un signal directionnel fort — surtout couplé aux traces.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: « System » CPU élevé, mais vous ne regardez que le Gestionnaire des tâches

Cause racine : Pas d’attribution. « System » est un seau, pas un diagnostic.

Fix : Capturez ETW (WPR/WPA) et inspectez les piles CPU échantillonnées ; confirmez le temps DPC/ISR et identifiez les modules pilotes.

2) Symptom: Un cœur saturé, les autres au repos ; RDP est affreux

Cause racine : Problèmes de routage/affinité d’interruptions, RSS désactivé/mis en erreur, ou périphérique bloqué sur une seule queue.

Fix : Vérifiez l’état RSS et le nombre de queues ; mettez à jour pilote/firmware NIC ; ajustez les queues RSS ; validez la distribution des interruptions ensuite.

3) Symptom: Pics System CPU lors de sauvegardes ou scans AV

Cause racine : Les minifilters du système de fichiers font du travail synchrone intensif, scannent des datasets chauds ou snapshotent avec des chemins metadata coûteux.

Fix : Revoyez la sortie de fltmc ; ajustez les exclusions ; planifiez les scans ; supprimez les agents redondants ; testez sur un canari.

4) Symptom: CPU System élevé plus Event ID 129 (storport reset)

Cause racine : Timeouts/resets stockage dus à pilote/firmware/controlleur, instabilité de fabric, ou inadéquation de profondeur de file.

Fix : Corrélez avec les compteurs de latence disque ; mettez à jour/rollback le miniport driver ; vérifiez le firmware ; validez le câblage/fabric ; impliquez l’équipe stockage avec preuves ETW.

5) Symptom: Interrupts/sec élevé après activation d’offloads

Cause racine : Bug ou incompatibilité dans le chemin d’offload ; modulation d’interruptions trop agressive/trop timide ; interactions RSC/LSO.

Fix : Revenez en arrière et réactivez les options une par une ; mesurez interrupts/sec, temps DPC et latence de queue ; conservez une baseline connue bonne.

6) Symptom: CPU noyau élevé seulement sur du matériel « neuf »

Cause racine : Paramètres BIOS/firmware par défaut (états d’alimentation, PCIe ASPM), driver chipset, ou driver non validé pour la plate-forme.

Fix : Alignez les réglages BIOS sur les recommandations vendor ; mettez à jour firmware et drivers chipset ; vérifiez les warnings WHEA ; testez avec un plan d’alimentation cohérent.

7) Symptom: « System » CPU élevé durant de fortes petites écritures, surtout avec chiffrement

Cause racine : Overhead crypto/filtre et patterns de flush amplifient le coût par I/O ; peut exposer la sensibilité à la latence du stockage.

Fix : Mesurez la distribution des tailles d’I/O via ETW ; regroupez les écritures quand c’est sûr ; validez les versions du pilote de chiffrement ; envisagez l’accélération matérielle et les modes supportés.

Listes de contrôle / plan pas-à-pas

Checklist A: Triage en 10 minutes (safe pour la production)

1. Exécutez des compteurs pour CPU privilégié vs utilisateur ; confirmez la dominance du temps noyau.
2. Vérifiez interrupts/sec et temps DPC/interrupt ; notez si un cœur est déséquilibré.
3. Récupérez la dernière heure de warnings/errors du journal Système ; cherchez storport/disk/ndis/whea.
4. Listez les drivers non-Microsoft et les composants récemment modifiés (NIC, stockage, filtres).
5. Décidez si cela ressemble à du stockage ou à du réseau en vous basant sur compteurs + logs.

Checklist B: Capture de preuves (pour en finir avec les discussions)

1. Démarrez une trace WPR (CPU + DiskIO + Network) en filemode.
2. Reproduisez ou attendez le pic (60–120 secondes suffisent souvent).
3. Arrêtez la trace et sauvegardez l’ETL avec timestamp dans le nom de fichier.
4. Capturez un snapshot de compteurs concurrent pour latence/queue disque et interrupts/sec.
5. Archivez le segment du journal Système pour la même fenêtre.

Checklist C: Expériences d’isolation (choisissez une, ne pas tout balancer)

1. Si c’est d’origine réseau : basculez un offload ; mesurez ; restaurez si pire.
2. Si c’est stockage : testez un rollback de driver sur un nœud ; mesurez ; vérifiez la fréquence des event 129.
3. Si c’est filtre : désactivez/désinstallez un filtre non critique sur un canari ; mesurez latence I/O et CPU noyau.
4. Si virtualisé : migrez la charge/VM vers un autre hôte ; comparez traces et logs.
5. Si matériel : changez de port/câble NIC, mettez à jour le firmware, vérifiez WHEA.

Checklist D: Contrôle des changements qui ne ruinent pas votre trimestre

1. Maintenez une matrice de drivers/firmware approuvés par modèle de plateforme.
2. Canarisez chaque mise à jour de driver sous charge représentative ; capturez ETW avant/après.
3. Documentez les étapes de rollback et gardez les installateurs localement pour fenêtres d’urgence.
4. Traquez les réglages offload/RSS comme configuration, pas comme « ce que dit l’UI aujourd’hui ».

FAQ

1) Pourquoi « System » obtient-il le CPU au lieu que le pilote apparaisse comme processus ?

Les pilotes noyau ne s’exécutent pas comme des processus en mode utilisateur avec leurs propres PIDs. Leur travail s’exécute en contexte noyau, souvent imputé au processus System.
Les traces ETW sont le moyen d’attribuer ce travail à un module spécifique.

2) « System interrupts » élevé est-ce toujours du matériel ?

C’est du matériel et du logiciel. Le matériel déclenche les interruptions, mais les pilotes décident comment elles sont gérées, agrégées et différées.
Des pilotes bogués, des paramètres offload erronés ou des problèmes de firmware peuvent tous produire des tempêtes d’interruptions.

3) Quelle est la différence entre ISR et DPC, et pourquoi s’en soucier ?

ISR est la routine de service d’interruption immédiate — elle doit être rapide. DPC est le travail différé planifié pour s’exécuter peu après à haute priorité.
Si le temps DPC est élevé, votre système peut sembler lent car le travail noyau à haute priorité évince les threads normaux.

4) L’antivirus peut-il vraiment provoquer un pic de CPU « System » ?

Oui. L’AV utilise typiquement des minifilters du système de fichiers. Sous un fort churn de fichiers (serveurs de build, applis générant beaucoup de logs, fenêtres de sauvegarde),
le filtre peut ajouter un coût par I/O et faire monter le CPU noyau, parfois de manière dramatique.

5) Si je mets à jour les drivers, « latest » est-il toujours meilleur ?

Non. « Latest » est un pari à moins d’être validé sur votre matériel, build OS et workload. Préférez les versions vendor-supportées et canarisez avec des preuves ETW avant un large déploiement.

6) Combien de temps dois-je capturer une trace ETW ?

Assez longtemps pour inclure le pic et un peu de baseline normale — souvent 60–180 secondes suffisent pour l’attribution CPU.
Si les pics sont rares, utilisez le buffering circulaire et capturez autour de la fenêtre d’incident.

7) Je vois des resets storport (Event 129). Est-ce forcément l’array de stockage ?

Pas forcément. Cela peut être l’array, la fabric, le firmware HBA, le pilote, la profondeur de file, ou même une starvation CPU hôte causant des timeouts.
Correliez avec la latence disque, les retries (Disk 153) et les piles ETW stockage pour restreindre le diagnostic.

8) Si ETW montre principalement ntoskrnl.exe plutôt qu’un driver vendeur ?

Cela peut arriver quand les symboles/piles ne sont pas bien résolus, ou quand le chemin chaud est du code noyau générique appelé par plusieurs pilotes.
Assurez-vous que le stack walking est activé, incluez les événements loader, et recoupez avec les providers DPC/ISR. Vous trouverez souvent le pilote déclencheur par le contexte de la pile.

9) Une appli en mode utilisateur peut-elle causer un fort CPU « System » même si le pilote est OK ?

Oui — en générant des workloads pathologiques : taux IOPS très élevés de petites opérations, patterns socket abusifs, churn constant d’ouvertures/fermetures.
ETW vous aide à distinguer « bug de pilote » de « travail noyau légitime causé par la charge ».

10) Dois-je utiliser Driver Verifier pour attraper ça ?

Driver Verifier est puissant mais risqué en production ; il peut provoquer des crashes pour exposer des défauts de pilotes.
Utilisez-le en staging ou sur un nœud sacrificiel avec un plan de rollback, pas sur votre base de données critique à midi.

Conclusion : prochaines étapes pratiques

Quand « System » bouffe du CPU, traitez-le comme un incident noyau, pas comme une séance d’optimisation applicative. Votre chemin le plus rapide vers la vérité est :
compteurs pour classifier, logs pour corréler, ETW pour attribuer, et un changement contrôlé pour prouver la causalité.

1. Exécutez les compteurs privileged/user CPU et interrupts/DPC pour confirmer la classe du problème.
2. Récupérez les journaux Système pour storport/disk/ndis/whea dans la même fenêtre.
3. Capturez une courte trace WPR et inspectez les piles CPU échantillonnées dans WPA.
4. Identifiez le pilote/module et choisissez la mitigation réversible la plus petite (rollback/toggle/offload/test filtre).
5. Après le correctif, recapturez les mêmes compteurs/trace pour prouver l’amélioration et prévenir les régressions.

Si vous ne faites qu’une chose : obtenez la trace. Elle transforme « System est élevé » d’une plainte en une cause racine sur laquelle agir — ou à fournir au vendor sans honte.