¿Proceso ‘System’ con CPU alta? A menudo es un controlador — Cómo demostrarlo

Qué es realmente el proceso “System” (y qué no es)

El proceso System (PID 4 en la mayoría de sistemas) no es “un programa” como tu servicio. Es un contenedor para trabajo en modo kernel:
hilos que se ejecutan en el kernel de Windows y controladores en modo kernel. Cuando consume mucha CPU, algo en modo kernel está quemando ciclos—a menudo gestionando interrupciones,
ejecutando DPCs (Deferred Procedure Calls) o procesando rutas de E/S.

Unas aclaraciones que evitan decisiones erróneas tempranas:

• CPU alta en System no es prueba de malware. El malware puede causarlo, pero “System” suele ser más frecuentemente tu controlador de almacenamiento o NIC teniendo un mal día.
• CPU alta en System no es un bug de aplicación—hasta que lo es. Las aplicaciones pueden activar rutas del kernel (por ejemplo, tormentas de E/S, escrituras pequeñas, thrash de mmap) que exponen un defecto o mala configuración del controlador.
• “System interrupts” en el Administrador de tareas es un síntoma, no un proceso. Es tiempo dedicado a atender interrupciones de hardware, que sigue siendo normalmente una historia de “controlador o hardware”.
• Deshabilitar servicios al azar rara vez ayuda. El tiempo del kernel no se preocupa por tu indexador de Windows Search cuando la cola de DPC se está derritiendo.

El objetivo no es “reducir la CPU de System” por estética. El objetivo es identificar qué componente del kernel consume tiempo y por qué,
y luego escoger la acción correctiva de menor riesgo: actualizar/volver a la versión anterior del controlador, corregir firmware, ajustar offloads, eliminar un controlador filtro, ajustar la profundidad de cola,
o reemplazar un dispositivo defectuoso.

Hechos interesantes y un poco de historia (porque esto no empezó ayer)

1. “System” como proceso visible viene de la línea NT—un diseño que enfatizó la separación clara entre modo usuario y modo kernel, con modelos de controlador estables.
2. Los DPC existen porque no puedes hacer todo en tiempo de interrupción. Los manejadores de interrupción deben ser rápidos; el trabajo pesado se difiere a DPC, que aún se ejecuta con prioridad elevada.
3. ETW (Event Tracing for Windows) existe desde Windows 2000 y sigue siendo la forma más fiable de demostrar a dónde fue el tiempo del kernel.
4. Storport reemplazó controladores de puerto de almacenamiento antiguos por rendimiento y escalabilidad, pero cuando se comporta mal, lo hace de forma ruidosa: CPU alta, resets y picos de latencia.
5. Los offloads de NDIS han sido don de productividad y maldición para depuración: checksum offload, LSO, RSC, RSS. Genial cuando funcionan; dramático cuando son defectuosos.
6. Los controladores filtro están en todas partes: antivirus, DLP, agentes de backup, cifrado, snapshotting, monitorización. Se sitúan en rutas calientes y pueden convertir “bien” en “misterioso”.
7. El planificador de Windows y el enrutamiento de interrupciones cambiaron sustancialmente entre versiones (y generaciones de hardware). Un controlador que “funciona en 2016” puede comportarse distinto en 2022 con núcleos modernos y NUMA.
8. La moderación de interrupciones se volvió general porque la red a línea completa ahogaría las CPU. Mal implementada, crea latencia; excesiva, genera interrupciones por servicio.
9. “CPU alta” a veces oculta un problema de energía/firmware. C-states, microcode de BIOS y firmware defectuoso pueden manifestarse como comportamientos extraños de interrupciones o tormentas de temporizadores.

Un modelo mental útil: la CPU del kernel rara vez es “aleatoria”. Casi siempre es un bucle, una cola, una tormenta o un reintento.
Tu trabajo es encontrar la cola.

Guion rápido de diagnóstico (primeras/segundas/terceras comprobaciones)

Primero: clasifica el consumo de CPU (usuario vs kernel vs interrupciones)

• ¿Está alta la CPU globalmente, o solo un núcleo al máximo?
• ¿El tiempo está en Tiempo de kernel (privilegiado) o en Tiempo de usuario?
• ¿Muestra el Administrador de tareas alto System y/o altas System interrupts?

