Cómo monitorear RAM y CPU en VPS Windows sin herramientas pagas

Guía práctica para monitorear RAM y CPU en VPS Windows usando Task Manager, Resource Monitor, PerfMon y PowerShell — sin instalar nada pago.

Un VPS Windows Server consume RAM y CPU de forma distinta a Linux — el overhead del sistema operativo es mayor, el pagefile es más agresivo, y los procesos GUI quedan residentes incluso cuando nadie está conectado vía RDP. Para un admin que necesita diagnosticar lentitud o planear un upgrade de plan, saber qué herramienta nativa usar en cada situación ahorra horas de depuración.

Esta guía cubre las cuatro herramientas nativas de Windows Server para monitorear RAM y CPU: Task Manager para diagnóstico inmediato, Resource Monitor para análisis de 60 segundos con gráfico, Performance Monitor para recolección histórica persistente, y PowerShell para automatización y Server Core. Ninguna exige licencia adicional, instalación de agente ni cuenta en la nube.

Tiempo estimado de ejecución: 25 a 35 minutos para configurar todas las herramientas y grabar el primer Data Collector Set con datos reales.

Prerrequisitos

Prerrequisitos

Necesitas Windows Server 2019, 2022 o 2025 con acceso RDP usando cuenta administradora local o de dominio. PowerShell 5.1 o superior ya viene por defecto. Para Server Core, conexión vía WinRM o consola directa. Cerca de 200 MB libres en disco si vas a habilitar Data Collector Sets persistentes.

Sistema probado Windows Server 2022
Puerto RDP por defecto 3389
PowerShell mínimo 5.1
Acceso necesario Administrator

Task Manager para diagnóstico inmediato

Task Manager es la primera parada cuando algo está visiblemente mal — RDP lento, aplicación colgada, alerta de monitoreo externo. En tres clics ves quién está consumiendo qué.

01

Conecta vía RDP y abre Task Manager con Ctrl+Shift+Esc. Si aparece la versión compacta, haz clic en “More details” en la esquina inferior izquierda para expandir.

Ve a la pestaña “Performance” — verás gráficos de CPU, Memory, Disk y Ethernet en tiempo real. Haz clic en “Memory” para ver los detalles de la RAM.

02

Identifica los números que importan en el panel de memoria:

  • In use: RAM física ocupada ahora por procesos.
  • Available: RAM libre + standby (caché que puede liberarse).
  • Committed: total reservado incluyendo pagefile, en formato “actual/máximo”.
  • Cached: datos en standby que pueden descartarse si otro proceso los necesita.

Si “Committed” está cerca del máximo, el sistema está usando pagefile pesado. Aumenta la RAM o identifica el proceso que está filtrando memoria.

03

Ve a la pestaña “Details” y haz clic en el encabezado de la columna “Memory (private working set)” para ordenar de mayor a menor. Los 5 procesos en el tope concentran el 80% del consumo en la mayoría de los servidores.

Para CPU, ordena por la columna “CPU” — pero atención: el valor mostrado es instantáneo y oscila bastante. Para un promedio confiable, usa Resource Monitor.

Working set vs memoria privada

La columna “Memory (private working set)” muestra solo RAM exclusiva del proceso. La columna “Memory (shared working set)” muestra DLLs compartidas. Para calcular el impacto real, considera el private — es lo que desaparecería si matas el proceso.

Resource Monitor para análisis de 60 segundos

Resource Monitor (resmon.exe) ofrece una vista detallada con gráficos rodantes de los últimos 60 segundos. Úsalo cuando Task Manager mostró que algo está alto pero necesitas entender el patrón.

01

Presiona Win+R, escribe resmon y Enter. La ventana tiene 5 pestañas: Overview, CPU, Memory, Disk, Network. Los gráficos a la derecha se actualizan cada segundo.

Ve a la pestaña “Memory”. Verás procesos ordenados por uso, con columnas Commit, Working Set, Shareable y Private. La diferencia respecto a Task Manager es el gráfico inferior — “Used Physical Memory” muestra el hardware en modo barra horizontal: Hardware Reserved, In Use, Modified, Standby y Free.

02

Para investigar la CPU, ve a la pestaña “CPU”. Marca el checkbox de un proceso en la lista — el gráfico “Associated Modules” muestra qué DLLs está ejecutando, y “Associated Handles” lista archivos y claves de registro abiertos.

Este cross-reference revela cosas que Task Manager no muestra: por ejemplo, un w3wp.exe (IIS) consumiendo CPU porque está trabado en un archivo de log que otro proceso dejó bloqueado.

No confíes en el valor "Maximum Frequency"

El porcentaje mostrado en “Maximum Frequency” en Resource Monitor puede pasar de 100% si el procesador tiene Turbo Boost activo. En VPS esto puede aparecer incluso sin Turbo real, dependiendo de cómo la virtualización expone los cores. Usa ”% CPU Usage” como referencia principal.

