Supporto Tecnico Enterprise : Performance

Memoria Paged e NonPaged Pool – Come risolvere un memory leak

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

In questo post vedremo come risolvere un leak di memoria e identificare il driver responsabile.
Vi consiglio di leggere il post Memoria Paged e NonPaged Pool – Come identificare un memory leak per verificare che effettivamente siamo in presenza di un leak di memoria.

Utilizzare il PoolMon

L’allocazione di una quantità di byte in una delle memorie Pool utilizza un sistema di tagging. Un TAG è un identificativo di quattro byte associato ad ogni porzione di memoria Pool allocata.

Il TAG viene specificato da un driver, durante l’allocazione della memoria, attraverso la routine ExAllocatePoolWithTag. I seguenti tre parametri, devono essere specificati durante la chiamata a questa routine:

PoolType: Il tipo di memoria Pool da allocare (Paged o NonPaged)
NumberofBytes: Il numero di byte da allocare con la richiesta
TAG: il Pool TAG, rappresentato attraverso quattro caratteri ASCII

L’obiettivo dei Pool TAG è quello di fornire un meccanismo, che attraverso degli identificatore potenzialmente univoci, consenta di stabilire quali driver stanno allocando la memoria. Inoltre, durante la fase di sviluppo di un driver, i TAG sono utili per poter differenziare le diverse tipologie di allocazione, rendendo più selettiva un’eventuale investigazione attraverso il tool Driver Verifier.

Identificare il TAG e byte allocati

Per poter verificare quanti byte sono allocati da un determinato TAG occorrerà utilizzare il tool poolmon.exe, che è possibile recuperare dalla cartella \Support\Tools del CD d’installazione del Sistema Operativo.

Questo tool consente di ottenere un report di tutti i TAG della Paged e Non Paged Pool con i relativi byte allocati.
In Windows Server 2003 il Pool tagging è già abilitato, mentre in Windows Server 2000 e Windows XP è necessario abilitarlo attraverso il tool Gflags.exe presente sempre nella cartella \Support\Tools del supporto di installazione, o modificando le opportune chiavi di registro.

Per maggiori informazioni sull'utilizzo di questo tool potete consultare l’articolo How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kernel mode memory leaks

La seguente immagine illustra un esempio di output relativo al poolmon:

FIG 1 - Output del tool Poolmon.exe

I campi fondamentali per la nostra analisi sono evidenziati in rosso:

Tag: Rappresenta il TAG che identifica l'allocazione.
Type: Specifica se la memoria è stata allocata in Paged (Paged) o Nonpaged (Nonp) pool.
Bytes: Quantità di memoria allocata, in bytes, per il corrispondente TAG

Possiamo, dunque, utilizzare i seguenti passi per raccogliere l'output del poolmon in una finestra temporale di nostro interesse:

Copiare il file "PoolMon.exe" in "C:\PoolMon", inserendo nella stessa cartella il tool sleep.exe
Aprire una console dei comandi da "Start" --> "All programs" --> "Accessories" --> "Command Prompt"
Spostare il prompt in C:\PoolMon
Per avere una lettura dei dati ogni 15 minuti (per 2 giorni circa), digitare il seguente comando:
for /l %i in (1,1,200) do ( poolmon -n log-%i.txt && sleep 900000 )
Nella cartella "C:\PoolMon" verranno creati i vari file di log.

Il tool sleep.exe utilizzato è fornito in allegato al presente post.

Determinare la frequenza di campionamento

Sleep.exe richiede un parametro che indica il periodo d'attesa in millisecondi tra due esecuzioni del ciclo for.
Nell’esempio di script riportato sopra, abbiamo il parametro 900’000 che è ottenuto moltiplicando: 15 minuti * 60 secondi * 1000 millisecondi per ottenere una pausa tra una lettura e l’altra di 15 minuti.

Considerando i 200 cicli impostati ogni 15 minuti, abbiamo un campionamento di circa 2 giorni calcolato da: 15 minuti/campione * 200 campioni = 3000 minuti totali / 60 = 50 ore totali / 24 = 2,08 giorni.

Possiamo modificare il numero di cicli e la frequenza di campionamento in base alla rapidità del leak che abbiamo identificato.

Al termine del periodo di monitoring, avremo dunque 200 file di testo, che iniziano con log1.txt fino a log200.txt nel nostro esempio.

Copiando questi dati in un foglio Excel ed ordinandoli in base al tipo (Nonp o Paged) e in ordine decrescente rispetto ai byte allocati, saremo in grado di determinare la variazione di allocazione dei TAG in funzione del tempo, identificando quali, in particolare, stanno occupando di più.