Si domina el tiempo de kernel, dejas de mirar flame graphs de aplicaciones y empiezas a recoger evidencia del kernel.

Segundo: decide si es E/S, red o “hardware raro”

• Sospechas de almacenamiento: alta latencia de disco, longitud de cola alta, advertencias de Storport, resets, controladores filtro, cambios en multipath.
• Sospechas de red: pérdidas, retransmisiones, interrupciones altas en la NIC, toggles de offload, advertencias de NDIS.
• Sospechas de hardware raro: dispositivos USB, audio, GPU, chipset, temporizadores de gestión de energía.

Tercero: captura pruebas que puedas mostrar a un proveedor o junta de cambios

• Trazas ETW (WPR/WPA) centradas en uso de CPU por controlador, ISR, DPC.
• Contadores de rendimiento para tasa de interrupciones/DPC, latencia de disco/cola, paquetes de red/interrupciones.
• Registros de eventos: canal System para Storport, disco, NVMe, NDIS, errores de hardware WHEA.

Si no puedes producir una línea de tiempo que correlacione “pico de CPU” con “rutina de controlador dominando DPC/ISR” o “tormenta de resets de storport”, no tienes prueba—tienes sensaciones.

Cómo demostrar que es un controlador: la cadena de evidencia

“Es un controlador” es una afirmación. Para convertirla en prueba, quieres una cadena de evidencia que aguante en una sala de incidentes:
síntomas → mediciones → atribución → cambio controlado → resultado.

1) Síntomas: lo que notan los usuarios mapea a modos de fallo del kernel

• Retrasos en RDP, latencia del teclado: a menudo presión de interrupciones/DPC que priva a los hilos normales.
• Picos de latencia en almacenamiento: Storport, controlador NVMe, firmware del HBA, flapping de multipath, controladores filtro.
• Jitter en red: interrupciones de NIC, problemas de offload, mala configuración de RSS, bugs en colas del controlador.
• Saltos de audio (en escritorios): síntomas clásicos de latencia DPC.

2) Mediciones: confirma que el tiempo del kernel es realmente el problema

Usa contadores y trazas. No confíes en una sola captura de pantalla del Administrador de tareas como si fuera un diagnóstico médico.

3) Atribución: identifica el componente del kernel que realiza el trabajo

Aquí es donde ETW gana. Quieres ver muestreos de stacks de CPU que caigan en un módulo de controlador (p. ej., storport.sys, stornvme.sys, ndis.sys,
controlador NIC del proveedor, controlador filtro de cifrado, minifilter de antivirus).

4) Cambio controlado: aisla sin romper producción

Escoge cambios reversibles y seguros: revertir un controlador, desactivar una característica de offload, deshabilitar un controlador filtro en una ventana de mantenimiento,
cambiar el puerto de la NIC, mover una VM a otro host, o cambiar la profundidad de cola. Luego vuelve a medir.

5) Resultado: muestra antes/después con las mismas herramientas

Si la tasa de DPC baja, la CPU del kernel baja y la latencia se normaliza tras tu cambio, tienes causalidad. Si no, sigue investigando.

Idea parafraseada de Werner Vogels (reliability/operations): Todo falla eventualmente; los sistemas resilientes asumen fallos y se recuperan automáticamente.
En este contexto: asume que los controladores pueden fallar y construye la capacidad de prueba repetible y reversión en tu memoria operativa.

Tareas prácticas: comandos, salidas, significado y decisiones (12+)

Estas tareas están deliberadamente orientadas a lo que puedes hacer en un Windows Server real sin instalar herramientas misteriosas. Algunas usan utilidades integradas,
otras usan componentes de Windows Performance Toolkit que a menudo ya están presentes en imágenes empresariales. Ejecútalas como Administrador salvo que se indique lo contrario.

