Diagnóstico del rendimiento por proceso en Windows: Get-Process, Get-CimInstance y recuento de handles

Objetivo

Reducir a un único proceso de Windows un problema de CPU, memoria o handles que afecta a todo el host, usando PowerShell y recurriendo a una herramienta de Sysinternals solo cuando ya hay un proceso concreto bajo sospecha.

Requisitos previos

PowerShell en la máquina de destino (local o mediante remoting); el servicio WMI/CIM en ejecución para las clases Win32_PerfFormattedData_* (lo está por defecto); derechos de administrador para inspeccionar procesos que pertenecen a otros usuarios.

Pasos

1. Ordenar por working set: Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, WorkingSet64, CPU. La documentación de Get-Process muestra que el working set y CPU son propiedades disponibles directamente en los objetos devueltos; use WorkingSet64 (alias WS), ya que la propiedad más antigua WorkingSet, de 32 bits, da valores incorrectos en procesos de más de 2 GB.
2. Ordenar por CPU de la misma manera: Get-Process | Sort-Object CPU -Descending | Select-Object -First 10. Aquí CPU es el tiempo de procesador acumulado desde que se inició el proceso, no un porcentaje; por eso un proceso que lleva mucho tiempo en ejecución puede aparecer en los primeros puestos aunque ahora esté inactivo.
3. Para obtener una tasa en lugar de un total acumulado, consulte la clase de datos de rendimiento con formato: Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | Where-Object Name -notin '_Total','Idle' | Sort-Object PercentProcessorTime -Descending | Select-Object -First 10 Name, IDProcess, PercentProcessorTime. El filtro es importante: sin él, las instancias _Total e Idle encabezarían la lista. El valor es relativo a un procesador lógico, por lo que un proceso con varios hilos puede superar 100. La documentación de Get-CimInstance describe cómo consultar una clase con -ClassName; la documentación de la clase Win32_PerfFormattedData_PerfProc_Process incluye PercentProcessorTime e IDProcess entre sus propiedades, ya calculadas como tasa.
4. Compruebe los handles cuando sospeche que un proceso tiene una fuga de handles, una causa habitual de degradación lenta y no de un pico repentino: Get-Process | Sort-Object Handles -Descending | Select-Object -First 10 Name, Id, Handles. La propiedad subyacente Process.HandleCount está documentada como el número de handles del sistema operativo que el proceso tiene abiertos; un recuento que sube de forma constante durante horas sin que cambie la carga de trabajo es la señal típica de una fuga.
5. Una vez identificado un proceso concreto, pase a una herramienta de Sysinternals para obtener el detalle que PowerShell no expone: Process Explorer, para ver exactamente qué handles y DLL tiene abiertos un proceso; o Process Monitor, para observar en tiempo real su actividad en el sistema de archivos, el registro y los procesos o hilos.
6. Process Monitor requiere derechos de administrador (carga un controlador); Process Explorer funciona sin ellos, pero solo muestra el detalle completo de los procesos de otros usuarios cuando se ejecuta con privilegios elevados. Detenga la captura en Process Monitor sin demora, porque con la configuración por defecto su registro crece rápidamente.

Resultado esperado

Un ID de proceso concreto con una medición en forma de tasa (porcentaje de CPU, working set o recuento de handles) sobre la que un script pueda actuar, pasando a una herramienta gráfica solo cuando las propias propiedades de PowerShell no bastan.

Límites y base de verificación

Las clases Win32_PerfFormattedData_* se calculan a partir de dos muestras internas consecutivas, de modo que una única consulta puede devolver una tasa poco fiable en la primera llamada; es más fiable consultar dos veces con unos segundos de diferencia. El recuento de handles por sí solo no indica qué tipo de recurso (archivo, clave del registro, evento) se está filtrando; para ese detalle hace falta la vista por handle de Process Explorer.