FIG 2 - Schermata di Excel per l'ordinamento dei TAG.

Analizzare i log

Avremo risultati di questo tipo:

NonPaged Pool

NonPaged - Log 1	NonPaged - Log 10	NonPaged - Log 20

Paged Pool

Paged - Log 1	Paged - Log 10	Paged - Log 20

Come possiamo notare è evidente un notevole incremento del TAG Pipo per la Nonpaged pool.
Analizzando anche i restanti log abbiamo infatti il seguente andamento:

FIG 3 - Andamento della Nonpaged pool allocata dal TAG Pipo.

Come è possibile notare è presente un leak sul TAG Pipo. Ora che abbiamo identificato il TAG che sta alla base del memory leak, come possiamo identificarne il driver corrispondente?

Identificare il driver

L’elenco di tutti i TAG utilizzati per le allocazioni nella memoria Pool sono disponibili nel file Pooltag.txt
Questo file contiene l’identificativo di tutti i componenti Kernel-mode e driver rilasciati con i Sistemi Operativi Windows.

E’ disponibile per il download e l’installazione all’interno dei Debugging Tools for Windows:

Un esempio del contenuto del file Pooltag.txt è riportato di seguito:

8042 - i8042prt.sys - PS/2 kb and mouse
AdSv - vmsrvc.sys   - Virtual Machines Additions Service
ARPC - atmarpc.sys - ATM ARP Client
ATMU - atmuni.sys   - ATM UNI Call Manager
ACPI - acpi.sys     - ACPI
Afd? - afd.sys      - AFD objects
AfdA - afd.sys      - Afd EA buffer

Se il TAG che causa il leak di memoria non è contenuti nell’elenco, vi consiglio di effettuare una ricerca nella nostra Knowledge Base, in modo da verificare la presenza di eventuali problemi conosciuti e installare la relativa hotfix.

Se invece, come nel caso del nostro esempio, il TAG non è Microsoft non sarà presente nell'elenco.
In questo caso possiamo utilizzare il comando findstr, valido per ciascuna versione di Windows, che potrà essere eseguito come indicato di seguito:

Aprire una console dei comandi da "Start" --> "All programs" --> "Accessories" --> "Command Prompt"
Spostarsi nella cartella %systemroot%\system32\drivers
Digitare il comando
findstr /m /l <tag> *.sys
Verificare l'output restituito dal comando

In questo screenshot è evidenziata la ricerca per il TAG Pipo:

Come possiamo notare è restituito il driver corrispondente al TAG specificato “Pipo”.

In questo caso occorrerà verificare un'eventuale versione aggiornata del driver Pippo.sys, o eventualmente contattare il fornitore del software segnalando la problematica.

Conclusione

Alla luce di quanto visto fino ad ora, se stiamo evidenziando un leak di memoria sul nostro sistema potremo identificarne la potenziale causa attraverso i seguenti passi:

Monitorare i byte allocati da ciascun TAG durante una finestra temporale adeguata al nostro leak, attraverso il tool poolmon.exe
Evidenziare eventuali allocazioni che variano proporzionalmente al tempo in costante crescita
Stabilire su che tipo di pool è presente il leak (Paged o Nonpaged)
Stabilire il driver associato al TAG che sta causando il leak
Ricercare eventuali problemi noti, o analizzare la problematica con il fornitore del driver

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platform Support

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

SQL Server - Facciamo quattro conti con i dischi

itentblg — Mon, 09 Feb 2009 03:00:00 GMT

Mi capita spesso di incontrare evidenti problemi di performance sui vari volumi utilizzati da SQL Server, sia per un’errata scelta del livello di RAID sia per un errato dimensionamento del numero di dischi necessari a soddisfare la quantità di operazioni al secondo richieste dai vari database.

Le moderne Storage Area Network dispongono di sistemi di gestione dei volumi che praticamente in tempo reale possono riallocare su meccaniche completamente differenti,anche come numero, quello che dal sistema operativo viene visto come disco (la lettera dell’unità): inoltre la grande quantità di memoria cache installata garantisce prestazioni teoriche tali da non far sorgere preoccupazioni, tant’è che per volumi dedicati alla “semplice” di repository normalmente si può risparmiare su qualche disco.

La tendenza attuale inoltre è quella che porta a vedere la SAN più come una riserva di GigaByte e TeraByte di spazio, piuttosto che come un sistema dal quale si possono estrarre notevoli performance, perché normalmente si chiede “Ho bisogno di XXX Gb di spazio” e non “Ho bisogno di XXX Gb di spazio che sia in grado di garantirmi YYY operazioni di I/O al secondo”.

