Problemas con el contador Pool Paged Failures

Hash: SHA1

Un problema interesante, dadas las características del sistema. La causa puede
ser una fuga de memoria en modo kernel. Parece que algún componente del kernel,
controlador de sistema o controlador de terceros reserva cierta cantidad de
memoria paginada y no la libera cuando ha terminado de trabajar con ella. Este
patrón se repite con el tiempo, produciendo una acumulación de memoria paginada
no devuelta al sistema y, por tanto, fallos y la consiguiente ralentización.

¿Ese Windows 2000 está al día con las actualizaciones?

El contador "Pool Paged Failures" acumula el número de veces que fallan las
peticiones de memoria paginada del kernel, por consiguiente no hay forma de
"bajarlo". No pasa nada si se mantiene constante, pero su crecimiento indica sin
duda que "algo raro está sucediendo".

¿El contador "Pool Paged Bytes" crece de forma más evidente cuando ocurre el
problema? ¿Después disminuye muy poco o se mantiene? ¿En qué rango de valores se
mueve aproximadamente? El servicio Servidor suele registrar las incidencias de
falta de memoria paginada del sistema cuando necesita reservar memoria paginada y
no puede. ¿Aparece algún error en el registro de sucesos de Sistema con
identificador 2020 y origen Srv?

Ramón Sola / / MVP Windows - Shell/User
Para obtener la dirección correcta no hacen falta los sellos.
Por favor, usar el correo sólo para cuestiones ajenas a los
grupos de noticias, gracias.

Un buen día, Simon Cascante () tuvo la irrefrenable necesidad
de escribir:

Hola a todos!!

Tenemos un servidor Windows 2000 SP4 con SQL Server 2000 SP4, al
realizar procesos de cargas de datos, el servidor tiende a ponerse
lento, al revisar el System Monitor el contador "Pool Paged Failures"
crece hasta valores superiores a los 20,000, cuanto terminan los
proceso de carga este valor no baja. Existe alguna forma bajar el
valor Pool Paged Failures?

Características del servidor:
4 procesadores
8 GB de memoria
20 GB memoria virtual

Saludos,

On 2 feb, 23:36, Ramón Sola [MVP Windows - Shell/User]
wrote:

Hash: SHA1

Un problema interesante, dadas las características del sistema. La causa puede
ser una fuga de memoria en modo kernel. Parece que algún componente del kernel,
controlador de sistema o controlador de terceros reserva cierta cantidad de
memoria paginada y no la libera cuando ha terminado de trabajar con ella. Este
patrón se repite con el tiempo, produciendo una acumulación de memoria paginada
no devuelta al sistema y, por tanto, fallos y la consiguiente ralentización.

¿Ese Windows 2000 está al día con las actualizaciones?

El contador "Pool Paged Failures" acumula el número de veces que fallan las
peticiones de memoria paginada del kernel, por consiguiente no hay forma de
"bajarlo". No pasa nada si se mantiene constante, pero su crecimiento indica sin
duda que "algo raro está sucediendo".

¿El contador "Pool Paged Bytes" crece de forma más evidente cuando ocurre el
problema? ¿Después disminuye muy poco o se mantiene? ¿En qué rango de valores se
mueve aproximadamente? El servicio Servidor suele registrar las incidencias de
falta de memoria paginada del sistema cuando necesita reservar memoria paginada y
no puede. ¿Aparece algún error en el registro de sucesos de Sistema con
identificador 2020 y origen Srv?

Ramón Sola / / MVP Windows - Shell/User
Para obtener la dirección correcta no hacen falta los sellos.
Por favor, usar el correo sólo para cuestiones ajenas a los
grupos de noticias, gracias.

Un buen día, Simon Cascante () tuvo la irrefrenable necesidad
de escribir:

> Hola a todos!!

> Tenemos un servidor Windows 2000 SP4 con SQL Server 2000 SP4, al
> realizar procesos de cargas de datos, el servidor tiende a ponerse
> lento, al revisar el System Monitor el contador "Pool Paged Failures"
> crece hasta valores superiores a los 20,000, cuanto terminan los
> proceso de carga este valor no baja. Existe alguna forma bajar el
> valor Pool Paged Failures?

> Características del servidor:
> 4 procesadores
> 8 GB de memoria
> 20 GB memoria virtual

> Saludos,

¿Ese Windows 2000 está al día con las actualizaciones?
R/ Si esta actualizado.

¿El contador "Pool Paged Bytes" crece de forma más evidente cuando
ocurre el problema?
/R Si de forma constante, que al detener el servicio de MSOLAP el
crecimiento se detiene.

¿Después disminuye muy poco o se mantiene?
/R No disminuye sigue creciendo, has que se detiene el servicio MSOLAP

