Como eu determino qual aplicativo está vazando memória não-paginável?

Question

Recentemente, tivemos um problema em nosso servidor ativo que fez com que nosso aplicativo da web parasse de responder. Todos nós estávamos recebendo 503 erros até que nós reiniciamos o servidor, então estava tudo bem. Eventualmente eu o rastreei de volta para o httperr.log e encontrei um monte de erros de 1_Connections_Refused.

Outras investigações pareciam indicar que atingimos o limite de pool não paginado. Desde então, temos monitorado a memória do pool não paginado usando o 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 mostrará o driver mapeado como [< desconhecido > Objetos de evento].

Esta é praticamente nenhuma ajuda não . Minha equipe passou um tempo considerável pesquisando esse problema e não conseguiu encontrar um processo para restringir isso a um aplicativo ou serviço específico. Tenho a impressão de que a maioria das pessoas parece resolver o problema matando processos na máquina até verem a redefinição da memória não-paginada. Isso não é exatamente o 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. Eu vejo MailService.exe com um valor de NP Pool de 105K isso é 36K maior do que o valor do segundo processo listado. Como tivemos alguns problemas com o nosso Mail Server no passado (o que pode ou não estar relacionado a esse problema), minha intuição é que isso está causando o problema.

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

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

unable to load msvcr70.dll/msvcp70.dll

e não cria o localtag.txt. Meu colega teve que baixar o pooltag.txt da internet porque não conseguimos descobrir onde ele está localizado. Nós não temos o debugger do win ou o win DDK instalado (que eu posso ver). Talvez o erro acima seja dado porque não temos nenhum desses instalados - mas não sei.

Por fim, 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.

Então, minha pergunta é a seguinte: Existe alguma outra maneira de diminuir a causa desse vazamento de memória?

ATUALIZAÇÃO:

Como sugerido abaixo, eu registrei os Bytes não-paginados do Pool pelo último dia para ver se algum processo está em alta. Na maioria dos casos, todos os processos parecem estar razoavelmente estáticos em seu uso. Dois deles parecem ter se acertado ligeiramente. Eu continuarei a monitorar isso pelos próximos dias.

Eu também esqueci de mencionar anteriormente que nenhum dos processos parece estar usando um número excessivo de alças.

UPDATE 2:

Eu tenho monitorado isso nas últimas duas semanas. O Pool de Bytes Não Paginados para processos individuais e o Total de Conjuntos 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 reinicializado, por isso estou me perguntando se isso resolveu o problema. Eu definitivamente não estou vendo o crescimento consistente no conjunto de bytes não paginados agora que eu estava antes disso.

    

Answer 1

Eu tenho monitorado isso por cerca de 6 a 7 semanas e posso finalmente dar uma resposta definitiva para o problema.

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

O total de Memória de Bytes Não Pagos ficou estático por algum tempo também, mas depois começou a aumentar gradualmente e depois a aumentar. Depois de um pico, cerca de metade da memória foi liberada e então permaneceu estática novamente (no nível mais alto) por algum tempo até que o padrão fosse repetido. Olhando para o gráfico, notei que esses picos pareciam ser regularmente espaçados e, como se vê, eles estavam acontecendo com 2 semanas de intervalo e sempre em um domingo.

Então, a próxima pergunta foi: O que está funcionando quinzenalmente aos domingos? Eu fui dar uma olhada no Visualizador de Eventos e toda vez que um pico ocorria , o McAfee estava rodando . Eu também acho que ao fazer login no servidor com frequência para monitorar o problema, inadvertidamente o problema ficou pior, porque a McAfee tem um verificador em tempo real e acredito que isso estava causando os aumentos menores que estávamos vendo.

Acho que as verificações que estão sendo agendadas também explicam por que vimos o aumento da memória NP anexado à tag Objetos de evento no PoolMon, em vez da marca específica da McAfee. Esta foi a principal coisa que realmente nos levou para o caminho do jardim.

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

UPDATE : apenas como nota final. O McAfee's foi atualizado no fim de semana e isso resolveu completamente nosso problema de memória não paginada.

UPDATE 2 : Como acabei de receber uma votação para isso, adicionarei mais uma atualização a isso. Inicialmente, a atualização para a McAfee pareceu corrigir nosso problema, ou seja, nós não vemos mais os picos massivos da memória NP em intervalos regulares. Também notei que, desde a atualização, a McAfee não registra mais os registros no Event Viewer por padrão agora, o que oculta quando está sendo verificado ativamente.

Mas ainda estamos vendo aumentos graduais no uso de memória do NP. Chegou ao ponto em que agora precisamos reiniciar o servidor a cada duas semanas ou mais. É tão ruim que recentemente adquirimos um novo servidor na esperança de que o hardware e o software atualizados façam esse problema desaparecer MAS nosso servidor completamente novo com apenas o Windows Server 2008, o SQL Server 2008 R2 e o McAfee instalados estava STILL mostrando um vazamento de memória NP. Foi somente depois que eu removi completamente a McAfee que o vazamento parou e ele permaneceu estático mesmo depois de configurarmos o servidor com todo o nosso software em preparação para mudar para ele.

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