Task 1: Confirmar rápidamente CPU de kernel vs usuario (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"

Qué significa: El tiempo privilegiado eclipsa el tiempo de usuario. Eso es ejecución en kernel—controladores, rutinas del kernel, interrupciones.

Decisión: Deja de optimizar aplicaciones. Empieza a atribuir la CPU del kernel (DPC/ISR, controladores, rutas de I/O).

Task 2: Comprobar tasa de interrupciones y DPC (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"

Qué significa: Interrupts/sec es enorme; el tiempo de DPC está elevado. Eso es territorio clásico de “tormenta de interrupciones/DPC”.

Decisión: Identifica qué dispositivo/controlador genera interrupciones (a menudo NIC o almacenamiento). Pasa a ETW y correlación por dispositivo.

Task 3: Detectar sesgo por núcleo (un núcleo pegado por interrupciones)

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"

Qué significa: Un CPU está haciendo trabajo de interrupciones. Esto suele apuntar a problemas de afinidad/ enrutamiento de interrupciones, mala configuración de RSS, o un dispositivo atascado en un núcleo.

Decisión: Inspecciona RSS de la NIC, moderación de interrupciones y controladores; considera también BIOS/firmware y controladores de chipset.

Task 4: Encontrar eventos ruidosos en el registro System (almacenamiento/red/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.

Qué significa: Resets de Storport y reintentos de disco se correlacionan fuertemente con picos de CPU del kernel y latencia. Las tormentas de resets son costosas.

Decisión: Trátalo como un problema de ruta de almacenamiento hasta demostrar lo contrario: controlador/firmware, HBA, multipath, SAN, cableado, firmware NVMe, controladores filtro.

Task 5: Comprobar errores de hardware WHEA (saboteadores silenciosos)

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.

Qué significa: Los errores corregidos aún cuestan tiempo y pueden desestabilizar controladores (especialmente almacenamiento y dispositivos PCIe).

Decisión: Extrae versiones de firmware, comprueba salud de PCIe/NVMe y no “ignores” errores corregidos en una flota.

Task 6: Listar controladores y versiones (lista rápida de sospechosos)

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

Qué significa: Esto solo muestra componentes principales de Microsoft. También quieres los controladores del proveedor (NIC/HBA) y controladores filtro (AV, backup).

Decisión: Enumera controladores no Microsoft a continuación; si un controlador del proveedor se actualizó recientemente, tienes un sospechoso principal.

Task 7: Enumerar controladores no Microsoft (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

Qué significa: Ahora tienes nombres y versiones de controladores de proveedor. Contrástalos con tu línea temporal de cambios.

Decisión: Si el momento coincide con un despliegue, prueba revertir en un nodo (o mover la carga) y vuelve a medir.

Task 8: Comprobar controladores filtro en la pila de almacenamiento (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

Qué significa: Los minifiltros interceptan I/O de archivos. Si la CPU del kernel está alta durante actividad intensa de disco, los filtros son culpables comunes.

Decisión: Si ves filtros no esenciales en servidores (especialmente agentes), planea una desactivación/desinstalación controlada en un host.

Task 9: Ver en qué volúmenes e instancias se adjuntan los filtros (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

Qué significa: Si el volumen caliente es el mismo con apilamiento intenso de filtros, tienes una amplificación plausible de la ruta caliente.

Decisión: Decide si el valor empresarial de cada filtro justifica el riesgo de rendimiento y fiabilidad; si es así, afina/excluye rutas.

Task 10: Capturar una traza ETW con WPR para CPU + DPC/ISR

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

Qué significa: Estás grabando eventos del kernel. Reproduce el problema durante 30–120 segundos, luego detén.

Decisión: Si puedes reproducirlo, puedes demostrarlo. Si no, graba más tiempo y correlaciona con marcas temporales de las quejas.

Task 11: Detener la traza y guardarla (WPR)

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

Qué significa: Ahora tienes un archivo ETL que puedes abrir en Windows Performance Analyzer (WPA) para ver uso de CPU por stack y módulo.

Decisión: Abre el ETL en WPA y revisa CPU Usage (Sampled), DPC/ISR y call stacks. Si la pila caliente apunta a un controlador, tienes atribución.

Task 12: Instantánea rápida de contadores para latencia de disco y cola

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"

Qué significa: Las escrituras son lentas y las colas están profundas. La CPU del kernel puede subir debido a reintentos, resets y tormentas de completado de E/S.

Decisión: Confirma con eventos de Storport/Disk y ETW Disk I/O; investiga controlador/firmware de almacenamiento y apilamiento de filtros.

Task 13: Comprobar errores de red y estado de offloads (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

Qué significa: Los ajustes RSC/RSS importan. Si ves interrupciones altas y CPU alta, offloads defectuosos o configuraciones incompatibles son sospechosos.

Decisión: Si ETW apunta a NDIS/controlador NIC, prueba desactivar un offload a la vez en un host y vuelve a medir.

Task 14: Verificar colas RSS y asignación de CPU (PowerShell)

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

Qué significa: Si una NIC de 25/40/100Gb corre con 1–2 colas, puedes sufrir dolor por interrupciones en un solo núcleo.

Decisión: Aumenta colas (dentro de la guía del proveedor), asegura compatibilidad VMQ/RSS y valida la distribución de interrupciones después.

Task 15: Correlacionar CPU de “System” con un módulo de controlador específico via muestreo en vivo (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

Qué significa: Esta es una traza de muestreo de CPU que puedes abrir en WPA. “CPU Usage (Sampled)” con stacks a menudo destaca la rutina caliente del controlador.

Decisión: Si las pilas convergen en un módulo de controlador, has pasado de “probable” a “demostrable.”

Task 16: Identificar servicios fuera de control que disparan rutas del kernel (comprobación de tormenta de E/S)

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

Qué significa: “System” está en la cima, pero procesos en usuario como AV o bases de datos pueden estar generando la carga que desencadena overhead del kernel.

Decisión: Si ETW muestra E/S de archivos intensiva con coste de minifilter, ajusta exclusiones; si existen resets de almacenamiento, enfócate primero en la ruta.

Broma #1: El proceso “System” es el compañero de trabajo que siempre dice “estoy en reuniones”—y de alguna forma tu proyecto sigue fallando.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

Una fintech mediana ejecutaba una flota de VMs Windows Server manejando ingestión de mensajes y cifrado. Un lunes, tras una ventana de cambios rutinaria del fin de semana,
el on-call vio CPU al máximo en varios nodos. El Administrador de tareas apuntaba a “System” y “System interrupts”. La teoría instintiva: “Nuestro servicio de ingestión está fugando hilos.”

El equipo escaló el servicio, duplicó trabajadores de cola e incluso ajustó parámetros GC. Nada mejoró. La flota se volvió más inestable porque aumentaron el throughput hacia un cuello de botella en el kernel.
Mientras, los clientes reportaron timeouts intermitentes; los dashboards mostraron aumento en latencia de escritura en disco.

La suposición equivocada fue simple: “Si la CPU está alta, es espacio de usuario.” No midieron tiempo privilegiado. No comprobaron la tasa de DPC/interrupciones.
No miraron registros del System porque “esos siempre están ruidosos.”

Cuando alguien finalmente corrió una comprobación rápida de contadores, el tiempo privilegiado dominaba y las interrupciones eran absurdas. Los registros mostraron resets de Storport.
Las trazas ETW mostraron stacks de CPU pasando tiempo en rutinas de completado de almacenamiento—consistente con un controlador reiniciando repetidamente la ruta.

Causa raíz: una actualización de firmware de almacenamiento en el cluster subyacente interactuó mal con una configuración específica de HBA virtual. Revertir el firmware
(o mover VMs a hosts no afectados) estabilizó el entorno. El servicio de ingestión estaba bien; simplemente estaba gritando hacia una ruta de almacenamiento rota.

La lección duradera: antes de tocar tu app, clasifica la CPU. Si es tiempo de kernel, trata a tu aplicación como generadora de carga, no como sospechosa.

Microhistoria 2: La optimización que salió mal

Una empresa minorista tenía una canalización interna de procesamiento de archivos en servidores Windows con alto throughput de red. Alguien notó overhead de CPU en los receptores
y propuso habilitar “todas las funciones de offload” en las NIC para reducir CPU del host. El cambio se aprobó porque parecía dinero gratis.

Al principio, la CPU bajó en benchmarks. Luego el tráfico de producción llegó: tamaños de paquete aleatorios, ráfagas y mezcla de TLS y texto plano. En horas,
varios nodos mostraron alta CPU en “System” y la latencia empeoró. Los dashboards de red mostraron micro ráfagas extrañas y pérdidas periódicas.

Las trazas ETW dejaron claro: el tiempo se quemaba en NDIS y el controlador NIC del proveedor, dominado por procesamiento DPC. La moderación de interrupciones estaba afinada demasiado agresivamente para throughput,
y una ruta de offload estaba defectuosa bajo la forma de tráfico de la canalización. El sistema no era “más rápido”; oscilaba entre ráfagas coalescidas y acumulaciones de DPC.

El equipo revirtió los cambios, luego reintrodujo offloads uno a uno, verificando con contadores: interrupts/sec, tiempo de DPC y latencia de extremo a extremo.
Mantuvieron RSS habilitado y ajustaron el número de colas, pero deshabilitaron el offload problemático. La CPU subió ligeramente, pero la fluctuación (jitter) cayó masivamente—y el jitter era el verdadero killer de SLO.

La lección duradera: la “optimización de CPU” que ignora la latencia cola es cómo obtienes un sistema rápido que se siente lento. Además, cambiar diez ajustes de NIC a la vez no es un experimento científico; es danza interpretativa.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un SaaS de salud ejecutaba servidores de aplicaciones Windows con control de cambios estricto. Su equipo SRE mantenía una matriz de controladores y firmware aprobados: versiones aprobadas para NIC,
controlador de almacenamiento, chipset, más un camino de rollback documentado. No era glamoroso. Eran hojas de cálculo y “no, no puedes actualizar eso hoy.”

Un trimestre, un proveedor lanzó un nuevo controlador NIC para abordar un advisory de seguridad. Seguridad quería desplegarlo ayer.
Operaciones accedió—pero solo tras ponerlo en staging en un conjunto canario con un procedimiento estándar de captura ETW durante carga sintética.

El canario inmediatamente mostró mayor tiempo de DPC y más interrupts/sec bajo un perfil de tráfico específico. No catastrófico, pero medible,
y la tendencia era mala. Pausaron el despliegue, abrieron un caso con el proveedor con evidencia ETW, y continuaron con la versión aprobada mientras aplicaban mitigaciones alternativas.

Dos semanas después, el proveedor entregó una build corregida. El canario quedó limpio. El despliegue completó sin incidentes.
Nadie escribió un postmortem heroico porque nada se rompió. Ese es el punto.

La lección duradera: controles aburridos—matrices de versiones, canarios, trazas repetibles—vencen la adrenalina siempre.

Broma #2: Si no capturas una traza, tu causa raíz es “las vibras estaban mal”, y finanzas no aceptará eso como partida presupuestaria.

Algunos ángulos de almacenamiento y “System”: sospechosos habituales (Storport, controladores filtro, colas)

Los problemas de almacenamiento aparecen de forma desproporcionada como CPU en “System”. El kernel hace contabilidad de E/S: rutinas de completado, reintentos, timeouts,
gestión de colas, vaciados de caché y recuperación de errores. Cuando la pila de almacenamiento está descontenta, puede quemar CPU mientras además entrega peor latencia. Eficiente.

Resets y timeouts de Storport: por qué duelen a la CPU

Un reset de Storport (comúnmente evento ID 129) no es solo “una advertencia”. Significa que Windows dijo a un miniport de almacenamiento: “no recibo respuestas a tiempo; reinicia el dispositivo/ruta”.
Los resets pueden llevar a abortos de comandos, requeues, comportamientos de invalidación de caché, eventos de multipath y una tormenta de completados. Todo en contexto kernel.

Si ves un patrón como: pico de latencia → evento 129/153 → pico de CPU en System, trátalo como correlacionado hasta que se demuestre lo contrario.

Apilamiento de controladores filtro: el impuesto de la ruta caliente que no presupuestaste

Los minifiltros pueden ser correctos y aun así caros. Añade dos o tres en serie—escaneo AV, inspección DLP, filtro de snapshot de backup—y puedes multiplicar el coste por E/S.
Bajo carga, eso se convierte en CPU del kernel y presión de DPC, especialmente si el filtro hace trabajo síncrono o provoca lecturas de metadatos adicionales.

Profundidad de cola y “E/S pequeñas”: dolor autoinfligido

Algunos workloads generan muchas escrituras aleatorias pequeñas y fsyncs. No es una falla moral; es cómo ciertas bases de datos y colas de mensajes mantienen consistencia.
Pero si la ruta de almacenamiento está afinada para I/O en streaming, puedes forzar al SO y al controlador a manejar una tasa masiva de IOPS con overhead alto por operación.

La solución puede ser un cambio en la aplicación para agrupar operaciones. O puede ser “deja de usar un combo de controlador/controladora que se reinicia bajo presión.”
No asumas que es tu código hasta tener stacks ETW.

Ángulo de red y “System”: NDIS, offloads, RSS y tormentas de paquetes

Los controladores de red viven en un mundo de interrupciones, DPC y empaquetado cuidadoso. Cuando algo falla, la CPU pasa a tiempo kernel rápidamente.
Si el pico de System coincide con ráfagas de tráfico, pérdidas o retransmisiones, probablemente estés en territorio NDIS.

Patrones clásicos

• Interrupciones/sec muy altas con un núcleo haciendo la mayor parte del tiempo de interrupción: problema de afinidad de interrupciones/configuración RSS/colas.
• El tiempo de DPC sube cuando aumenta el throughput: el controlador lucha con el procesamiento de recepción o rutas de coalescencia/segmentación.
• Después de una actualización del controlador: el comportamiento de offload cambia; los valores por defecto se modifican; aparece un bug solo con tu mezcla de tráfico.
• Switches virtuales y overlays: vSwitch, encapsulación y agentes de seguridad añaden capas que pueden amplificar el overhead.

Offloads: trátalos como flags de función, no mandamientos

Los offloads pueden ser beneficiosos, pero “habilitarlos en todas partes” no es una estrategia. El enfoque correcto es:
habilitar un conjunto mínimo, medir bajo carga representativa y luego ampliar con cuidado. Si un ajuste reduce CPU pero empeora la latencia cola, no es una victoria.

RSS y encolado: distribuye el trabajo o paga el impuesto de un solo núcleo

Las NIC modernas pueden distribuir el procesamiento de recepción entre núcleos usando RSS. Pero los valores por defecto no siempre son sensatos, especialmente en VMs o cuando otras características (VMQ, SR-IOV)
están involucradas. Si ves un núcleo pegado con interrupciones, RSS/afinidad es un sospechoso inmediato.

Virtualización e hipervisores: cuando el host es inocente y aun así culpable

En entornos virtualizados, “controlador” puede significar:

• Controladores en el invitado (NIC/almacenamiento virtual)
• Controladores del host (NIC/HBA físico) causando latencia que el invitado experimenta como resets/timeouts
• Capas de switch virtual/controladores filtro en la pila del host
• Planificación de CPU y peculiaridades de virtualización de interrupciones

Una VM invitada que muestra CPU alta en System por resets de almacenamiento puede ser causada por colas de almacenamiento a nivel host o problemas de la red de almacenamiento.
Tu prueba aún comienza en el invitado (ETW, registros de eventos), pero la remediación puede requerir al equipo de plataforma.

Consejo práctico: si puedes reproducir el problema migrando en vivo la VM a otro host, eso es evidencia potente.
No es causalidad perfecta, pero es una señal direccional fuerte—especialmente si se acompaña de trazas.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: CPU alta en “System”, pero solo miras el Administrador de tareas

Causa raíz: Sin atribución. “System” es un cubo, no un diagnóstico.

Solución: Captura ETW (WPR/WPA) e inspecciona stacks muestreados de CPU; confirma tiempo de DPC/ISR e identifica módulos de controladores.

2) Síntoma: Un núcleo pegado, los demás inactivos; RDP va fatal

Causa raíz: Problemas de enrutamiento/afinidad de interrupciones, RSS deshabilitado/mal configurado, o un dispositivo atascado en una sola cola.

Solución: Verifica estado de RSS y recuento de colas; actualiza controlador/firmware de NIC; ajusta colas RSS; valida la distribución de interrupciones después.

3) Síntoma: CPU de System se dispara durante backups o escaneos AV

Causa raíz: Minifiltros del sistema haciendo trabajo síncrono intenso, escaneando datasets calientes o snapshotting con rutas de metadatos costosas.

Solución: Revisa salida de fltmc; ajusta exclusiones; programa escaneos; elimina agentes redundantes; prueba en un canario.

4) Síntoma: CPU alta en System más Event ID 129 (reset de storport)

Causa raíz: Timeouts/resets de almacenamiento debido a controlador/firmware/controladora, inestabilidad de la red, o desajuste de profundidad de cola.

Solución: Correlaciona con contadores de latencia de disco; actualiza/revierte miniport driver; comprueba firmware; valida cableado/fabric; involucra al equipo de almacenamiento con evidencia ETW.

5) Síntoma: Interrupciones/sec altas tras habilitar offloads

Causa raíz: Bug o desajuste en la ruta de offload; moderación de interrupciones demasiado agresiva o demasiado laxa; interacciones RSC/LSO.

Solución: Revierte y vuelve a habilitar una opción a la vez; mide interrupts/sec, tiempo de DPC y latencia cola; mantiene una base conocida buena.

6) Síntoma: CPU del kernel alta solo en hardware “nuevo”

Causa raíz: Valores por defecto de BIOS/firmware (estados de energía, PCIe ASPM), controlador de chipset o controlador no validado para esa plataforma.

Solución: Alinea configuraciones de BIOS con la guía de rendimiento del proveedor; actualiza firmware y controladores de chipset; revisa advertencias WHEA; prueba con un plan de energía consistente.

7) Síntoma: “System” con CPU alta durante escrituras pequeñas intensas, especialmente con cifrado

Causa raíz: Overhead de criptografía/controladores filtro y patrones de flush que amplifican el coste por E/S; pueden exponer sensibilidad a latencia de almacenamiento.

Solución: Mide distribución de tamaño de E/S via ETW; agrupa escrituras donde sea seguro; verifica versiones de controladores de cifrado; considera aceleración hardware y modos soportados.

Listas de verificación / plan paso a paso

Checklist A: Triar en 10 minutos (seguro para producción)

1. Ejecuta contadores para CPU privilegiada vs usuario; confirma dominio de tiempo de kernel.
2. Revisa interrupts/sec y tiempo de DPC/interrupción; anota si hay sesgo en un núcleo.
3. Extrae la última hora de advertencias/errores del log System; busca patrones storport/disk/ndis/whea.
4. Lista controladores no Microsoft y componentes cambiados recientemente (NIC, almacenamiento, controladores filtro).
5. Decide si tiene forma de almacenamiento o de red según contadores + logs.

Checklist B: Captura de evidencia (para que dejen de discutir)

1. Inicia traza WPR (CPU + DiskIO + Network) en filemode.
2. Reproduce o espera el pico (60–120 segundos suelen ser suficientes).
3. Detén la traza y guarda ETL con marca temporal en el nombre.
4. Captura una instantánea concurrente de contadores para latencia/cola de disco e interrupts/sec.
5. Archiva el recorte del registro System para la misma ventana.

Checklist C: Experimentos de aislamiento (elige uno, no hagas shotgun)

1. Si es forma de red: alterna un offload; mide; revierte si empeora.
2. Si es forma de almacenamiento: prueba rollback de controlador en un nodo; mide; verifica cambios en frecuencia de evento 129.
3. Si es forma de filtros: deshabilita/desinstala un filtro no crítico en un canario; mide latencia de I/O y CPU del kernel.
4. Si es virtualizado: migra la carga/VM a otro host; compara trazas y logs.
5. Si es hardware: cambia de puerto/cable de NIC, actualiza firmware, comprueba WHEA.

Checklist D: Control de cambios que no arruine tu trimestre

1. Mantén una matriz aprobada de controladores/firmware por modelo de plataforma.
2. Canariza cada actualización de controlador bajo carga representativa; captura ETW antes/después.
3. Documenta pasos de rollback y guarda instaladores localmente para ventanas de emergencia.
4. Registra ajustes de offload/RSS como configuración, no como “lo que diga la GUI hoy”.

Preguntas frecuentes

1) ¿Por qué “System” consume CPU en vez de que el controlador aparezca como proceso?

Los controladores del kernel no se ejecutan como procesos en modo usuario con su propio PID. Su trabajo se ejecuta en contexto kernel, frecuentemente imputado al proceso System.
Las trazas ETW de stacks son cómo atribuyes ese trabajo a un módulo específico.

2) ¿“System interrupts” con CPU alta siempre es hardware?