E qui si inserisce un aspetto molto importante da considerare: SQL Server ( e anche Exchange ) all’avvio richiede l’apertura dei suoi file di database in modalità WriteThrouh, tramite il flag FILE_FLAG_WRITE_THROUGH e FILE_FLAG_NO_BUFFER della funzione Windows CreateFile, ignorando quindi qualsiasi tipo di cache, da quella del sistema operativo a quella che può essere presente sul disco. Solo alcuni sistemi molto avanzati possono essere configurati per ignorare questi due flag e fare in modo che SQL Server “veda” la cache come “stable media” (praticamente un disco) garantendo così elevate performance, ma la maggior parte delle installazioni oggi presenti non è in grado: e qui iniziano i problemi perché dobbiamo fare i conti, nel vero senso del termine, con le pure caratteristiche fisiche dei dischi che compongono gli array (spesso uno solo) dove risiedono i file di dati di SQL Server.

Vediamo quindi un generico disco SCSI di ultima generazione cosa può garantirci come numero di operazioni di I/O prima di iniziare ad accodare le richieste e allungare i tempi di risposta: il riferimento dei nostri calcoli è un Seagate Cheetah 15.5K, disponibile nei tagli 74Gb, 146Gb e 300Gb, i più comuni (purtroppo … come dimensione del singolo) usati oggi all’interno delle SAN.

Il disco in questione presenta per i tre formati le seguenti caratteristiche:

latenza media di 2ms (considerata come la metà del tempo necessario per compiere un intera rotazione dei piatti)
Scrittura Random 4.0ms
Lettura Random 3.5ms
Scrittura Sequenziale 0.4ms
Lettura Sequenziale 0.2ms

Tenendo presente che un disco inizia a dare evidenti segni di accodamento quando viene usato in modo continuativo oltre l’ 85% delle sue capacità (Cap. 8 di “Microsoft SQL Server 2000 Performance Tuning Technical Reference”), possiamo passare a valutare quanto rende il nostro Cheetah in termini di operazioni al secondo.

Relazione tra tempi di risposta e percentuale di utilizzo del disco

Abbiamo che in modalità sequenziale una lettura richiede una latenza totale di 2.2ms mentre per una scrittura servono 2.4ms, per un totale rispettivamente di 455 e 417 operazioni/sec (= 1000m / latenza ). In modalità random i valori salgono 5.5ms e 6.0ms ottenendo così 182 e 167 operazioni/sec.

A questi risultati dobbiamo sottrarre l’overhead della catena driver+controller+logica di gestione del disco, in sostanza tutto quello che si trova tra la richiesta di scrittura da parte del sistema operativo e la testina del disco, valutato intorno al 20% per le operazioni random e 10% per quelle sequenziali. I valori calcolati prima diventano così 364 e 333 per l’accesso sequenziale mentre per l’accesso random si scende a 164 e 150: abbiamo così il massimo ammissibile per ogni disco nel caso di uso non continuativo. I valori medi diventano quindi 348 nel caso di accesso sequenziale e 157 per l’accesso random.

Prendendo ora come riferimento l’85% dell’utilizzo onde evitare evidenti accodamenti, i nostri valori diventano 309 e 283 nel primo caso e 139 e 128 nel secondo, con una media rispettivamente di 296 per l’accesso sequenziale e 133 per l’accesso random.

Di seguito la tabella riassuntiva dei dati appena trovati:

Latenza di rotazione (1/2 giro) = 2ms		Latenza totale	Operazioni/Sec	Overhead:20% random, 10% sequenziale	Media per uso non continuativo	85% per evitare code	Media
Lettura Sequenziale	0.2ms	2.2ms	455	364	348	309	296
Scrittura Sequenziale	0.4ms	2.4ms	417	333		283
Lettura Random	3.5ms	5.5ms	182	164	157	139	133
Scrittura Random	4.0ms	6.0ms	167	150		128

Vediamo ora i vari livelli di RAID come si comportano dal punto di vista delle operazioni di I/O richieste ad ogni disco che compone un Array.

RAID0

Alla base di tutti i livelli abbiamo il RAID0, un semplice striping che non offre caratteristiche di fault tolerance e naturalmente non è raccomandato per fornire storage a SQL Server, anche se rappresenta il massimo livello di performance. Il numero di operazioni gestite da ogni disco componente l’array è dato da:

I/O per Disco = (Letture + Scritture) / Numero di dischi

RAID1

