La idea central

No diagnostiques “el servidor está lento” mirando un único porcentaje. Define primero qué operación se ha degradado, cuantifica la desviación frente a una línea base y sigue la cadena de espera: aplicación → proceso/hilo → sistema operativo → driver/hipervisor → recurso físico o servicio dependiente.

1. El modelo: síntoma, saturación y causa no son lo mismo

Un servidor puede mostrar CPU al 95 % sin que la CPU sea la causa primaria: un bucle de reintentos puede consumir procesador porque una dependencia externa está fallando. También puede tener CPU al 25 % y ofrecer tiempos de respuesta inaceptables porque un único hilo está serializado, espera I/O o compite por CPU dentro de una máquina virtual.

El primer paso es traducir la queja a una señal observable. “La aplicación va lenta” no es una métrica. “El p95 de la operación X pasó de 180 ms a 2,4 s entre las 10:05 y las 10:22, afectando a tres nodos” sí permite investigar. Registra:

  • Operación o servicio afectado y métrica de experiencia: latencia p50/p95/p99, throughput, errores y timeouts.
  • Ventana temporal exacta, recurrencia, alcance y cambios coincidentes.
  • Topología: físico/virtual, clúster, almacenamiento, red, balanceadores y dependencias.
  • Línea base comparable: mismo horario, carga, patrón de negocio y configuración.
  • Impacto y restricciones operativas: criticidad, tolerancia a captura, ventana de cambio y límites de almacenamiento.

Trabaja con hipótesis falsables. Por ejemplo: “la cola de disco crece antes de la latencia de aplicación” es verificable; “el disco está mal” no lo es. Busca precedencia temporal y correlación, pero no confundas correlación con causalidad.

2. Captura de evidencia: PerfMon antes que la intuición

Task Manager y Resource Monitor sirven para orientar una primera inspección. No son suficientes para un evento intermitente: cuando alguien abre la consola, el pico puede haber terminado. Para problemas que aparecen por ventanas, deja una captura persistente con Performance Monitor (PerfMon) o logman.

2.1 Diseña la captura según el fenómeno

Para una degradación de varios minutos, un intervalo de 5–15 segundos suele ofrecer una visión general razonable. Para picos breves o CPU elevada, reduce el intervalo durante una ventana acotada, asumiendo mayor volumen y overhead. No conviertas un muestreo de un segundo en una política permanente sin medir el coste. Microsoft advierte además de la agregación visual de muestras cuando PerfMon presenta demasiados puntos en una gráfica: conserva el BLG original y analiza sus estadísticas, no solo la curva.

Ejemplo de conjunto circular de contadores, con límite de tamaño y muestreo cada 15 segundos. Ejecuta en una consola elevada y adapta el directorio, la capacidad y los objetos a la función del servidor:

$name = 'CA_Perf_15s'
$path = 'C:\PerfLogs\CA_Perf_15s.blg'

