Si el “Paged Pool” se come toda la RAM en Windows Server 2019, no es un “rasgo” del sistema sino la señal de que algún controlador o servicio está fugando memoria. Aquí tienes un procedimiento probado para detener la hemorragia sin reiniciar el host cada vez, aislar al culpable y aplicar la corrección definitiva.
Resumen del problema
Entorno con ~60 máquinas Windows Server 2019 (v1809, build 17763). La memoria del Paged Pool crece continuamente durante días o semanas hasta volver los servidores lentos o inaccesibles, obligando a reinicios. Se busca: (1) cómo mitigar sin reiniciar todo el equipo y (2) si es posible limitar el Paged Pool.
Idea clave y respuesta corta
- El Paged Pool no “crece porque sí”: casi siempre hay un controlador o servicio que “olvida” liberar memoria (fuga).
- No hay un tope soportado para el Paged Pool en Windows Server 2019. El sistema calcula y gestiona dinámicamente esos límites.
- La solución real es encontrar y corregir el componente que fuga (actualización, hotfix, reconfiguración o retirada).
- Mitigación temporal sin reiniciar: reinicia el servicio o controlador implicado, y amplía el pagefile para ganar margen mientras aplicas el fix.
Acciones inmediatas (sin reiniciar el servidor)
Estas medidas suelen recuperar memoria del Paged Pool de forma segura mientras avanzas con el diagnóstico.
- Reinicia el servicio que fuga (si ya lo identificaste):
sc stop <NombreServicio> sc start <NombreServicio>
En muchos casos el contadorMemory\Pool Paged Bytes
cae tras reiniciar el servicio. - Reinicia el controlador (NIC, filtro de backup, antivirus, etc.). Puedes usar Administrador de dispositivos o PowerShell:
Get-PnpDevice | ? Status -eq 'OK' | ? FriendlyName -like '<patrón>' | ForEach-Object { Disable-PnpDevice -InstanceId $_.InstanceId -Confirm:$false; Start-Sleep -Seconds 2; Enable-PnpDevice -InstanceId $_.InstanceId -Confirm:$false }
Nota: requiere privilegios de administrador y puede interrumpir temporalmente el servicio asociado. - Actualiza o desinstala temporalmente el agente/controlador sospechoso (EDR/AV, backup, agentes de virtualización, multipath de almacenamiento, etc.).
- Amplía el pagefile para evitar caídas mientras corriges el origen (mitigación, no solución). En la mayoría de casos, tamaño administrado por el sistema funciona mejor. En servidores con picos fuertes, fija un máximo alto para evitar fragmentación.
Importante: Vaciar cachés de archivo (por ejemplo, la Standby list con RAMMap) no reduce el Paged Pool. Tampoco los “memory cleaners”.
Diagnóstico paso a paso (enfoque práctico)
Medir y alertar
Crea alertas tempranas para detectar crecimientos sostenidos.
Contador | Descripción | Umbrales recomendados |
---|---|---|
Memory\Pool Paged Bytes | Tamaño del Paged Pool en bytes. | Alerta si sube día a día sin estabilizarse (tendencia > 5–10% por día durante ≥3 días). |
Memory\Pool Nonpaged Bytes | Tamaño del Nonpaged Pool. | Útil para diferenciar si la fuga está en paged o nonpaged. |
Process(*)\Handle Count | Número de handles por proceso. | Escalada si algún proceso > 100k–200k y creciendo. |
Atajos de PowerShell para muestrear:
# Muestreo rápido (bytes)
Get-Counter '\Memory\Pool Paged Bytes','\Memory\Pool Nonpaged Bytes'
Top procesos por handles
Get-Process | Sort-Object Handles -Descending | Select-Object -First 15 Name,Id,Handles,PM,VM
Identificar la etiqueta (“pool tag”) que crece
Usa PoolMon (Windows Driver Kit) para ver qué etiqueta acumula memoria:
poolmon.exe -b -p
-b
: ordena por bytes.-p
: muestra solo Paged Pool.
Campos típicos de PoolMon:
Campo | Significado |
---|---|
Tag | La etiqueta de 4 caracteres asociada a las asignaciones. |
Type | P (Paged) / N (Nonpaged). |
Allocs/Frees | Número de asignaciones/liberaciones. |
Diff | Allocs – Frees. Un crecimiento anómalo indica fuga. |
Bytes | Memoria retenida por esa etiqueta. |
Mapear etiqueta → controlador/servicio
Una vez que conoces el tag, localiza el binario asociado. Métodos prácticos:
- Buscar en
pooltag.txt
(incluido en el WDK) por la etiqueta. - Rastrear en disco a qué controlador pertenece:
findstr /s /m /i SM00 C:\Windows\System32\drivers\*.sys
SustituyeSM00
por tu etiqueta. Si hay coincidencia, ese.sys
es un fuerte candidato.
Confirmar actividad anómala con trazas
Una traza corta puede revelar quién está asignando:
wpr -start Memory -filemode
rem Reproduce el crecimiento durante 5–10 min
wpr -stop C:\Temp\mem.etl
Abre mem.etl
en WPA para investigar “Heap Allocations”, “Pool Allocations” y correlacionar con módulos. RAMMap (Sysinternals) da una foto útil del uso pero no siempre etiqueta el origen con precisión.
Correlacionar con eventos y cambios
Las fugas suelen aparecer tras un cambio en drivers o agentes:
- Revisa Visor de eventos → System / Application / Setup por instalaciones/actualizaciones coincidentes con el inicio del problema.
- Compara con tu CMDB/inventario: nuevos agentes EDR/AV, filtros de backup, drivers de HBA/NIC, agentes de virtualización, utilidades de monitorización, etc.
# Eventos de instalación/actualización recientes
Get-WinEvent -FilterHashtable @{LogName='Setup'; StartTime=(Get-Date).AddDays(-14)} |
Select-Object TimeCreated,Id,LevelDisplayName,ProviderName,Message
Corregir en origen (la parte que realmente lo arregla)
- Actualiza o reemplaza el componente asociado a la etiqueta: drivers de red/almacenamiento, filtros de backup (VSS), antivirus/EDR, agentes de monitorización, componentes de virtualización (integrations, paravirtual NIC/Storage), software de DLP, etc.
- Si el problema empezó tras un parche del sistema o un driver, considera aplicar un KIR (Known Issue Rollback) o deshacer el cambio mientras llega el fix.
- Mantén Windows Server 2019 al día con el último Cumulative Update (CU) y Servicing Stack Update (SSU). Varios administradores han observado que actualizaciones recientes (enero de 2025 en adelante) estabilizaron el Paged Pool de forma significativa en entornos afectados.
Mitigaciones para “ganar tiempo” (mientras corriges)
No son la solución, pero reducen el riesgo de caída:
Mitigación | Cómo aplicarla | Notas |
---|---|---|
Reinicio controlado del servicio con fuga | Tarea programada fuera de horario con sc o PowerShell. | Evita reiniciar el host completo; valida impacto en dependencias. |
Reiniciar el dispositivo | Deshabilitar/habilitar el dispositivo (NIC, HBA) bajo ventana controlada. | Puede interrumpir temporalmente la red/IO. Úsalo con prudencia. |
Aumentar pagefile | Sistema gestionado o máximo alto predefinido. | Mitiga Memory Pressure y retrasos; no corrige la fuga. |
Lo que no conviene hacer
- No “capar” el Paged Pool con el registro. Claves heredadas como
PagedPoolSize
están desaconsejadas; Windows 2019 dimensiona dinámicamente.SystemPtesLimit
se relaciona con PTEs, no limita el Paged Pool, y tocarlo puede desestabilizar. - No desactivar el pagefile. Suele empeorar la fragmentación y reduce la resiliencia ante picos.
- No confiar en “limpiadores de RAM”. Pueden dañar el rendimiento y no liberan el Paged Pool.
- No vivir a base de reinicios del host. Solo ocultan el problema y aumentan el riesgo operativo.
Checklist operativo recomendado
- Parchear 2–3 servidores piloto con el CU/SSU actual y comparativa de 24–72 h.
- Vigilar con PerfMon:
Pool Paged Bytes
,Pool Nonpaged Bytes
, tendencia yHandle Count
. - Aislar con PoolMon: etiqueta → controlador/servicio. Confirmar con WPR/WPA.
- Mitigar sin reinicio: reinicia el servicio/driver; si procede, deshabilita/habilita el dispositivo fuera de horario.
- Corregir: actualizar o retirar el componente con fuga; si es bug de parche, aplicar KIR o CU que lo corrige.
- Validar: tras la corrección, el Paged Pool debe estabilizarse en carga habitual. Mantén alertas permanentes.
Parches y experiencias recientes
Administradores reportaron un inicio repentino de fugas de Paged Pool a finales de 2024 y principios de 2025 en entornos Windows Server 2019. En al menos un caso, instalar el Cumulative Update y el Servicing Stack Update de enero de 2025 detuvo el crecimiento sostenido del Paged Pool (estabilidad varios días en torno al ~18% de uso). Recomendación: mantener el sistema actualizado y validar siempre en un anillo piloto antes de desplegar masivamente.
Preguntas frecuentes (FAQ)
¿Puedo limitar el Paged Pool para que nunca pase de X GB?
No de forma soportada. Windows gestiona ese umbral dinámicamente y “caparlo” rompe supuestos del kernel. Lo correcto es eliminar la causa de la fuga.
¿Vaciar la Standby list o desactivar cachés ayuda?
No. La Standby list es memoria reutilizable de caché de archivos; limpiarla no devuelve memoria al Paged Pool.
¿Y si el problema es el Nonpaged Pool?
La metodología es análoga: PoolMon con -n
para ver nonpaged, mapea la etiqueta y corrige el controlador. Monitorea también Memory\Pool Nonpaged Bytes
.
¿Cómo dimensiono el pagefile?
Regla práctica: administrado por el sistema o tamaño máximo fijo suficiente para absorver picos (p. ej., entre 1× y 2× la RAM, según carga y volcados). Evita quedarte corto y evita cambiarlo a menudo.
¿Qué componentes suelen fugar?
Frecuentes: filtros de antivirus/EDR, controladores de backup y VSS, drivers de red/almacenamiento (incluidos paravirtuales/multipath), agentes de monitorización/telemetría y herramientas de DLP o cifrado.
Ejemplo de trabajo de campo (ficticio pero realista)
- Alertas:
Pool Paged Bytes
sube de 6 GB a 22 GB en 5 días. - PoolMon: etiqueta
SM00
con tipoP
y Diff creciendo; 12 GB retenidos. - Mapeo:
findstr
apunta a un driver de filtrado de red. - WPR/WPA: picos de asignación al mismo módulo al ritmo de 50–100 MB/min.
- Corrección: actualización del driver publicada por el fabricante; tras aplicarla, el Paged Pool se estabiliza < 6 GB con misma carga.
- Mitigación temporal: tarea programada que reiniciaba el servicio cada madrugada para evitar caídas durante la semana de pruebas.
Anexo: comandos útiles
PoolMon
poolmon.exe -b -p rem Top etiquetas (Paged)
poolmon.exe -b -n rem Top etiquetas (Nonpaged)
poolmon.exe -b -p -i 5 rem Refresco cada 5 s
Mapeo de etiqueta a binario
findstr /s /m /i <TAG> C:\Windows\System32\drivers\*.sys
findstr /s /m /i <TAG> C:\Windows\System32\*.dll
PerfMon rápido con PowerShell
# Muestra Paged/Nonpaged en MB cada 5 s
1..30 | % {
$c = Get-Counter '\Memory\Pool Paged Bytes','\Memory\Pool Nonpaged Bytes'
$p = [math]::Round(($c.CounterSamples | ? {$_.Path -like '*Paged Bytes'} |
Select -First 1 -ExpandProperty CookedValue)/1MB,2)
$n = [math]::Round(($c.CounterSamples | ? {$_.Path -like '*Nonpaged Bytes'} |
Select -First 1 -ExpandProperty CookedValue)/1MB,2)
"{0} | Paged={1} MB | Nonpaged={2} MB" -f (Get-Date), $p, $n
Start-Sleep 5
}
Crear Data Collector Set (DCS) mínimo
logman create counter PagedPoolDCS -c "\Memory\Pool Paged Bytes" "\Memory\Pool Nonpaged Bytes" ^
-f bin -o "C:\PerfLogs\PagedPool.blg" -si 00:01:00 -v mmddhhmm -rf 24:00
logman start PagedPoolDCS
Reiniciar un servicio con ventana de mantenimiento
$svc = 'NombreServicio'
if ((Get-Service $svc).Status -eq 'Running') {
Write-Host "Reiniciando $svc..."
Restart-Service $svc -Force -ErrorAction Stop
}
Anexo: plantillas y umbrales de alerta
Señal | Condición | Acción sugerida |
---|---|---|
Tendencia Paged Pool | > 5%/día durante ≥ 3 días | Ejecutar PoolMon. Abrir ticket de driver/servicio sospechoso. |
Diff en PoolMon | Positivo y creciente en una misma etiqueta | Mapear etiqueta → binario. Revisión de versión y cambios recientes. |
Handles por proceso | > 200k y subiendo | Perfilado del proceso. Revisar hooks y filtros cargados. |
Pagefile comprometido | > 80% sostenido | Aumentar tamaño. Plan de corrección prioritario. |
Buenas prácticas preventivas
- Anillos de despliegue: primero piloto, luego anillo limitado, y por último producción completa. Métricas comparativas antes/después.
- Inventario de drivers y agentes: versión, fecha de instalación, proveedor y hash. Te ahorrará horas al correlacionar problemas.
- Documenta etiquetas recurrentes: guarda capturas de PoolMon y mapeos; muchas fugas vuelven con variantes.
- Pagefile estable: evita crecer/disminuir constantemente; en VMs, considera fijar un máximo alto para impedir fragmentación.
Conclusión
Cuando el Paged Pool crece sin freno en Windows Server 2019, el sistema está “gritando” que un controlador o servicio fuga memoria. No hay un límite soportado que puedas imponer; la vía robusta es identificar la etiqueta con PoolMon, mapearla a su binario, y corregir el componente (actualización, rollback o retirada). Para cortar el síntoma sin reiniciar el host, reinicia el servicio o driver implicado y amplía el pagefile como mitigación temporal. Mantén el sistema con los CUs y SSUs más recientes y valida siempre en pilotos: muchos entornos han visto estabilizarse el Paged Pool tras actualizar. Con monitoreo continuo, anillos de cambio y el flujo de trabajo aquí descrito, puedes devolver estabilidad a tus servidores y evitar reinicios de emergencia.