Rappresenta il “classico” mirroring in cui i il meccanismo di “fault tolerance” viene implementato replicando i dati un secondo disco. dal punto di vista del calcolo abbiamo:

I/O per Disco = [Letture + (2 * Scritture)] / 2

Si nota quindi come in questo caso le operazioni di scrittura siano più onerose, mentre nel caso delle letture grazie al supporto “Split seeks”, che permette di distribuire equamente il carico sui due dischi, si comporta come un RAID0

RAID5

E’ probabilmente il livello più utilizzato perché fornisce un buon livello “fault tolerance” unitamente ad un elevato rapporto numero di dischi/spazio disponibile, e in determinate condizione anche buone performance. Il RAID5 introduce il concetto di “parità” per potere ricostruire il dato nel caso in cui uno dei dischi componenti un array dovesse rompersi: il calcolo della parità risulta essere anche il “tallone d’Achille” per le performance di questa implementazione. Al momento della creazione di un volume di questo tipo la parte riservata ai dati viene inizializzata a 0 ed il bit di parità resettato: per questo motivo sono necessarie quattro operazioni, la prima per leggere il dato esistente, la seconda lo stato della parità, la terza per riscrivere il nuovo dato e la quarta per la nuova parità dopo che il processore del controller ne ha calcolato il valore. Abbiamo quindi:

I/O per Disco = [Letture + (4 * Scritture)] / Numero di dischi

dal momento che come abbiamo visto sopra per ogni operazione di scrittura ne occorrono 4

RAID10

E' l'unica vera alternativa al RAID5 nel momento in cui si vuole il massimo delle performance unitamente al migliore livello di “fault tolerance” ed è in sostanza un mirroring al quale viene aggiunta la funzionalità di stripe.

Il calcolo presenta la stessa formula del RAID0 ma con il denominatore che diventa uguale al numero di dischi (sempre multiplo di 2)

I/O per Disco = [Letture + (2 * Scritture)] / Numero di dischi

Sono previsti anche altri livelli di RAID: 3,4, 6 (un 5 con doppia parità) e 7 ( 3 o 4 con caching), ma il loro impiego è limitato a casi sporadici.

LA DOMANDA FATIDICA: RAID5 o RAID10?

Purtroppo molto spesso le esigenze di spazio dominano nei confronti delle performance ed il RAID5, a parità di dischi fornisce sempre una capacità di memorizzazione superiore, ma una volta che questo problema passa in secondo piano sarebbe opportuno scegliere praticamente sempre il RAID10 dal punto di vista delle performance. Il RAID5 nel momento in cui la percentuale delle scritture supera il 10% del totale inizia a imporre un maggior carico ai singoli dischi dell’array.

Prendiamo ad esempio il nostro disco visto sopra, da 188 operazioni random al secondo prima di iniziare ad accodare, e vediamo cosa succede una volta inserito in un array composto da 6 unità (configurazione molto diffusa), che si trova a gestire 500 operazioni al secondo.

Confronto sul carico dei dischi

Rapporto Lettura/Scrittura	RAID 5 I/Os ^[a]	RAID 10 I/Os ^[b]
100% letture; 0% scritture	(500 + 0) / 6 83 I/Os per disco	(500 + 0) / 6 83 I/Os per disco
90% letture; 10% scritture	(450 + 200) / 6 108 I/Os per disco	(450 + 100) / 6 91 I/Os per disco
75% letture; 25% scritture	(375 + 500) / 6 145 I/Os per disco	(375 + 250) / 6 104 I/Os per disco
50% letture; 50% scritture	(250 + 1000) / 10 208 I/Os per disco	(250 + 500) / 6 125 I/Os per disco
0% letture; 100% scritture	(0 + 2000) / 6 333 I/Os per disco	(0 + 1000) / 6 166 I/Os per disco
^[^a^] [Letture+ (4 * Scritture)] / N°Dischi ^[^b^] [Letture+ (2 * Scritture)] /N°Dischi

Come si vede già con il 10% di scritture il RAID5 impone più del 15% in più di carico su ogni disco, al 25% il confronto inizia a diventare molto sconveniente, e già prima del 50% supera il limite oltre il quale inizia l’accodamento. infine al 100% di scritture il RAID5 risulta evidentemente in difficoltà mentre il RAID10 si mantiene ancora entro le capacità del singolo disco.

Mauro Munzi
Senior Support Engineer
Microsoft Enterprise SQL Support

SQL Server - Analizzare un problema di timeout utilizzando Sqlnexus

itentblg — Mon, 05 Jan 2009 03:00:00 GMT