Es hardware más software. El hardware dispara las interrupciones, pero los controladores deciden cómo se manejan, agrupan y difieren las interrupciones.
Controladores defectuosos, ajustes de offload malos o problemas de firmware pueden producir tormentas de interrupciones.

3) ¿Cuál es la diferencia entre ISR y DPC, y por qué debería importarme?

ISR es la rutina inmediata de servicio de interrupción—debe ser rápida. DPC es trabajo diferido programado para ejecutarse pronto después con prioridad alta.
Si el tiempo de DPC es alto, tu sistema puede sentirse lento porque el trabajo de kernel de prioridad alta desplaza a los hilos normales.

4) ¿El antivirus realmente puede causar picos de CPU en “System”?

Sí. El AV suele usar minifiltros de sistema de archivos. Bajo alto churn de archivos (servidores de build, apps con mucho logging, ventanas de backup),
el filtro puede añadir coste por E/S y hacer subir dramáticamente la CPU del kernel.

5) Si actualizo controladores, ¿“último” siempre es mejor?

No. “Último” es una apuesta salvo que esté validado en tu hardware, build de OS y workload. Prefiere versiones soportadas por el proveedor y canariza con evidencia ETW antes de un despliegue amplio.

6) ¿Cuánto tiempo debo capturar una traza ETW?