¿En qué rango de valores se mueve aproximadamente?
R/ Si no se detiene ha llegado hasta 25,000

¿Aparece algún error en el registro de sucesos de Sistema con
identificador 2020 y origen Srv?
R/ Si el error es el siguiente:
The server was unable to allocate from the system paged pool because
the pool was empty.

Gracias por tu ayuda!

Atención, el mensaje me ha salido bastante largo. Considero que hay que explicar
bastantes cosas para que se pueda comprender cómo funciona el método de
investigación.

La herramienta Poolmon (Pool Monitor) permite investigar este tipo de problemas.
En modo kernel, todas las asignaciones de memoria se caracterizan por una
etiqueta de cuatro bytes, habitualmente en forma de caracteres alfanuméricos.
Cada controlador o componente del sistema emplea un conjunto de etiquetas, que es
más o menos extenso según la diversidad de sus estructuras de datos o sus
"subcomponentes". Poolmon muestra, en tiempo real, estadísticas de uso de memoria
en modo kernel basándose en esas etiquetas.

Para que Poolmon funcione, el etiquetado de memoria tiene que estar activado.
Existen dos posibilidades:
* Ejecutar la herramienta Gflags y marcar la casilla 'Enable Pool Tagging'.
* Variar el valor GlobalFlag de la clave
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager, cambiándolo
por 0x400 hexadecimal (1024 decimal).
Debe reiniciarse el sistema después de hacer uno de estos cambios.

Poolmon y Gflags se pueden conseguir en este paquete:

Windows 2000 SP4 Support Tools
http://www.microsoft.com/windows200...tools.mspx

Descarga Sp4supporttools.exe y ejecútalo. Indica una carpeta de destino en la que
se extraerán los archivos que forman parte del paquete. Poolmon.exe y Gflags.exe
están dentro del archivo Support.cab.

Ejecuta Poolmon.exe. Aparecerá una ventana de texto con información diversa:

Memory: 522992K Avail: 106788K PageFlts: 4292 InRam Krnl: 1784K P:66728K
Commit: 479612K Limit:1279036K Peak: 639520K Pool N:12756K P:75560K
Tag Type Allocs Frees Diff Bytes Per Alloc