Una delle richieste più frequenti che riceviamo nel team di supporto di Sql Server è quella di capire la causa determinante timeout applicativi durante l’esecuzione di query.

In questo post spiegherò come utilizzare Sqlnexus per effettuare velocemente l'analisi di un problema relativo alla lentezza di una query e determinante un timeout applicativo.

Problema

Errori di timeout, che si verificano in modalità casuale, durante una complessa attività applicativa.

Dati da raccogliere

Per capire la causa di problemi di timeout è necessario individuare l'attività su cui il timeout si verifica e se tale attività è stata affetta da blocchi o da problemi di performance sul server.

Dal punto di vista di Sql server, l’analisi di un timeout verificatosi durante l’esecuzione di una query, può essere inizialmente affrontata come un generico problema di performance volto ad identificare la causa per cui una determinata query viene eseguita in un tempo superiore a quello impostato dal timeout applicativo.

A tale scopo, durante il riprodursi del problema, si chiede generalmente di raccogliere dati di performance quali trace di Sql server profiler, System monitor counters e trace di Blocker script.

Il tool in grado di raccogliere contemporaneamente tali informazioni è Pssdiag:

Sql server 2000 è disponibile pubblicamente con interfaccia grafica al seguente indirizzo http://support.microsoft.com/kb/830232
Sql server 2005 è possibile utilizzare il tool Sqldiag compreso nell'installazione e non avente interfaccia grafica

Per avere un esempio degli eventi e counters da catturare è possibile far riferimento al seguente articolo HOW TO: Troubleshoot Application Performance with SQL Server.

In questa situazione specifica sono stati raccolti i seguenti eventi:

Database: tutti gli eventi
Errors and warning: tutti gli eventi
Locks: Lock:Deadlock, Lock:Escalation, Lock:Timeout
Objects: Auto Update Stats
Performance: Show Plan Statistics
Security Audit: Login, Login Failed, Logout
Sessions: ExistingConnestion
StoredProcedure: RPC:Completed, RPC:Starting, SP:CacheInsert, SP:CacheRemove, SP:Recompile, SP:StmtCompleted, SP:StmtStarting
Tsql:SQL:BatchCompleted, SQL:BatchStarting, SQL:StmtCompleted, SQL:StmtStarting

Analisi dei dati

In questa sezione vedremo come Sqlnexus possa essere utilizzato per analizzare i dati raccolti tramite le trace di Sql server profiler.

Installazione di Sqlnexus

Scaricare il tool Sqlnexus e verificare le informazioni sul suo utilizzo

Installare RML utilities

Caricamento dati in Sqlnexus

Avviare Sqlnexus.exe e connettersi a un Sql server in ambiente di test per effettuare l’analisi dei dati.
Una volta aperta l’interfaccia di Sqlnexus, cliccando su import, verrà visualizzata la finestra in cui impostare la cartella contenente i file di Sql server profiler raccolti con Pssdiag:

Visualizzazione dei dati di performance

Terminato l'import dei dati , potremo selezionare Readtrace_main, nella sezione Reports, per visualizzare l'analisi:

Selezionando i link presenti nella schermata di Performance Overview, potremo visualizzare i report indicanti le query eseguite durante l’intervallo di tempo di cattura dei dati e il rispettivo consumo di risorse. Tali report costituiscono un aiuto essenziale nell’individuare le query aventi maggiore impatto in termini di tempo di esecuzione , letture , scritture o consumo di CPU.

Individuazione dei timeout

Siccome l’obiettivo di questo blog e quello di analizzare le query su cui è avvenuto un timeout applicativo, dovremo individuare gli eventi di Attention avvenuti durante la cattura dei dati.
Per visualizzare tali eventi, selezioniamo Interesting events e sarà visualizzato un grafico simile a quello sotto riportato:

Come è possibile verificare dalla schermata sopra riportata, supponendo di aver impostato gli eventi necessari in Sql server profiler, potremo visualizzare tramite un grafico facilmente leggibile, altri tipi di eventi quali la crescita dei datafile o i sort warning e associare o meno tali eventi al verificarsi del problema.
Selezionando il link Attention, potremo visualizzare la query su cui è avvenuto il timeout e lo spid che stava eseguendo in quel momento la query.

Selezionando la query, potremo visualizzare tutti i dettagli sul tempo di esecuzione, le letture eseguite, il consumo di CPU e il nome del file di Sql server profiler contenente l’esecuzione della query durante l’avvenuto timeout.

Dalla schermata sopra riportata è evidente che il tempo di esecuzione della query ha superato i 30 sec di timeout impostato dall’applicazione.