Performance Monitor para historial persistente

Resource Monitor muestra solo 60 segundos y pierde todo al cerrar. Para rastrear el consumo de RAM y CPU a lo largo de horas, días o semanas, configura Data Collector Sets en Performance Monitor.

01

Abre Performance Monitor (perfmon.exe). En el panel izquierdo, expande “Data Collector Sets” → “User Defined”. Clic derecho → New → Data Collector Set.

Nombre: RAM_CPU_Baseline. Selecciona “Create manually (Advanced)” y haz clic en Next. Marca “Performance counter” y Next.

02

En “Performance counters”, haz clic en Add y selecciona estos contadores esenciales:

\Processor(_Total)\% Processor Time
\Memory\Available MBytes
\Memory\Committed Bytes
\Memory\Pages/sec
\Memory\Page Faults/sec
\Process(*)\Working Set
\Process(*)\% Processor Time
\System\Processor Queue Length

Configura “Sample interval” en 15 segundos. En producción, 60 segundos es suficiente — intervalos demasiado cortos generan archivos enormes sin ganancia de precisión.

03

Elige el directorio de salida (por defecto %systemdrive%\PerfLogs\Admin\RAM_CPU_Baseline). Haz clic en Finish. Clic derecho en el Data Collector Set creado → Start. La recolección empieza inmediatamente en formato binario .blg.

Para detener después de unas horas, clic derecho → Stop. El archivo aparece en “Reports” → “User Defined” → tu set. Haz doble clic para abrir el gráfico histórico.

Exportar a CSV para análisis externo

Para abrir los datos en Excel o enviarlos a un stack de análisis, convierte el .blg a CSV: relog C:\PerfLogs\Admin\RAM_CPU_Baseline\DataCollector01.blg -f CSV -o salida.csv. El comando relog viene con Windows Server, no hay que instalar nada.

PowerShell para automatización y Server Core

En Windows Server Core no hay GUI — PowerShell es la única opción. Incluso en Server con GUI, los scripts son útiles para recolectar métricas en varios servidores simultáneamente o enviarlas a un endpoint externo.

01

Para un snapshot rápido de RAM y CPU ahora, ejecuta en PowerShell:

Get-CimInstance Win32_OperatingSystem | Select-Object `
  @{N='RAM_Total_GB';E={[math]::Round($_.TotalVisibleMemorySize/1MB,2)}}, `
  @{N='RAM_Libre_GB';E={[math]::Round($_.FreePhysicalMemory/1MB,2)}}, `
  @{N='RAM_Uso_Pct';E={[math]::Round((($_.TotalVisibleMemorySize - $_.FreePhysicalMemory) / $_.TotalVisibleMemorySize) * 100, 2)}}

Get-CimInstance Win32_Processor | Select-Object Name, LoadPercentage

El resultado muestra RAM total, libre y porcentaje de uso, más la carga promedio de la CPU en el momento.

02

Para identificar los top 10 procesos consumiendo RAM, ordenados:

Get-Process | Sort-Object WorkingSet64 -Descending |
  Select-Object -First 10 `
    Name, Id, `
    @{N='RAM_MB';E={[math]::Round($_.WorkingSet64/1MB,2)}}, `
    @{N='CPU_seg';E={[math]::Round($_.CPU,2)}} |
  Format-Table -AutoSize

El campo CPU muestra segundos totales de CPU consumidos por el proceso desde que inició — útil para identificar procesos antiguos que acumularon carga.

03

Para monitoreo continuo cada 30 segundos, guarda este script como monitor.ps1:

while ($true) {
  $ts = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
  $cpu = (Get-CimInstance Win32_Processor).LoadPercentage
  $os = Get-CimInstance Win32_OperatingSystem
  $ramPct = [math]::Round((($os.TotalVisibleMemorySize - $os.FreePhysicalMemory) / $os.TotalVisibleMemorySize) * 100, 2)
  "$ts CPU=$cpu% RAM=$ramPct%" | Out-File -Append C:\PerfLogs\monitor.log
  Start-Sleep -Seconds 30
}

Ejecuta en segundo plano: Start-Process powershell -ArgumentList "-File C:\scripts\monitor.ps1" -WindowStyle Hidden. El log queda en formato simple, fácil de procesar con Get-Content después.

Verificación

Para confirmar que cada herramienta está recolectando datos correctamente:

# Confirma que el Data Collector Set está corriendo
logman query RAM_CPU_Baseline

# Lista los archivos .blg generados
Get-ChildItem C:\PerfLogs\Admin\RAM_CPU_Baseline\ -Recurse -Filter *.blg

# Confirma que el script monitor.ps1 está grabando
Get-Content C:\PerfLogs\monitor.log -Tail 5

Salida esperada: logman query debe mostrar Status: Running, debe haber al menos un .blg en el directorio (aunque sea pequeño), y el log de PowerShell debe mostrar líneas recientes con timestamps de los últimos minutos.