Lo suficiente para incluir el pico y un poco de línea base normal—a menudo 60–180 segundos bastan para atribución de CPU.
Si los picos son raros, usa buffering circular y captura alrededor de la ventana del incidente.

7) Veo resets de storport (Evento 129). ¿Eso es definitivamente el array de almacenamiento?

No necesariamente. Puede ser array, fabric, firmware del HBA, controlador, desajuste de profundidad de cola o incluso CPU del host saturada causando timeouts.
Correlaciona con latencia de disco, reintentos (Disk 153) y stacks ETW de almacenamiento para acotar.

8) ¿Y si ETW muestra mayormente ntoskrnl.exe en vez de un controlador del proveedor?

Eso puede pasar cuando los símbolos/pilas no están bien resueltas, o cuando la ruta caliente es código genérico del kernel llamado por muchos controladores.
Asegura que el stack walking esté habilitado, incluye eventos del cargador y cruza proveedores DPC/ISR. A menudo aún así encuentras el controlador desencadenante por el contexto del call stack.

9) ¿Puede una aplicación en modo usuario causar CPU alta en “System” aunque el controlador esté bien?

Sí—generando cargas patológicas: IOPS extremadamente altos de operaciones pequeñas, patrones de sockets abusivos o churn constante de open/close.
ETW te ayuda a distinguir “bug de controlador” de “trabajo legítimo del kernel causado por la carga”.