Una volta individuata la query su cui si manifesta il problema, lo spid avente in esecuzione la query e l’intervallo di tempo in cui è avvenuto il timeout, potremo aprire la trace di Sql server profiler, filtrare per lo spid indicato da Sqlnexus, cercare la query affetta dal problema e analizzare in dettaglio i vari passi di esecuzione.

Nell’esempio qui riportato, analizzando la trace di Sql server profiler in corrispondenza della query e dell’intervallo di tempo in cui si è verificato il problema è stato possibile verificare che il timeout applicativo era dovuto ad un tempo di esecuzione superiori ai 30 sec e che la maggior parte del tempo di esecuzione, circa 25 sec, era utilizzato nella ricompilazione e inserimento in cache.

Se la trace di Sql server profiler non dovesse bastare ad individuare la causa del problema, sarà necessario effettuare altre verifiche quali l’analisi del Blocker script e dei Performance counters in corrispondenza dell’intervallo di tempo in cui si è verificato il problema oppure la verifica dettagliata del piano di esecuzione della query per effettuare un adeguato tuning.

Anche per analisi più approfondite Sqlnexus potrà aiutare, dandoci velocemente una panoramica delle attività presenti sul server durante il verificarsi del problema.

Raffaella Canobbio
Support Escalation Engineer
Microsoft Enterprise SQL Support

Analizzare l’evento “Application Popup 333”

itentblg — Mon, 17 Nov 2008 03:00:00 GMT

In questo mio primo post vorrei parlarvi di un evento, che sotto determinate condizioni, è possibile riscontrare nel Registro Eventi del proprio server: l’Application Popup 333.

Come prima cosa cerchiamo di capire a cosa si riferisce questo evento.

Partiamo con l’indicare che il relativo source è l’Application Popup, che ci notifica negli eventi di sistema che un’operazione di I/O iniziata dal registro è fallita. In particolare questo componente non è stato capace di leggere, scrivere o fare il flush su disco di determinate informazioni, che andranno dunque perse. Negli eventi di sistema vedremo una serie di segnalazioni come queste:

Sottolineo una serie perché in seguito al presentarsi del primo di questi eventi, circa ogni 5 secondi il sistema memorizzerà una nuova notifica, fino a quando non verrà effettuato un reboot della macchina.

In generale non possiamo determinare gli effetti della mancata scrittura o lettura del registro, ma questi saranno sicuramente circoscritti al componente che ha richiesto l’operazione. I sintomi che accompagnano questo evento, se presenti, sono differenti a seconda della causa che lo genera.

Tipici scenari possono riguardare hangs del sistema, risorse insufficienti per il completamento di un servizio richiesto, database SQL che si stoppano o che eseguono le query lentamente, o più in generale eventi legati alle performance del sistema operativo.

Questo evento è stato introdotto con Windows Server 2003 Service Pack 1 ed è possibile trovarlo sia su sistemi x86 che x64.

Terminata questa breve introduzione, passiamo all’analisi di quelle che possono essere le cause che portano a questo evento.

Il disco che sta ospitando il sistema operativo ha un carico di lavoro molto elevato, o ha dei problemi hardware, evidenziando una lunga coda di operazioni che attendono per essere eseguite. Possiamo avere questa circostanza sia su sistemi x86 che x64.
Esaurimento delle risorse lato Kernel: Non Paged Pool Memory (Evento SRV 2020 nel registro di sistema), Paged Pool Memory (Evento SRV 2019 nel registro di sistema) o Page Table Entries (PTE). Questa problematica riguarda, salvo eventi particolari, sistemi x86, a causa delle limitazioni dettate dall’architettura a 32 bit.
Un filter driver sta impedendo flush su disco del registri. Questo può accadere sia in sistemi x86, che x64.
E’ stato concesso il privilegio “Lock system pages in memory” ad un account user. Questo può succedere sia in sistemi x86, che x64.

Abbiamo elencato le ipotetiche cause del nostro evento 333, ma come facciamo a rimuoverlo?!

Dipende dal particolare scenario alla base del problema, analizziamo singolarmente le varie casistiche:

Problemi legati al disco

Per identificare questo tipo di problematica possiamo configurare i performance monitor forniti dal sistema operativo per l’analisi del nostro disco fisico. La prima grandezza che ci fornisce un’idea di come il nostro disco sta rispondendo alle operazioni richieste è la Current Disk Queue Length. Questo valore dovrebbe essere tipicamente non superiore a 1 per un disco, o più in generale non superiore a n per sistemi di memorizzazione costituiti da n dischi, come le varie tipologie di RAID. Occorre sollevare un’eccezione per le SAN, dove questo valore può essere falsato dalla metodologia di archiviazione utilizzata dall’hardware a disposizione e dunque eventuali anomalie riscontrate vanno sempre discusse con l’OEM.