Resolución de problemas

Performance Monitor no crea el archivo .blg

Verifica los permisos en la carpeta de salida. El usuario “SYSTEM” necesita escritura en C:\PerfLogs. Ejecuta icacls C:\PerfLogs — si falta SYSTEM con (F), arréglalo con icacls C:\PerfLogs /grant SYSTEM:F /T. También confirma que el disco tenga al menos 500 MB libres, si no el colector se detiene silenciosamente.

Get-Counter devuelve “Path could not be found”

Ocurre cuando el sistema está en otro idioma (portugués, español) y los contadores aparecen con nombres traducidos. Usa la sintaxis numérica en lugar de la textual: (Get-Counter '\2\6').CounterSamples.CookedValue devuelve ”% Processor Time” independiente del idioma. La lista completa de IDs está en HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009\Counter.

Resource Monitor muestra el proceso “System” consumiendo mucha RAM

El proceso System (PID 4) con working set alto generalmente indica un driver con fuga de memoria o caché de filesystem agresivo. Usa poolmon.exe (parte del Windows Driver Kit) para ver qué tag de pool está creciendo. En VPS, es común que los drivers de paravirtualización (red o disco) necesiten update.

Próximos pasos

Con las cuatro herramientas dominadas, tienes cobertura completa de monitoreo sin costo adicional. Para avanzar:

  • Configura alertas en Performance Monitor (clic derecho en el Data Collector Set → Properties → Alerts) para dispararse cuando la RAM disponible caiga por debajo de 500 MB.
  • Usa WMI Events en PowerShell para acciones automáticas — reiniciar un servicio cuando la CPU pase del 90% por más de 5 minutos.
  • Centraliza logs de varios servidores en una sola estación vía Event Forwarding o Windows Admin Center.
  • Estudia los contadores de Memory\Pool Paged Bytes y Pool Nonpaged Bytes para detectar fugas en el kernel temprano.

Si estás provisionando entornos Windows para producción, una VPS Hostini con plan optimizado para Windows Server ya viene con RAM dedicada (sin oversubscription), lo que hace que la lectura de los contadores Available MBytes y Committed Bytes sea confiable — en entornos sobreasignados, los números del guest pueden mentir.

Preguntas frecuentes

¿Cuál es la diferencia entre Memory In Use y Committed en Task Manager?

In Use es la RAM física efectivamente ocupada por procesos en el momento. Committed es la suma de la RAM física más el pagefile reservados por el sistema — puede superar la RAM total porque incluye memoria virtual. Si Committed crece por encima de 1.5x la RAM física, el servidor está haciendo paging pesado y la CPU sufrirá con I/O de disco.

¿Por qué el uso de CPU en Task Manager difiere del Resource Monitor?

Task Manager muestra utilización promedio en el intervalo de refresh (1-2s), mientras que Resource Monitor muestra promedio por core en los últimos 60 segundos con gráfico. En cargas con picos, Task Manager puede mostrar 100% momentáneo que el Resource Monitor suaviza. Para depurar procesos que se cuelgan, usa Resource Monitor — el gráfico histórico revela patrones.

¿Puedo ejecutar Performance Monitor sin impacto en producción?

Sí, los contadores de PerfMon tienen overhead mínimo (<1% CPU) cuando se recolectan en intervalos de 15s o mayores. El costo aparece cuando registras cientos de contadores cada 1 segundo. Para producción, configura Data Collector Sets con intervalo de 60s y mantén solo los 8-10 contadores que importan para tu caso.

¿Cómo veo qué proceso está consumiendo RAM en Windows Server Core?

Sin GUI, usa PowerShell: Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, @{N='RAM_MB';E={[math]::Round($_.WorkingSet64/1MB,2)}}. WorkingSet64 muestra RAM física real, distinta de PrivateMemorySize que incluye pagefile. Para CPU, cambia por CPU en lugar de WorkingSet64.

El contador Available MBytes está alto pero el servidor está lento. ¿Por qué?

RAM disponible alta con sistema lento generalmente indica presión de disco o CPU, no memoria. Verifica Disk Queue Length (debe quedar por debajo de 2) y Processor Time. Otra causa es working set demasiado pequeño — Windows puede estar haciendo trim agresivo de páginas que los procesos usan poco después, generando page faults constantes incluso con RAM libre.

¿Cuánto historial guarda Resource Monitor?

Resource Monitor muestra los últimos 60 segundos en tiempo real y no persiste datos al cerrar. Para historial de horas, días o semanas, configura un Data Collector Set en PerfMon con salida en .blg — graba en disco y luego revisas en el propio PerfMon o exportas a CSV vía relog.exe.

Temas:
Próximos pasos Cloud Ryzen con NVMe y protección DDoS siempre activa.Pon en producción en un VPS Hostini →
¿Te resultó útil este tutorial?
Hablar por WhatsApp