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.
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:
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:
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.
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:
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:
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:
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.
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:
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