FIG. 1 – Disco con valori della Current Queue Length anomali

FIG. 2 – Disco con valori della Current Queue Length normali

La figura 2 ci mostra un esempio un disco che sta eseguendo senza problemi le richieste di I/O derivanti dall’attività del sistema operativo. Dalla figura 2, invece, è possibile osservare un disco che sta accodando le richieste di I/O, introducendo dunque delle potenziali problematiche. E’ possibile suddividere le cause che possono portare ad una situazione come quella illustrata nella figura 1, in due sottogruppi:

Problemi strettamente legati all’hardware (Controller o unità disco)
Sovraccarico delle operazioni su disco

Consideriamo la prima casistica, il disco sta accodando delle richieste a causa di problemi hardware. L’accodamento è dunque causato da una lentezza da parte del sistema si storage nell’eseguire le richieste. Un altro counter, che affiancato alla Current Disk Queue Length, ci può evidenziare questa tipologia di problema è il Disk Response Time. Il tempo di risposta può variare a seconda delle specifiche del disco, ma in generale un tempo superiore ai 30ms dovrebbe essere investigato. Se i contatori esposti sembrano evidenziare un problema legato al sistema di storage, occorrerà aggiornare firmware e driver del controller ed eventualmente controllare i dischi attraverso i tool di hardware monitoring.

La seconda casistica riguarda un’eccessiva attività su disco. Un altro counter, che associato al Disk Queue Length, ci può evidenziare questo tipo di situazione è il I/O Data bytes/sec dell’oggetto Process. Occorrerà per prima cosa evidenziare eventuali processi che stanno eseguendo un’elevata attività di I/O e verificare se questo risulta in linea con i ruoli e le attività quotidiane del server. Se non si riscontrassero anomalie legate al binomio ruoli/attività disco, occorrerà effettuare un bilanciamento del carico su più dischi o server, ed eventualmente spostare il file di paging su un disco differente da quello di sistema.

Esaurimento delle risorse kernel

Tratteremo nel dettaglio la gestione di questa problematica nei prossimi post, partiamo comunque col dire che le tre grandezze che entrano in gioco in questo tipo e sono la Non Paged Pool Memory, la Paged Pool Memory e le Free Page Table Entries. Possiamo verificare questi valori attraverso i relativi contatori dell’oggetto memory. In particolare le soglie che dobbiamo tenere come riferimento, per sistemi Windows Server 2000 e 2003, sono le seguenti:

Non Paged Pool Memory (NPP)	< 256 MB ( 128 MB in sistemi con lo switch /3GB abilitato )
Paged Pool Memory (PP)	< 650 MB (491.875 per Windows 2000 e Windows XP)
Free Page Table Entries (PTE)	> 5.000 (Sotto questo valore il comportamento del sistema è imprevedibile)

L’esaurimento della Non Paged Pool Memory e Non Paged Pool Memory, è solitamente accompagnato dagli eventi d’errore 2019 e 2020 nei system events.

Se riscontriamo che la PP,o la NPP, si stanno avvicinando alle soglie indicate, occorrerà effettuare una specifica analisi per capire quale driver sta causando l’esaurimento della risorsa. Come anticipato tratteremo questo tipo di analisi in un articolo separato. In generale possiamo comunque investigare su problemi conosciuti di esaurimento della memoria, riguardanti i driver di terze parti attualmente installati sul nostro server. E’ buona norma mantenere sempre i driver dei vari prodotti, aggiornati all’ultima versione disponibile.

Per quanto riguarda le PTEs, occorrerà effettuare la seguente distinzione:

Switch /3GB abilitato nel boot.ini
In questo caso la memoria virtuale dedicata al sistema operativo si riduce da 2 a 1 GBytes, riducendo così anche lo spazio libero per le PTE. In questo particolare caso possiamo intervenire con lo switch /USERVA, come indicato nel seguente articolo:
KB 316739
How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB
http://support.microsoft.com/default.aspx?scid=kb;EN-US;316739

In questo modo possiamo modificare la soglia tra i 3Gbyte della memoria virtuale user e il Gbyte della memoria virtuale dedicata al kernel.
Switch /3GB disabilitato nel boot.ini
In questo caso potremmo avere un leak di PTE, che possiamo analizzare attraverso l’impostazione del Track PTE ed un tool di debugging. Anche questa specifica problematica, verra trattata nell’articolo dedicato alle risorse kernel.