waR Nonp 19 ( 0) 19 ( 0) 0 0 ( 0) 0
( Paged 207 ( 0) 207 ( 0) 0 0 ( 0) 0
1394 Nonp 1 ( 0) 0 ( 0) 1 520 ( 0) 520
8042 Nonp 2 ( 0) 2 ( 0) 0 0 ( 0) 0
8042 Paged 2 ( 0) 2 ( 0) 0 0 ( 0) 0
ACPI Nonp 10 ( 0) 10 ( 0) 0 0 ( 0) 0
AEC Paged 6 ( 0) 6 ( 0) 0 0 ( 0) 0
AECd Nonp 7 ( 0) 7 ( 0) 0 0 ( 0) 0
[...]

La cabecera muestra varios campos. De ahí nos interesa el campo P de la segunda
línea (Pool, Paged). La tabla contiene información diversa organizada por
etiquetas:
* Tag: etiqueta.
* Type: Paged si pertenece a memoria paginada, Nonp si pertenece a memoria no
paginada.
* Allocs: total de solicitudes de memoria que han sido satisfechas
(asignaciones).
* Frees: total de liberaciones de memoria.
* Diff: diferencia entre Allocs y Frees, es decir, número de bloques de memoria
que pueden estar en uso actualmente.
* Bytes: tamaño total de las asignaciones de memoria actuales.
* Per Alloc: división de Diff entre Bytes, es decir, una media del tamaño por
asignación de memoria.
Los números entre paréntesis indican la variación del valor al que acompañan
desde la última vez que se actualizó la información en pantalla.

Pulsa la tecla P dos veces para mostrar sólo las etiquetas asociadas a memoria
paginada (Type: Paged). Después pulsa la tecla D para ordenar la información por
la columna Diff de manera descendente. Entonces reproduce las condiciones del
problema y observa la evolución del uso de memoria paginada en la pantalla.

Deberías ver cómo crecen desmesuradamente el uso de memoria paginada y el Diff de
al menos una etiqueta. En un momento dado, el uso de memoria paginada llegará al
límite, comenzarán a fallar algunas operaciones y el sistema se ralentizará.
Además, en cuanto cesa la acción, el valor Diff que había crecido tanto ya no
descenderá en una proporción similar, revelando así la posible fuga: memoria que
se solicita, se utiliza y, debido a errores de programación, nunca se devuelve al
sistema.

Una vez identificada la etiqueta bajo la que se camufla la fuga de memoria, hay
que hallar el controlador o subsistema pertenece. Los últimos DDKs (Driver
Development Kits) y en el paquete de herramientas de depuración (Debugging Tools
for Windows) traen un archivo de texto denominado Pooltag.txt con etiquetas "bien
conocidas" de subsistemas del núcleo, controladores propios de Windows y algunos
controladores de terceros.

El método que sugiere el artículo 298102 de la Knowledge Base de Microsoft se
puede aplicar si la etiqueta no consta en el archivo Pooltag.txt. Consiste en
recorrer los archivos *.sys del disco duro, especialmente
%Systemroot%\System32\Drivers, buscando la etiqueta como una cadena de texto. Se
intenta reducir los falsos positivos poniendo una 'h' minúscula delante de la
etiqueta, ya que su código ASCII, es decir, 104 en decimal o 0x68 en hexadecimal,
es el código de operación de la instrucción "PUSH <valor_inmediato>" en la
arquitectura x86.


Más información:

Cómo usar el monitor de grupos de memoria (Poolmon.exe) para solucionar problemas
de pérdidas de memoria en el modo de núcleo
http://support.microsoft.com/kb/177415/es

How to find pool tags that are used by third-party drivers
http://support.microsoft.com/kb/298102/en-us


Ramón Sola / / MVP Windows - Shell/User
Para obtener la dirección correcta no hacen falta los sellos.
Por favor, usar el correo sólo para cuestiones ajenas a los
grupos de noticias, gracias.

Un buen día, Simon Cascante () tuvo la irrefrenable necesidad
de escribir:

¿Ese Windows 2000 está al día con las actualizaciones?
R/ Si esta actualizado.

¿El contador "Pool Paged Bytes" crece de forma más evidente cuando
ocurre el problema?
/R Si de forma constante, que al detener el servicio de MSOLAP el
crecimiento se detiene.

¿Después disminuye muy poco o se mantiene?
/R No disminuye sigue creciendo, has que se detiene el servicio MSOLAP

¿En qué rango de valores se mueve aproximadamente?
R/ Si no se detiene ha llegado hasta 25,000

¿Aparece algún error en el registro de sucesos de Sistema con
identificador 2020 y origen Srv?
R/ Si el error es el siguiente:
The server was unable to allocate from the system paged pool because
the pool was empty.

Gracias por tu ayuda!

On 8 feb, 14:54, Ramón Sola [MVP Windows - Shell/User]
wrote:

Atención, el mensaje me ha salido bastante largo. Considero que hay que explicar
bastantes cosas para que se pueda comprender cómo funciona el método de
investigación.

La herramienta Poolmon (Pool Monitor) permite investigar este tipo de problemas.
En modo kernel, todas las asignaciones de memoria se caracterizan por una
etiqueta de cuatro bytes, habitualmente en forma de caracteres alfanuméricos.
Cada controlador o componente del sistema emplea un conjunto de etiquetas, que es
más o menos extenso según la diversidad de sus estructuras de datos o sus
"subcomponentes". Poolmon muestra, en tiempo real, estadísticas de uso de memoria
en modo kernel basándose en esas etiquetas.

Para que Poolmon funcione, el etiquetado de memoria tiene que estar activado.
Existen dos posibilidades:
* Ejecutar la herramienta Gflags y marcar la casilla 'Enable Pool Tagging'.
* Variar el valor GlobalFlag de la clave
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager, cambiándolo
por 0x400 hexadecimal (1024 decimal).
Debe reiniciarse el sistema después de hacer uno de estos cambios.

Poolmon y Gflags se pueden conseguir en este paquete:

Windows 2000 SP4 Support Toolshttp://www.microsoft.com/windo...4/suppo...

Descarga Sp4supporttools.exe y ejecútalo. Indica una carpeta de destino en la que
se extraerán los archivos que forman parte del paquete. Poolmon.exe y Gflags.exe
están dentro del archivo Support.cab.

Ejecuta Poolmon.exe. Aparecerá una ventana de texto con información diversa:

Memory: 522992K Avail: 106788K PageFlts: 4292 InRam Krnl: 1784K P:66728K
Commit: 479612K Limit:1279036K Peak: 639520K Pool N:12756K P:75560K
Tag Type Allocs Frees Diff Bytes Per Alloc

waR Nonp 19 ( 0) 19 ( 0) 0 0 ( 0) 0
( Paged 207 ( 0) 207 ( 0) 0 0 ( 0) 0
1394 Nonp 1 ( 0) 0 ( 0) 1 520 ( 0) 520
8042 Nonp 2 ( 0) 2 ( 0) 0 0 ( 0) 0
8042 Paged 2 ( 0) 2 ( 0) 0 0 ( 0) 0
ACPI Nonp 10 ( 0) 10 ( 0) 0 0 ( 0) 0
AEC Paged 6 ( 0) 6 ( 0) 0 0 ( 0) 0
AECd Nonp 7 ( 0) 7 ( 0) 0 0 ( 0) 0
[...]

La cabecera muestra varios campos. De ahí nos interesa el campo P de la segunda
línea (Pool, Paged). La tabla contiene información diversa organizada por
etiquetas:
* Tag: etiqueta.
* Type: Paged si pertenece a memoria paginada, Nonp si pertenece a memoria no
paginada.
* Allocs: total de solicitudes de memoria que han sido satisfechas
(asignaciones).
* Frees: total de liberaciones de memoria.
* Diff: diferencia entre Allocs y Frees, es decir, número de bloques de memoria
que pueden estar en uso actualmente.
* Bytes: tamaño total de las asignaciones de memoria actuales.
* Per Alloc: división de Diff entre Bytes, es decir, una media del tamaño por
asignación de memoria.
Los números entre paréntesis indican la variación del valor al que acompañan
desde la última vez que se actualizó la información en pantalla.

Pulsa la tecla P dos veces para mostrar sólo las etiquetas asociadas a memoria
paginada (Type: Paged). Después pulsa la tecla D para ordenar la información por
la columna Diff de manera descendente. Entonces reproduce las condiciones del
problema y observa la evolución del uso de memoria paginada en la pantalla.

Deberías ver cómo crecen desmesuradamente el uso de memoria paginada y el Diff de
al menos una etiqueta. En un momento dado, el uso de memoria paginada llegará al
límite, comenzarán a fallar algunas operaciones y el sistema se ralentizará.
Además, en cuanto cesa la acción, el valor Diff que había crecido tanto ya no
descenderá en una proporción similar, revelando así la posible fuga: memoria que
se solicita, se utiliza y, debido a errores de programación, nunca se devuelve al
sistema.

Una vez identificada la etiqueta bajo la que se camufla la fuga de memoria, hay
que hallar el controlador o subsistema pertenece. Los últimos DDKs (Driver
Development Kits) y en el paquete de herramientas de depuración (Debugging Tools
for Windows) traen un archivo de texto denominado Pooltag.txt con etiquetas "bien
conocidas" de subsistemas del núcleo, controladores propios de Windows y algunos
controladores de terceros.

El método que sugiere el artículo 298102 de la Knowledge Base de Microsoft se
puede aplicar si la etiqueta no consta en el archivo Pooltag.txt. Consiste en
recorrer los archivos *.sys del disco duro, especialmente
%Systemroot%\System32\Drivers, buscando la etiqueta como una cadena de texto. Se
intenta reducir los falsos positivos poniendo una 'h' minúscula delante de la
etiqueta, ya que su código ASCII, es decir, 104 en decimal o 0x68 en hexadecimal,
es el código de operación de la instrucción "PUSH <valor_inmediato>" en la
arquitectura x86.

Más información:

Cómo usar el monitor de grupos de memoria (Poolmon.exe) para solucionar problemas
de pérdidas de memoria en el modo de núcleohttp://support.microsoft.com/kb/177415/es

How to find pool tags that are used by third-party drivershttp://support.microsoft.com...8102/en-us

Ramón Sola / / MVP Windows - Shell/User
Para obtener la dirección correcta no hacen falta los sellos.
Por favor, usar el correo sólo para cuestiones ajenas a los
grupos de noticias, gracias.

Un buen día, Simon Cascante () tuvo la irrefrenable necesidad
de escribir:

> ¿Ese Windows 2000 está al día con las actualizaciones?
> R/ Si esta actualizado.

> ¿El contador "Pool Paged Bytes" crece de forma más evidente cuando
> ocurre el problema?
> /R Si de forma constante, que al detener el servicio de MSOLAP el
> crecimiento se detiene.

> ¿Después disminuye muy poco o se mantiene?
> /R No disminuye sigue creciendo, has que se detiene el servicio MSOLAP

> ¿En qué rango de valores se mueve aproximadamente?
> R/ Si no se detiene ha llegado hasta 25,000

> ¿Aparece algún error en el registro de sucesos de Sistema con
> identificador 2020 y origen Srv?
> R/ Si el error es el siguiente:
> The server was unable to allocate from the system paged pool because
> the pool was empty.

> Gracias por tu ayuda!

Estimado Ramón!

Muchísimas gracias por la ayuda!

Me fué muy útil TODA la información que enviaste.

Saludos!

¿Resolviste el problema? ¿Qué estaba provocando la fuga de memoria?

Ramón Sola / / MVP Windows - Shell/User
Para obtener la dirección correcta no hacen falta los sellos.
Por favor, usar el correo sólo para cuestiones ajenas a los
grupos de noticias, gracias.

Un buen día, Simon Cascante () tuvo la irrefrenable necesidad
de escribir:

Estimado Ramón!

Muchísimas gracias por la ayuda!

Me fué muy útil TODA la información que enviaste.

Saludos!