Seu Windows Server 2016 apresenta picos de CPU no processo System (NT KERNEL & SYSTEM)? Este guia prático explica como identificar o driver/serviço em modo kernel culpado, registrar as métricas certas, analisar dumps e aplicar correções seguras e permanentes.
Visão geral do problema
Em servidores Windows, o processo System (NT KERNEL & SYSTEM) concentra a execução de drivers e rotinas do kernel (interrupções e DPCs). Quando há picos de CPU atribuídos a “System”, quase sempre o gatilho é um driver defeituoso/desatualizado (rede, armazenamento, vídeo), um filtro de segurança (antivírus/EDR/backup) ou configurações de energia/hypervisor que amplificam interrupções.
O que está por trás de “System”: interrupções, DPCs e drivers
- Interrupções (ISR): sinais de hardware que o kernel precisa atender imediatamente (ex.: NIC, controladora de disco). Valor alto de % Interrupt Time indica pressão aqui.
- DPCs (Deferred Procedure Calls): trabalho adiado do ISR para ser concluído em menor prioridade. Valor alto de % DPC Time e DPCs Queued/sec costuma apontar para drivers de rede/armazenamento.
- Modo privilegiado: quando % Privileged Time cresce junto com DPC/ISR, o foco é kernel/driver, não um processo de usuário específico.
Resumo executivo: como resolver (roteiro confiável)
- Atualize drivers e firmware (NIC, HBA/RAID, vídeo em servidores com GUI) e aplique as Cumulative Updates do Windows Server 2016.
- Meça com PerfMon: % Privileged Time, % DPC Time, % Interrupt Time, Interrupts/sec, DPCs Queued/sec.
- Correlacione com Process Explorer/Resource Monitor para ver pilhas de threads (módulos como
ndis.sys,tcpip.sys,storport.sys,fltmgr.sys). - Capture um traço (WPR/WPA) ou kernel dump e confirme o driver mais quente.
- Corrija: atualize/substitua o driver, ajuste offloads (VMQ/RSS/RSC), refine políticas de antivírus/backup, reconfigure energia/BIOS/hypervisor.
- Valide com um baseline de PerfMon e monitore por alguns dias.
Drivers: por que começar por eles
Drivers de rede e armazenamento são os líderes em causar picos de kernel. Em ambientes com interface gráfica, drivers de vídeo também podem gerar DPCs. Antes de fazer qualquer ajuste fino, inventarie e atualize:
# Listar drivers instalados (versão e data)
Get-CimInstance Win32_PnPSignedDriver |
Select-Object DeviceName, DriverVersion, DriverDate | Sort-Object DeviceName
Opcional: listar apenas drivers de rede e armazenamento
Get-CimInstance Win32\_PnPSignedDriver |
Where-Object { $\_.DeviceName -match "Ethernet|Network|Storage|SAS|RAID|NVMe" } |
Select DeviceName, DriverVersion, DriverDate, Manufacturer Obtenha versões validadas junto ao fabricante do servidor/NIC/HBA/RAID e sincronize com sua política de Windows Update/WSUS.
Monitoramento com PerfMon: o que coletar e como interpretar
Crie um Data Collector Set para capturar os contadores abaixo e correlacionar horário do pico com serviços e drivers. Use amostragem de 5s por pelo menos 30–60 minutos pós-reinicio ou durante a janela do problema.
| Contador PerfMon | O que indica | Faixa de atenção |
|---|---|---|
| Processor(_Total)\% Privileged Time | Tempo de CPU em modo kernel | > 30% sustentado ou picos recorrentes acima de 60% |
| Processor(_Total)\% DPC Time | Tempo em DPCs (drivers) | > 10–20% sustentado sugere driver com DPC excessivo |
| Processor(_Total)\% Interrupt Time | Tempo atendendo interrupções de hardware | Picos acima de 5–10% com frequência merecem atenção |
| Processor Information(_Total)\Interrupts/sec | Taxa de interrupções | Aumento grande vs. baseline do hardware/ workload |
| Processor Information(_Total)\DPCs Queued/sec | DPCs enfileirados por segundo | Milhares/s de forma persistente apontam para NIC/armazenamento |
| System\Processor Queue Length | Threads aguardando CPU | > 2 por CPU lógico por longos períodos indica saturação |
| Context Switches/sec | Trocas de contexto | Explosões fora do padrão podem acompanhar DPC/ISR |
Criação rápida via linha de comando (salva em C:\PerfLogs\CPU-Kernel):
logman create counter "CPU-Kernel" ^
-f bincirc -max 200 ^
-c "\Processor(_Total)\% Privileged Time" ^
"\Processor(_Total)\% DPC Time" ^
"\Processor(_Total)\% Interrupt Time" ^
"\Processor Information(_Total)\Interrupts/sec" ^
"\Processor Information(_Total)\DPCs Queued/sec" ^
"\System\Processor Queue Length" ^
"\System\Context Switches/sec" ^
-si 00:00:05 -o "C:\PerfLogs\CPU-Kernel\CPU-Kernel.blg"
logman start "CPU-Kernel"
...reproduza o pico...
logman stop "CPU-Kernel" Isolando gatilhos de modo usuário
Embora o consumo apareça em “System”, processos de modo usuário podem provocar chamadas de kernel (por filtros de arquivo/rede), como antivírus, EDR, backup e agentes de rede. Use:
- Process Explorer: clique com o botão direito em System → Properties → Threads, ordene por CPU. Repare em Start Address e Module (ex.:
ndis.sys,tcpip.sys,storport.sys,fltmgr.sys, DLLs de antivírus/backup). - Resource Monitor (resmon.exe): guias CPU/Disco/Rede para ver processos que mais acionam I/O e possíveis correlações de horário.
Análise profunda: WPR/WPA e WinDbg
Para confirmar o driver, prefira um traço de CPU com Windows Performance Recorder (WPR) e análise no Windows Performance Analyzer (WPA):
- No WPR, habilite CPU Usage e Interrupt Activity (DPC/ISR), inicie a captura no modo de produção (File mode).
- Reproduza o pico por alguns minutos e pare a coleta para gerar o
.etl. - No WPA, abra CPU Usage (Sampled) e DPC/ISR Usage by Module. Classifique por Module e Inclusive CPU; módulos de topo (ex.:
ndis.sys,storport.sys, minifiltros de antivírus) são os candidatos.
Se optar por análise de dump:
- Ative kernel memory dump em Startup and Recovery e gere durante o pico (cuidado com janelas de manutenção).
- No WinDbg, use comandos como
!analyze -v,!dpc,!interruptse inspeção de pilhas para encontrar threads quentes e drivers associados.
Atualizações de sistema e firmware que fazem diferença
- Windows Update: aplique as Cumulative Updates recentes (trazem correções no kernel, networking e storport).
- Firmware/BIOS/UEFI: atualize BIOS/UEFI, controladoras RAID/HBA e NIC (incluindo microcódigo/EEPROM quando aplicável).
- Hypervisor/VM Tools: mantenha as ferramentas de integração atualizadas caso o servidor seja uma VM.
Rede: VMQ, RSS, RSC e offloads — teste controlado
Muitos surtos de DPC/ISR vêm da pilha de rede. Faça ajustes temporários para isolar causa (e reverta se não houver efeito):
# Fotografar estado atual
Get-NetAdapter | Select Name, DriverVersion, DriverDate, VmqEnabled, RssEnabled
Desabilitar para teste (um adaptador por vez)
Set-NetAdapterVmq -Name "Ethernet" -Enabled \$false
Set-NetAdapterRss -Name "Ethernet" -Enabled \$false
Disable-NetAdapterRsc -Name "Ethernet"
(Opcional) Offload de envio em massa
Disable-NetAdapterLso -Name "Ethernet" -IPv4
Disable-NetAdapterLso -Name "Ethernet" -IPv6
Se o pico cair após desabilitar uma dessas funções, planeje atualizar o driver/firmware e reativar os recursos seletivamente. Evite deixar essas otimizações permanentemente desligadas sem motivo justificado.
Armazenamento: storport, NVMe, drivers e eventos
- Verifique o Visualizador de Eventos → Sistema por avisos/erros de storport, disk, iaStor, NVMe (ex.: eventos 129/153) correlacionados ao horário do pico.
- Atualize miniport storport/HBA, firmwares de SSDs/NVMe e drivers da controladora RAID.
- Em ambientes com multipath, valide versão e policy do MPIO.
Energia, BIOS e virtualização
Estados de energia agressivos (C-States) e core parking podem aumentar latência de DPC/ISR. Teste um plano de energia mais estável:
# Ativar "Equilibrado" (pode reduzir picos em alguns cenários)
powercfg /setactive SCHEME_BALANCED
Alternativamente, listar e ativar "Alto desempenho"
powercfg /l
Copie o GUID do plano "Alto desempenho" listado e ative:
powercfg /setactive \ Em BIOS/UEFI, evite C-States extremamente profundos em servidores de baixa latência. Em VMs, avalie overcommit de CPU e métricas de prontidão da CPU no hypervisor. Em Hyper-V, acompanhe contadores de Hyper-V Hypervisor para correlacionar uso.
Segurança e backup: filtros que acionam kernel
Antivírus/EDR e agentes de backup instalam file filter drivers e network filters que podem elevar DPC/ISR. Boas práticas:
- Atualize o motor e as definições.
- Crie exclusões adequadas (pastas de banco de dados, logs, pastas do próprio antivírus e do backup).
- Teste desativar temporariamente módulos de inspeção profunda (SSL/TLS, network filtering) em janela controlada.
Passos rápidos de mitigação enquanto investiga
- Plano de energia: trocar para “Equilibrado” ou “Alto desempenho”, conforme o perfil do servidor e testes.
- Conter processos ruidosos: ajuste affinity temporária de serviços de terceiros para reduzir impacto em toda a máquina.
# Exemplo: fixar um processo nos 4 primeiros CPUs lógicos (0x000F)
$proc = Get-Process -Name "MeuServico"
$proc.ProcessorAffinity = 0x000F # efeito temporário até o próximo restart do processo
Matriz de diagnóstico: do sintoma à causa provável
| Sintoma visível | Contadores afetados | Causa provável | O que fazer |
|---|---|---|---|
| % Privileged alto + % DPC alto | DPCs Queued/sec, CPU Sampling aponta ndis.sys | Driver de rede/VMQ/RSS | Atualizar NIC/firmware; testar VMQ/RSS/RSC; revisar offloads |
| % Privileged alto + % Interrupt alto | Interrupts/sec elevado | Interrupções de hardware (NIC/HBA) | Atualizar drivers/firmware; ajustar moderação de interrupções |
| Picos durante backup/scan | DPC/ISR, fltmgr.sys em pilhas | Filtros de antivírus/backup | Atualizar produto; criar exclusões; escalonar janelas |
| Picos após patch/BIOS | % Privileged elevado sem I/O aparente | Interação de microcódigo/energia | Rever plano de energia/BIOS; validar hotfixes recentes |
| VM sob carga leve com picos | Fila de CPU do hypervisor | Overcommit CPU ou co-scheduling | Ajustar vCPUs alocadas; reduzir overcommit; atualizar ferramentas |
Checklist de atualização de drivers e firmware
- NIC (incluindo teaming, VMQ, RSS, SR-IOV): driver e firmware.
- Controladoras de armazenamento (RAID/HBA/NVMe): driver, firmware e utilitários.
- Chipset/BIOS/UEFI do fabricante do servidor.
- Vídeo (apenas se houver GUI): driver homologado para Windows Server 2016.
- Ferramentas de integração do hypervisor (se VM).
Revisão de tarefas agendadas e serviços
Como os picos são “em momentos aleatórios”, confira se há tarefas que rodam periodicamente e acionam drivers:
# Mapear tarefas agendadas e horários
schtasks /query /fo LIST /v | more
Serviços que mais consomem CPU ao longo do tempo (amostra)
Get-Process | Sort-Object CPU -Descending | Select -First 20 Name, CPU Boas práticas de validação após a correção
- Repita a coleta do PerfMon com os mesmos contadores e período.
- Compare baseline antes/depois (gráficos e valores médios/p95).
- Documente versões aplicadas (driver/firmware) e mudanças em energia/hypervisor.
- Mantenha um ciclo mensal de verificação de drivers em servidores críticos.
Modelos de comandos úteis (referência rápida)
# Power plan
powercfg /l
powercfg /setactive SCHEME_BALANCED
ou: powercfg /setactive <GUID-AltoDesempenho>
PerfMon via logman (criar/iniciar/parar)
logman create counter "CPU-Kernel" -si 00:00:05 -o C:\PerfLogs\CPU-Kernel\CPU-Kernel.blg -f bincirc -max 200 ^
-c "\Processor(\Total)% Privileged Time" "\Processor(\Total)% DPC Time" "\Processor(\_Total)% Interrupt Time" ^
"\Processor Information(\Total)\Interrupts/sec" "\Processor Information(\Total)\DPCs Queued/sec" "\System\Processor Queue Length"
logman start "CPU-Kernel"
logman stop "CPU-Kernel"
Rede: status e toggles de teste
Get-NetAdapter | ft Name, DriverVersion, VmqEnabled, RssEnabled
Set-NetAdapterVmq -Name "Ethernet" -Enabled \$false
Set-NetAdapterRss -Name "Ethernet" -Enabled \$false
Disable-NetAdapterRsc -Name "Ethernet"
Drivers instalados
Get-CimInstance Win32\_PnPSignedDriver | Select DeviceName, DriverVersion, DriverDate | Sort DeviceName Conclusão
Picos de CPU em NT KERNEL & SYSTEM quase sempre refletem interrupções/DPCs excessivos provocados por drivers ou filtros em modo kernel. O caminho eficaz é: atualizar drivers e firmware → monitorar com PerfMon → isolar com Process Explorer/Resource Monitor → confirmar com WPR/WPA ou WinDbg → corrigir e validar. Com essa metodologia disciplinada, você normaliza o uso de CPU no Windows Server 2016 e reduz drasticamente a chance de reincidência.
Apêndice: passos de mitigação imediata (resumo)
- Ativar plano de energia “Equilibrado” ou “Alto desempenho” conforme o perfil do servidor e resultado do teste.
- Desabilitar temporariamente VMQ/RSS/RSC para isolar problemas de NIC; se confirmar, atualizar driver/firmware e reconfigurar.
- Ajustar políticas de antivírus/EDR e backup (exclusões e janelas).
- Reduzir overcommit de CPU em VMs e manter ferramentas de integração atualizadas.
- Coletar PerfMon/WPR como evidência para tomada de decisão e auditoria.