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:

image_thumb[1][1]

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.

 image3_thumb

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

image6_thumb[4]

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:

  1. Download del tool MPSRPT_SETUPPerf.exe dal link Microsoft Product Support Reporting Tools page.
  2. Eseguire il file MPSRPT_SETUPPerf.EXE scaricato.
  3. 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:

  1. Cliccare su Start --> Run
  2. Digitare Secpol.msc e premere OK
  3. Espandere "Local Policies" e cliccare su "User Rights Assignment"
  4. Doppio click su "Lock pages in memory"
  5. Evidenziare eventuali user accounts elencati e cliccare su "Remove"
  6. Premere su OK, una volta rimossi tutti gli user account
  7. 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