Como determino qual aplicativo está vazando memória não paginada?

Recentemente, tivemos um problema em nosso servidor ativo que fez com que nosso aplicativo Web parasse de responder. Tudo o que estávamos recebendo eram erros 503 até reiniciarmos o servidor, então tudo estava bem. Eventualmente, rastreei o arquivo até o activationperr.log e encontrei muitos erros 1_Connections_Refused.

Investigações posteriores pareciam indicar que atingimos o limite de pool não paginado. Desde então, monitoramos a memória de pool não paginado usando Poolmon.exe e acreditamos ter identificado a tag que está causando o problema.

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

Se usarmos poolmon.exe / g, ele exibirá o driver mapeado como [<unknown> Event objects].

Isso praticamente não ajuda em nada. Minha equipe passou um tempo considerável pesquisando esse problema e não conseguiu encontrar um processo para reduzi-lo a um aplicativo ou serviço específico. Tenho a sensação de que a maioria das pessoas parece resolver o problema matando processos na máquina até ver a memória não paginada sendo redefinida. Não é exatamente isso que você deseja ver ao trabalhar em uma máquina de produção.

Se eu abrir o Gerenciador de tarefas e visualizar a lista de processos. Vejo MailService.exe com um valor de NP Pool de 105K, este é 36K maior que o valor do processo listado em segundo. Como tivemos alguns problemas com nosso servidor de email no passado (que podem ou não estar relacionados a esse problema), meu pressentimento é que isso está causando o problema.

No entanto, antes de reiniciarmos os serviços, eu gostaria de ter um pouco mais de certeza do que apenas um "pressentimento".

Eu também tentei usar poolmon.exe / c, mas isso sempre retorna o erro:

unable to load msvcr70.dll/msvcp70.dll

e não cria localtag.txt. Meu colega precisou baixar o pooltag.txt da Internet porque não conseguimos descobrir onde ele está localizado. Não temos o depurador do win ou o DDK do win instalado (que eu posso ver). Talvez o erro acima tenha sido dado porque não temos nenhum deles instalado - mas eu não sei.

Finalmente tentei:

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

Isso retornou uma lista bastante considerável de arquivos .sys e novamente não ajudou em nada com o problema em questão.

Portanto, minha pergunta é a seguinte: existe outra maneira de diminuir a causa desse vazamento de memória?

ATUALIZAR:

Conforme sugerido abaixo, registrei os bytes não agrupados do pool nos últimos dias para verificar se há algum processo em alta. Na maior parte dos casos, todos os processos parecem bastante estáticos em seu uso. Dois deles parecem ter aumentado um pouco. Continuarei monitorando isso pelos próximos dias.

Também esqueci de mencionar anteriormente que nenhum dos processos parece estar usando um número excessivo de identificadores também.

ATUALIZAÇÃO 2:

Eu tenho monitorado isso nas últimas duas semanas. O pool de bytes não paginados para processos individuais e o conjunto total de bytes não paginados permaneceram relativamente estáveis ​​durante esse período. Durante esse período, o Windows foi atualizado e o servidor foi reiniciado, por isso estou pensando se isso resolveu o problema. Definitivamente, não estou vendo o crescimento consistente no pool de bytes não paginados agora que estava antes disso.

Estou monitorando isso há cerca de 6 a 7 semanas e finalmente posso dar uma resposta definitiva ao problema.

Em primeiro lugar, os bytes não paginados para processos individuais não me disseram nada de útil, pois todos pareciam bastante estáticos em seu uso. Houve picos, mas o uso sempre retornou à linha de base posteriormente.

O total de memória de bytes não paginados também ficou estático por algum tempo, mas depois começou a aumentar gradualmente e a disparar. Após um pico, cerca de metade da memória foi liberada e, em seguida, permaneceu estática novamente (no nível superior) por um tempo, até que o padrão se repetisse. Olhando para o gráfico, notei que esses picos pareciam estar regularmente espaçados e, como se vê, eles aconteciam com duas semanas de intervalo e sempre no domingo.

Portanto, a próxima pergunta era: O que acontece duas vezes por semana aos domingos? Observei o Event Viewer e toda vez que ocorria um pico, a McAfee estava em execução . Também acho que ao fazer logon com frequência no servidor para monitorar o problema, inadvertidamente pioramos o problema, porque a McAfee possui um scanner em tempo real e acredito que isso estava causando os aumentos menores que estávamos vendo.

Penso que as verificações que estão sendo agendadas também explicam por que vimos o aumento da memória NP associado à marca de objetos Event no PoolMon, em vez da marca específica da McAfee. Essa foi a principal coisa que realmente nos levou pelo caminho do jardim.

Agora que finalmente sabemos o que está causando os vazamentos, podemos fazer algo a respeito. É incrível que demorou tanto tempo para encontrá-lo.

ATUALIZAÇÃO : Apenas como uma nota final. O McAfee's foi atualizado no fim de semana e isso resolveu completamente o problema de memória não paginada.

ATUALIZAÇÃO 2 : Como recebi um voto positivo, adicionarei uma atualização adicional a isso. Inicialmente, a atualização para a McAfee parecia corrigir o problema, ou seja, não vemos mais os picos maciços na NP Memory em intervalos regulares. Também notei que, desde a atualização, parece que a McAfee não grava mais logs no Visualizador de Eventos por padrão agora, que se oculta quando está sendo ativamente verificada.

Mas ainda estamos vendo aumentos graduais no uso da memória NP. Chegou ao ponto em que agora precisamos reiniciar o servidor a cada 2 semanas. É tão ruim que, recentemente, adquiriu um novo servidor na esperança de que hardware e software atualizado fará este problema desaparecer MAS nosso completamente novo servidor com apenas Windows Server 2008, SQL Server 2008 R2, e McAfee instalado foi AINDA mostrando um vazamento NP Memória . Foi só depois que removi completamente a McAfee que o vazamento parou e permaneceu estático, mesmo depois que configuramos o servidor com todo o nosso software em preparação para mudar para ele.

Desde então, li e não sei se isso é verdade, que o problema não está na McAfee, mas em alguma rotina do Windows usada pela McAfee que faz com que o NP Memory vaze. Aparentemente, a atividade de rede é a causa do vazamento, ou seja, mais atividade de rede => vazamentos maiores. Isso parece ser consistente com a nossa experiência, pois o vazamento piorou à medida que nosso servidor ficou mais ocupado.