10) ¿Debería usar Driver Verifier para detectar esto?

Driver Verifier es potente pero arriesgado en producción; puede inducir crashes para exponer defectos de controladores.
Úsalo en staging o en un nodo sacrificial con plan de rollback, no en tu base de datos más importante a mediodía.

Conclusión: próximos pasos prácticos

Cuando “System” se come la CPU, trátalo como un incidente del kernel, no como una sesión de afinamiento de aplicaciones. Tu camino más rápido a la verdad es:
contadores para clasificar, logs para correlacionar, ETW para atribuir y un cambio controlado para demostrar causalidad.

1. Ejecuta contadores de CPU privilegiada/usuario y de interrupciones/DPC para confirmar la clase de problema.
2. Extrae registros System por señales de storport/disk/ndis/whea en la misma ventana.
3. Captura una traza WPR corta e inspecciona stacks muestreados de CPU en WPA.
4. Identifica el controlador/módulo y elige la mitigación reversible más pequeña (rollback/toggle/offload/test de filtro).
5. Tras la corrección, vuelve a capturar los mismos contadores/traza para demostrar la mejora y prevenir regresiones.

Si haces solo una cosa: obtén la traza. Convierte “System está alto” de una queja en una causa raíz sobre la que puedes actuar—o entregar al proveedor sin vergüenza.