Come determinare quale applicazione perde memoria non di paging?

Di recente abbiamo riscontrato un problema sul nostro server live che ha causato la mancata risposta della nostra app Web. Tutto ciò che ottenevamo erano errori 503 fino al riavvio del server, quindi andava bene. Alla fine l'ho rintracciato in httperr.log e ho trovato molti errori 1_Connections_Refused.

Ulteriori indagini sembravano indicare che avevamo raggiunto il limite del pool non di paging. Da allora abbiamo monitorato la memoria del pool non di paging utilizzando Poolmon.exe e riteniamo di aver identificato il tag che causa il problema.

Tag   Type    Allocs       Frees       Diff       Bytes      Per Alloc
Even  Nonp  51,231,806   50,633,533   684,922   32,878,688      48

Se utilizziamo poolmon.exe / g mostra il driver mappato come [<oggetti evento> sconosciuti].

Questo è praticamente di nessun aiuto. Il mio team ha dedicato molto tempo alla ricerca di questo problema e non è stato in grado di trovare un processo per limitarlo a un'applicazione o un servizio specifici. Ho la sensazione che la maggior parte delle persone sembri risolvere il problema uccidendo i processi sulla macchina fino a quando non vedono il reset della memoria non di paging. Questo non è esattamente quello che vuoi vedere quando lavori su una macchina di produzione.

Se apro Task Manager e visualizzo l'elenco dei processi. Vedo MailService.exe con un valore NP Pool di 105 KB, 36 KB in più rispetto al valore del processo elencato per secondo. Dato che in passato abbiamo riscontrato alcuni problemi con il nostro server di posta (che potrebbe essere o meno correlato a questo problema), la mia sensazione è che questo sia il motivo.

Tuttavia, prima di uscire dal riavvio dei servizi, vorrei avere un po 'più di certezza di un semplice "istinto".

Ho anche provato a utilizzare poolmon.exe / c ma questo restituisce sempre l'errore:

unable to load msvcr70.dll/msvcp70.dll

e non crea localtag.txt. Il mio collega ha dovuto scaricare pooltag.txt da Internet perché non riusciamo a capire dove si trova. Non abbiamo installato il debugger win o il DDK win (che posso vedere). Forse l'errore sopra riportato è dato dal fatto che non abbiamo installato nessuno di questi, ma non lo so.

Alla fine ho provato:

C:\windows\system32\driver\findstr /m /l Even *.sys

Ciò ha restituito un elenco abbastanza consistente di file .sys e di nuovo non è stato affatto utile con il problema in questione.

Quindi la mia domanda è questa: c'è qualche altro modo per restringere la causa di questa perdita di memoria?

AGGIORNARE:

Come suggerito di seguito, sto registrando i byte non pagati del pool per l'ultimo giorno o giù di lì per vedere se qualche processo è in trend. Per la maggior parte, tutti i processi sembrano essere abbastanza statici nel loro utilizzo. Due di loro sembrano aver spuntato leggermente. Continuerò a monitorarlo per i prossimi giorni.

Ho anche dimenticato di menzionare prima che nessuno dei processi sembra utilizzare un numero eccessivo di handle.

AGGIORNAMENTO 2:

Ho monitorato questo per le ultime due settimane. Sia il pool di byte non di paging per i singoli processi sia il pool di byte non di paging totale sono rimasti relativamente stabili durante quel periodo. Durante questo periodo Windows è stato aggiornato e il server è stato riavviato, quindi mi chiedo se ciò abbia risolto il problema. Sicuramente non vedo la crescita costante nel pool di byte non di paging ora che ero prima di questo.

Lo sto monitorando da circa 6-7 settimane e posso finalmente dare una risposta definitiva al problema.

Innanzitutto i byte non di paging per i singoli processi non mi hanno detto nulla di utile in quanto sembravano essere abbastanza statici nel loro utilizzo. Ci sono stati picchi ma l'uso è sempre tornato alla linea di base in seguito.

Il totale della memoria dei byte non pagiati era statico anche per un po ', ma poi ha iniziato gradualmente ad aumentare e poi a picchiettare. Dopo un picco circa la metà della memoria è stata liberata e poi è rimasta di nuovo statica (al livello più alto) per un po 'fino a quando il modello si è ripetuto. Guardando il grafico ho notato che questi picchi sembravano essere spaziati abbastanza regolarmente e, a quanto pare, si stavano verificando a 2 settimane di distanza e sempre di domenica.

Quindi la domanda successiva era: che cosa succede la settimana bisettimanale? Sono andato a dare un'occhiata al Visualizzatore eventi e ogni volta che si verificava un picco, McAfee era in esecuzione . Penso anche che accedendo frequentemente al server per monitorare il problema, inavvertitamente abbiamo aggravato il problema perché McAfee ha uno scanner in tempo reale e credo che ciò causasse i minori aumenti che stavamo vedendo.

Penso che le scansioni pianificate spieghino anche perché abbiamo visto aumentare la memoria NP associata al tag degli oggetti Event in PoolMon anziché al tag specifico di McAfee. Questa è stata la cosa principale che ci ha davvero portato lungo il sentiero del giardino.

Ora che finalmente sappiamo cosa sta causando le perdite, possiamo fare qualcosa al riguardo. È incredibile che ci sia voluto così tanto tempo per rintracciarlo però.

AGGIORNAMENTO : Proprio come una nota finale. McAfee è stato aggiornato nel fine settimana e questo ha risolto completamente il nostro problema di memoria non paginata.

AGGIORNAMENTO 2 : Dato che ho appena ottenuto un voto positivo per questo, aggiungerò un ulteriore aggiornamento a questo. Inizialmente l'aggiornamento a McAfee sembra aver risolto il nostro problema, cioè non vediamo più i picchi massicci nella memoria NP a intervalli regolari. Ho anche notato che dall'aggiornamento sembra che McAfee non scriva più registri nel Visualizzatore eventi per impostazione predefinita ora, che si nasconde quando esegue attivamente la scansione.

Ma stiamo ancora assistendo a incrementi graduali nell'utilizzo della memoria NP. È arrivato al punto in cui ora dobbiamo riavviare il nostro server ogni 2 settimane circa. È così grave che abbiamo recentemente acquisito un nuovo server nella speranza che hardware e software aggiornati risolvano il problema MA IL nostro server completamente nuovo con solo Windows Server 2008, SQL Server 2008 R2 e McAfee installato era ANCORA con una perdita di memoria NP . È stato solo dopo aver rimosso completamente McAfee che la perdita si è fermata ed è rimasta statica anche dopo aver configurato il server con tutto il nostro software in preparazione per passare a esso.

Da allora ho letto, e non so se questo è vero, che il problema non è con McAfee, ma con alcune routine di Windows che McAfee utilizza che causano la perdita di memoria NP. Apparentemente, l'attività di rete è la causa della perdita, ovvero più attività di rete => perdite maggiori. Ciò sembra essere coerente con la nostra esperienza, in quanto la perdita è peggiorata dal momento che il nostro server è diventato più occupato.