Filter driver

E’ doveroso premettere che rimuovendo o disabilitando un filter driver senza capire l’impatto sul sistema, potremmo riscontrare comportamenti inaspettati, come hang o blue screen. Esempi di applicativi che possono utilizzare dei filter driver includono: Anti-virus software, Backup Software, software di gestione volumi, software di criptazione/decriptazione dati etc.

Il metodo più semplice per determinare i filter driver, di terze parti, installati sulla nostra macchina è utilizzare la nostra utility MPS Report, che consente di raccogliere queste informazioni. Possiamo seguire dunque i seguenti passi:

Download del tool MPSRPT_SETUPPerf.exe dal link Microsoft Product Support Reporting Tools page.
Eseguire il file MPSRPT_SETUPPerf.EXE scaricato.
Terminata l’esecuzione, la durata media è di circa 15min, è possibile analizzare il file PStat.txt, estraendolo dal file .CAB creato dal tool. Tramite questo file possiamo verificare tutti i filter / kernel drivers con le relative date. Verificare eventuali versioni non aggiornata, o eventuali versioni che hanno già problemi riconosciuti dal vendor.

E’ importante che, prima di effettuare qualsiasi operazione di disabilitazione o rimozione, venga effettuato il controllo sulla disponibilità da parte del vendor di eventuali versioni aggiornate.

Lock system pages in memory

In sistemi a 64bit, come descritto precedentemente, la probabilità di avere valori preoccupanti per le PTEs è assai inferiore rispetto a sistemi x86. Tuttavia, abbiamo visto nella nostra attività quotidiana, eventi 333 capitare ugualmente anche in sistemi x64, dovuti a questo motivo.

Un workaround per questo comportamento in sistemi x64 con 4GB, o meno, di memoria RAM è costituito dai seguenti passi:

Cliccare su Start --> Run
Digitare Secpol.msc e premere OK
Espandere "Local Policies" e cliccare su "User Rights Assignment"
Doppio click su "Lock pages in memory"
Evidenziare eventuali user accounts elencati e cliccare su "Remove"
Premere su OK, una volta rimossi tutti gli user account
Riavviare il sistema

Di default il sistema operative non fornisce questo diritto a nessun account. Il privilegio “Lock pages in memory” è fornito all’account utilizzato per i servizi SQL in SQL 2005 RTM/SP1 Enterprise Edition installato su sistemi a 32bit. Se state utilizzando SQL Enterprise in un servers x86, con più di 4GB di RAM, questo privilegio è necessario. Per cercare di ridurre l’occorrenza degli eventi 333 nel sistema, occorrerà verificare che l’account che si sta utilizzando per I servizi SQL, sia utilizzato solo per SQL. Per sistemi x64 possiamo rimuovere tutti gli utenti elencati.

Bene questo è tutto per questo post. Come potete vedere le cause per l’evento 333 sono svariate e spesso correlate a problemi con alcuni driver o configurazioni: vi consiglio dunque di visitare regolarmente la nostra Microsoft Knowledge base per verificare le nuove pubblicazioni e gli ultimi aggiornamenti disponibili.

Mattia Tocco
Senior Support Engineer
Microsoft Enterprise Platforms Support

Supporto Tecnico Enterprise : Performance

Memoria Paged e NonPaged Pool – Come risolvere un memory leak

Utilizzare il PoolMon

Identificare il TAG e byte allocati

Determinare la frequenza di campionamento

Analizzare i log

NonPaged Pool

Paged Pool

Identificare il driver

Conclusione

Memoria Paged e NonPaged Pool – Come identificare un memory leak

Memoria Paged e NonPaged Pool

Eventi SRV 2019 e 2020

Analizzare un Memory Leak

SQL Server - Facciamo quattro conti con i dischi

Latenza di rotazione (1/2 giro) = 2ms

Latenza totale

Lettura Sequenziale

0.2ms

2.2ms

Scrittura Sequenziale

0.4ms

2.4ms

Lettura Random

3.5ms

5.5ms

Scrittura Random

4.0ms

6.0ms

RAID0

RAID1

RAID5

RAID10

LA DOMANDA FATIDICA: RAID5 o RAID10?

100% letture; 0% scritture

90% letture; 10% scritture

75% letture; 25% scritture

50% letture; 50% scritture

0% letture; 100% scritture

[a] [Letture+ (4 * Scritture)] / N°Dischi

[b] [Letture+ (2 * Scritture)] /N°Dischi