logman create counter $name `
  -o $path -f bincirc -v mmddhhmm -max 1024 `
  -c '\Processor Information(*)\*' `
     '\System\*' `
     '\Memory\*' `
     '\PhysicalDisk(*)\*' `
     '\LogicalDisk(*)\*' `
     '\Process(*)\*' `
     '\Network Interface(*)\*' `
  -si 00:00:15

logman start $name

# Cuando termine la ventana de observación:
logman stop $name
logman delete $name

El conjunto anterior es una plantilla de partida, no una configuración universal. En servidores Hyper-V, RDS, SMB, IIS o SQL Server añade los objetos específicos de ese rol. Evita capturar todos los contadores disponibles indiscriminadamente: aumenta el coste, el tamaño y la dificultad de análisis.

2.2 Reglas de calidad de la evidencia

  • Sincroniza la referencia temporal con los sistemas de aplicación, monitorización, almacenamiento e hipervisor.
  • Documenta el intervalo, los contadores, la versión del sistema y el contexto de carga.
  • Comprueba que los contadores existen y que las instancias corresponden al dispositivo o proceso esperado.
  • Conserva los ficheros originales, registra su hash si forman parte de una evidencia de incidente y limita su acceso.
  • Incluye un periodo previo y posterior al evento; capturar solo el pico elimina contexto.

3. CPU: utilización, cola, paralelismo y tiempo de kernel

Empieza con Processor Information(*)\% Processor Utility cuando esté disponible, Processor(_Total)\% Processor Time y las instancias por procesador lógico. Añade:

  • System\Processor Queue Length: hilos ejecutables esperando CPU.
  • Processor(*)\% Privileged Time y % User Time: separación entre ejecución en kernel y user mode.
  • Processor(*)\% DPC Time y % Interrupt Time: actividad de interrupciones y DPC.
  • System\Context Switches/sec y Processor(*)\Interrupts/sec: contexto de planificación y actividad de interrupciones.
  • Process(*)\% Processor Time, Thread(*)\% Processor Time y recuento de hilos: atribución al proceso/hilo.

No uses un umbral aislado como veredicto. Una cola de procesador sostenida puede indicar contención, pero su interpretación depende del número de procesadores lógicos, la carga, el paralelismo y el contexto de virtualización. Un promedio bajo puede ocultar un core saturado; una suma de porcentajes por proceso puede superar 100 % porque el contador se expresa respecto a un procesador lógico.

3.1 Diferenciar user mode, kernel y contención

Si domina User Time, investiga el proceso y sus hilos: bucles, serialización, GC, cifrado, compresión o trabajo excesivo. Si domina Privileged Time, amplía a drivers, filtros, filesystem, antivirus, networking y llamadas al sistema. Un aumento anómalo de DPC/interrupt time merece revisar NIC/HBA, drivers, firmware, colas y distribución de interrupciones; no atribuyas automáticamente el síntoma a una aplicación.

En una VM, recoge simultáneamente métricas del guest y del host. El invitado no ve toda la contención del scheduler del hipervisor. Correlaciona CPU ready/co-stop o métricas equivalentes de la plataforma, overcommit, límites/reservas, NUMA y carga del host. No compares directamente métricas de plataformas distintas sin entender su definición.

3.2 Siguiente nivel

Cuando PerfMon identifica la ventana pero no explica el trabajo que consume CPU, usa Event Tracing for Windows (ETW). WPR puede capturar perfiles de CPU y actividad del sistema; WPA permite desglosar por proceso, hilo y pila. Una traza corta y dirigida durante el evento suele aportar más que horas de contadores genéricos.

4. Memoria: presión real, commit y fugas de kernel

La memoria no se diagnostica mirando únicamente el porcentaje de RAM usado. Separa memoria física disponible, compromiso virtual, working sets y pools del kernel. Como mínimo correlaciona:

  • Memory\Available MBytes: memoria física disponible para asignación.
  • Memory\% Committed Bytes In Use y Committed Bytes: compromiso del sistema frente al límite de commit.
  • Process(*)\Working Set - Private y Private Bytes: memoria residente privada y compromiso privado por proceso.
  • Memory\Pages/sec, Page Reads/sec y Page Writes/sec: actividad de paginación, que exige interpretación contextual.
  • Memory\Pool Nonpaged Bytes y Pool Paged Bytes: pools del kernel.

Pages/sec no significa “páginas del pagefile por segundo”: puede incluir lecturas de archivos mapeados y otras operaciones. Un hard fault tampoco implica automáticamente acceso al pagefile. Busca presión sostenida: memoria disponible que cae, commit que se aproxima al límite, actividad de lectura sostenida y degradación correlacionada de aplicaciones.

4.1 Distinguir fuga de proceso de fuga de kernel

Si Private Bytes crece de forma monotónica en un proceso, contrástalo con el working set, los ciclos de carga y la liberación esperada. Si el crecimiento aparece en pools paged/nonpaged sin un proceso que lo explique, investiga drivers y asignaciones del kernel. PoolMon, cuando esté disponible en el entorno de herramientas, permite agrupar por pool tag; la atribución requiere símbolos o referencias del fabricante y no debe resolverse descargando drivers al azar.

En sistemas con límites de memoria virtualizados, revisa también ballooning, dynamic memory, reservas y presión en el host. El guest puede observar memoria disponible sin conocer toda la presión física del nodo.

5. Almacenamiento: latencia, cola, throughput y ruta completa

El contador de utilización del disco no es un diagnóstico suficiente. La pregunta relevante es cuánto tarda una operación de I/O y dónde se acumula la espera. Recoge por volumen y dispositivo:

  • PhysicalDisk(*)\Avg. Disk sec/Read y Avg. Disk sec/Write: latencia media observada por Windows.
  • PhysicalDisk(*)\Current Disk Queue Length y Avg. Disk Queue Length: solicitudes pendientes, interpretadas según el dispositivo y la arquitectura.
  • Disk Reads/sec, Disk Writes/sec, Disk Read Bytes/sec y Disk Write Bytes/sec: IOPS y throughput.
  • Process(*)\IO Read Bytes/sec y IO Write Bytes/sec: actividad atribuida a procesos, no necesariamente I/O físico completado.

Los valores de latencia deben leerse en función del tipo de almacenamiento, patrón de I/O, tamaño de bloque, profundidad de cola, caché, multipath y SLA del backend. Los umbrales genéricos publicados por Microsoft son referencias para investigar, no SLO universales. Un pico corto no equivale a degradación sostenida y una media puede ocultar colas largas; contrasta con percentiles del storage array o del hipervisor si están disponibles.

5.1 Sigue la ruta, no solo la letra de unidad

Una unidad lógica puede estar respaldada por VHDX, CSV, SAN, iSCSI, Storage Spaces, SMB o almacenamiento cloud. Identifica la ruta completa: aplicación → filesystem → volumen → virtual disk/LUN → multipath/HBA/NIC → cabina o servicio. Compara la misma ventana en Windows, hipervisor y plataforma de almacenamiento. Si la latencia aparece primero en el backend, no intentes “arreglarla” cambiando parámetros del guest.

Para atribuir actividad, combina los contadores de proceso con Resource Monitor, ETW o herramientas del fabricante. El I/O atribuido al proceso incluye operaciones que pueden terminar en caché o en capas intermedias; no equivale siempre a operaciones físicas en el medio.

6. Red: throughput no es calidad de transporte

Un enlace al 30 % puede transportar tráfico con retransmisiones, drops o latencia elevada. Correlaciona por interfaz:

  • Network Interface(*)\Bytes Total/sec, Output Queue Length y contadores de errores/descartes disponibles.
  • Get-NetAdapterStatistics: errores y descartes por adaptador.
  • Get-NetTCPStatistics: estadísticas TCP del stack; compara deltas entre muestras, no solo acumulados desde el arranque.
  • Latencia, pérdida y retransmisiones desde los extremos y a través de la ruta, junto con métricas de switch, firewall, balanceador y virtual switch.
# Fotografía inicial de adaptadores y estadísticas
Get-NetAdapter |
  Select-Object Name, InterfaceDescription, Status, LinkSpeed

Get-NetAdapterStatistics |
  Format-Table Name, ReceivedBytes, SentBytes,
    ReceivedPacketErrors, OutboundPacketErrors,
    ReceivedDiscardedPackets, OutboundDiscardedPackets -AutoSize

Get-NetTCPStatistics |
  Format-List *

Captura dos o más muestras con marca temporal para calcular deltas. En entornos virtuales revisa vNIC, vSwitch, VMQ, RSS, colas, teaming y límites de ancho de banda. En SMB, correlaciona los contadores de red con SMB Client/Server, latencia de almacenamiento y CPU: el throughput bajo puede ser consecuencia de I/O lento o de una aplicación que no genera solicitudes suficientes.

7. ETW, WPR y WPA: pasar de la correlación a la atribución

PerfMon responde “qué recurso cambió y cuándo”. ETW ayuda a responder “qué procesos, hilos, drivers o rutas de ejecución estaban trabajando”. Windows Performance Recorder (WPR) está incluido en Windows; Windows Performance Analyzer (WPA) se obtiene mediante Windows ADK / Windows Performance Toolkit. Los perfiles y el volumen de eventos deben elegirse según la hipótesis.

Comprueba primero los perfiles disponibles en la versión instalada:

wpr -profiles

Para una captura dirigida, inicia WPR con un perfil adecuado desde la interfaz o la línea de comandos. Por ejemplo, una captura corta con el perfil general, en modo archivo:

wpr -start GeneralProfile -filemode

# Reproduce o espera el síntoma durante una ventana breve.

wpr -stop C:\PerfLogs\CA-performance.etl

Valida el perfil disponible antes de ejecutar el ejemplo; los nombres pueden variar según la instalación y los componentes del Windows Performance Toolkit. No mantengas una traza ETW amplia indefinidamente: puede generar un volumen elevado y afectar al sistema. Para análisis de CPU, WPA permite agrupar por proceso, hilo y pila; carga símbolos cuando necesites resolver funciones. Para problemas de memoria, I/O, DPC o drivers, selecciona los gráficos y proveedores pertinentes en vez de abrir todas las tablas sin una pregunta concreta.

Si el caso requiere soporte del fabricante, utiliza el procedimiento de captura recomendado por ese fabricante o Microsoft (por ejemplo, TSS cuando aplique). Comprueba requisitos, permisos, datos sensibles incluidos y retención antes de recopilar o transferir trazas.

8. Flujo de trabajo operativo: una secuencia que evita cambios a ciegas

  1. Define el impacto. Servicio, transacción, percentiles, nodos afectados y ventana temporal.
  2. Congela el contexto. Cambios recientes, despliegues, tareas batch, backup, antivirus, parches, cambios de red/storage y eventos del hipervisor.
  3. Establece baseline. Compara una ventana normal equivalente; registra carga, throughput y latencia.
  4. Captura sin alterar. PerfMon persistente y eventos ya disponibles; limita la instrumentación invasiva.
  5. Localiza el subsistema. Busca qué señal cambia primero y si el síntoma es local, transversal o dependiente de una ruta.
  6. Profundiza con ETW o herramientas de rol. Solo cuando la captura inicial haya reducido el espacio de hipótesis.
  7. Formula una causa demostrable. Evidencia temporal, mecanismo técnico y explicación de por qué reproduce el impacto.
  8. Prueba una corrección acotada. Define métrica de éxito, blast radius, ventana y rollback antes del cambio.
  9. Valida después. Compara contra baseline y confirma que no se ha desplazado el cuello de botella a otro componente.
Criterio de cierre

Una incidencia de rendimiento no está resuelta porque el porcentaje haya bajado durante cinco minutos. Debe recuperarse la métrica de servicio, desaparecer o quedar explicada la señal limitante, mantenerse la estabilidad bajo carga comparable y existir evidencia posterior al cambio.

9. Errores que producen diagnósticos falsos

  • Perseguir el máximo: un pico aislado no explica una degradación sostenida. Examina duración, percentiles y precedencia.
  • Usar umbrales universales: el mismo valor significa cosas distintas en HDD, NVMe, SAN, VM y host físico.
  • Confundir proceso con recurso físico: los contadores de I/O de proceso no son una medición directa del backend.
  • Mirar solo el guest: omite contención de CPU, memoria, red y storage en el hipervisor.
  • Capturar demasiado: una traza enorme, sin hipótesis ni periodo acotado, complica el análisis y puede aumentar el impacto.
  • Optimizar antes de medir: cambios de registro, prioridades, pagefile, antivirus o parámetros de NIC pueden ocultar el síntoma y crear otro.
  • Confundir recuperación con causa raíz: reiniciar un servicio o ampliar recursos puede restaurar temporalmente el servicio sin explicar el mecanismo.

10. Fuentes primarias y referencias

Revisado el 11 de noviembre de 2026. Los nombres de contadores, perfiles y herramientas pueden variar por idioma, versión y componentes instalados. Antes de aplicar capturas o cambios en producción, valida la configuración en el sistema objetivo y sigue los procedimientos de cambio de tu organización.