Memoria Paged e NonPaged Pool – Come identificare un memory leak

itentblg — Mon, 11 May 2009 02:00:00 GMT

In questo post vedremo come identificare le problematiche legate ad un esaurimento di due specifiche risorse Kernel: Paged Pool e NonPaged Pool.
Vi consiglio di leggere il post di Fabio Lavatelli per una visione esaustiva della memoria: Kernel Memory Overview.

Memoria Paged e NonPaged Pool

All’avvio del computer, il Memory Manager crea dinamicamente due memorie pool di dimensione fissa per tutto il periodo in cui il Sistema Operativo rimane attivo: queste due pool sono conosciute come Paged Pool e NonPaged Pool.

Le dimensioni di queste pool, determinate all'avvio, dipendono da una serie di fattori: alcuni di questi possono essere modificati attraverso specifiche chiavi di registry, mentre altri dipendono dall’hardware specifico del computer, come la quantità di memoria fisica.

Entrambe le pool possono raggiungere un valore massimo teorico dipendente dall’architettura del sistema operativo:

Tipo Pool	Sistemi a 32-Bit (x86)	Sistemi a 64-Bit (x64)
NonPaged	256 MB (Windows 2000, XP e 2003) 128 MB (Con opzione /3GB abilitata al boot)	128 GB
Paged	491,875 MB (Windows 2000 e Windows XP) 650,000 MB (Windows Server 2003)	128GB

Nel caso sia abilitata l’opzione /3GB nel file boot.ini la dimensione massima teorica della NonPaged Pool è dimezzata. Questo è dovuto alla gestione nel Sistema Operativo della memoria virtuale: sono dedicati 3 Gigabyte alla parte applicativa e solo 1 Gigabyte alla parte kernel.

I Sistemi Operativi a 64 bit (x64) presentano limiti di memoria virtuale superiori di diversi ordini di grandezza rispetto a sistemi a 32 bit (x86), perciò un'eventuale saturazione della memoria disponibile avverrebbe in tempi più elevati.

La sostanziale differenza tra le due tipologie di pool, come evidenzia il nome, è che la Paged Pool può essere paginata su disco, mentre la NonPaged Pool è sempre residente in memoria.

I driver utilizzano la NonPaged Pool per tutte quelle operazioni eseguite ad un Interrupt Request Level (IRQL) troppo elevato per ammettere paginazione.
L'IRQL definisce la priorità a cui il processore sta operando, maggiori informazioni sono disponibili nel seguente articolo: Scheduling, Thread Context, and IRQL

Eventi SRV 2019 e 2020

Nel caso in cui un driver abbia un funzionamento anomalo, potrebbe allocare memoria Pool senza mai rilasciarla arrivando alla saturazione di tutto lo spazio a disposizione: questo fenomeno è chiamato memory leak.

In questo tipo di scenario, generalmente troviamo nel Log degli Eventi di Sistema i seguenti 2 eventi specifici.
L'evento 2019 si riferisce all'esaurimento della NonPaged pool:

Type: Error
Date: <date>
Time: <time>
Event ID: 2019
Source: Srv
User: N/A
Computer: <ComputerName>
Details: The server was unable to allocate from the system NonPaged pool because the pool was empty.

Mentre l'evento 2020 riguarda l'esaurimento della Paged Pool:

Type: Error
Date: <date>
Time: <time>
Event ID: 2020
Source: Srv
User: N/A
Computer: <ComputerName>
Details: The server was unable to allocate from the system Paged pool because the pool was empty

In alcuni scenari specifici di memory leak, gli eventi 2019 e 2020 non sono presenti nel Registro Eventi, ma sono loggati molti errori 333 - Application Popup:

Type: Error
Date: <date>
Time: <time>
Event ID: 333
Source: Application Popup
User: N/A
Computer: <ComputerName>
Details: An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system's image of the Registry

Maggiori informazioni riguardo questo scenario sono spiegati nel post Analizzare l’evento “Application Popup 333”

Analizzare un Memory Leak

Il comportamento del Sistema Operativo in presenza di un memory leak è imprevedibile: si possono registrare hang, crash di applicazioni o BlueScreen (bugcheck 0x0000041 MUST_SUCCEED_POOL_EMPTY).

Il performance monitor permette di verificare lo stato della Memoria Pool con i seguenti counter:

Counter	Description
Memory\Paged Pool Bytes	Indica il numero di byte allocati nella Paged Pool di sistema
Memory\Non Paged Pool Bytes	Indica il numero di byte allocati nella NonPaged Pool di sistema

Il grafico seguente illustra un andamento tipo di un memory leak relativo alla NonPaged Pool:

FIG 1 - Andamento tipico di un memory leak relativo alla NonPaged Pool.

La NonPaged Pool allocata, indicata in MegaByte, è al di sotto del valore massimo teorico di 256 MB, ma presenta un andamento crescente che indica un tipico caso in cui un driver non stia rilasciando la memoria allocata.

La crescita può essere variabile in funzione del tempo, e per questo la finestra temporale di monitoring dovrà essere modulata proporzionalmente alla rapidità del leak.

Il grafico seguente illustra un altro andamento tipo di saturazione di memoria relativo alla NonPaged Pool:

FIG 2 - Andamento variabile relativo alla NonPaged Pool.

L’andamento non risulta crescente, ma può indicare ugualmente la presenza di problemi dovuti al raggiungimento del limite massimo di memoria Pool disponibile. In questa situazione non abbiamo un vero e proprio memory leak, ma una saturazione della NonPaged Pool che richiede un tuning manuale di specifiche chiavi di registry.

I due andamenti riportati valgono per entrambe le tipologie di memoria Pool anche se i limiti più stringenti e che presentano più problemi sono relativi alla memoria NonPaged Pool.

Nei successivi post vedremo nel dettaglio come approfondire e risolvere:

Problemi di memory leak
Problemi di saturazione della memoria

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

Supporto Tecnico Enterprise : Pool Memory

Memoria Paged e NonPaged Pool – Come identificare un memory leak