Resolvendo Memory Leaks

Afinal, quanta memória minha aplicação está consumindo?

A pergunta do título, embora simples, não é fácil de responder. De qualquer forma, o conhecimento necessário para respondê-la é fundamental para conseguir resolver problemas comuns (e evitar algumas confusões) na utilização de memória.

Windows e Linux, embora adotem modelos semelhantes para gestão de memória, utilizam terminologias diferentes para indicar como ela está sendo utilizada. Nesse post, vamos utilizar a terminologia do Windows.

Como podemos classificar a memória (no Windows)

Sistemas operacionais modernos adotam um modelo de memória virtual. Ou seja, a memória alocada não está, necessariamente, ocupando RAM. Isso permite que o total de memória utilizada por todos os processos supere (largamente) a quantidade de memória fisicamente disponível. Além disso, muitos recursos podem ser compartilhados por diversos processos (fontes, DLLs, imagens, etc), logo, a memória correspondente também será compartilhada. Por fim, a alocação de memória ocorre sempre em blocos (páginas), geralmente de 64 KB, que precisam ser plenamente utilizados ou ficam sem uso (unused) e não acessíveis.

Para qualquer processo, podemos classificar a memória utilizada como:

  • Working Set – Toda memória alocada que está ocupando, fisicamente, a memória RAM. Há, três tipos de alocações:
    • Private Working Set – memória alocada e utilizada (commited), de uso exclusivo do processo, ocupando a RAM fisicamente;
    • Shareable Working Set – memória alocada e utilizada (commited), potencialmente compartilhada com outros processos (embora, não obrigatoriamente), ocupando a RAM fisicamente;
    • Shared Working Set – memória alocada e utilizada (commited), já compartilhada com outros processos, ocupando a RAM fisicamente.
  • Private bytes – Total de memória alocada e utilizada (commited), tanto na memória RAM, fisicamente, quanto em um dispositivo de persistência durável;
  • Paged bytes – montante de memória alocada e utilizada (commited) por um processo e armazenada em um dispositivo de persistência durável
  • Virtual bytes – montante total de memória alocada, não necessariamente utilizada (reserved ou commited), por um processo. Memória reservada funciona como uma preparação para a alocação em si.

Para aplicações .NET, podemos ainda classificar a memória como sendo:

  • gerenciada – alocada por meios comuns e desalocada pelo Garbage Collector.
  • não-gerenciada –  não monitoradas pelo Garbage Collector

Começando a investigar a quantidade de memória utilizada por uma aplicação

Tanto o Task Manager, na aba detalhes, quanto o Performance Monitor conseguem dar boas indicações de como a memória está sendo consumida.

O Task Manager consegue apresentar um bom instantâneo de como a memória está sendo alocada em um determinado momento. O Performance Monitor consegue indicar a progressão de consumo.

Há outras ferramentas que podemos, e vamos utilizar em outros posts.

Voltando ao cenário do post anterior

No post anterior, propus o seguinte cenário:

Você foi contratado, por uma grande instituição financeira, para resolver o problema de um Serviço Windows, escrito em .NET (não por você), que está disparando OutOfMemoryException com frequência. Você não tem autorização para fazer um dump completo da memória. Entretanto, você tem acesso aos fontes, ao “Performance Monitor” e ao “Gerenciador de Tarefas” da máquina onde esse serviço está rodando. Qual seria sua primeira medida? Por quê?

Gostei muito de todas as respostas compartilhadas. Vejamos se consigo gerar uma “continuação” a partir das respostas indicadas:

Seguindo a recomendação do Nicolas Tarzia:

Converso com as pessoas para descobrir se há um padrão (horário, tempo de uso, etc) para a ocorrência do problema. Infelizmente, não há um padrão definido. Também não há nada que chame a atenção no registro de eventos do windows.

Seguindo a recomendação do Alexsandro:

Observo, no Performance Monitor, há ocorrência de “picos” de consumo. Entretanto, nada chama a atenção além do fato do consumo total de memória (Private Bytes) crescer sem sinais de redução.

Seguindo a recomendação do Flávio Peinado:

Verifico no código, rapidamente, se há conexões com bancos de dados ou sockets que não estão sendo fechadas. Entretanto, tudo parece OK.

Seguindo a recomendação do Tiago Borba,

Verifico também se há algum recurso de IO (FileStream, por exemplo) sendo aberto e não encerrado. Novamente, tudo OK.

Por fim, seguindo a recomendação do Gustavo:

Monitoro a quantidade em Private Bytes (total de memória “commited” para o sistema) e verifico o volume alocado em Heaps gerenciados. Aqui, percebo que o volume de memória alocada em Heaps Gerenciados está estável, embora Private Bytes continue crescendo. 

Procuro por objetos sem Dispose no código e… não encontro nada.

O que pode estar acontecendo?

Mais posts da série Resolvendo Memory Leaks

6 Comentários
  1. Lucas Massena

    Eu olharia os processos/rotinas mais pesadas em busca de objetos que não estão sendo descartados e que geralmente, são colocados em variáveis globais ou estáticas.

  2. Adriano Silva

    Parabéns pelos posts Elemar. Aguardando ansiosamente os próximos.

  3. José Roberto Araújo

    Um caminho seria analisar a aba Stack no Process Monitor. Por vezes, além de toda a memória (private bytes) alocada para dar suporte a estrutura de dados da aplicação em si, esta ainda faz uso de recursos do SO, o que, por vezes, pode causar um estouro de uso de memória. Analisando o comportamento na aba Stack, seria um caminho para ver o que está sendo usado no momento do OutOfMemoryException.

    1. José Roberto Araújo

      Além da sugestão anterior, o que pode ser analisado é o delta entre o Private Bytes e StandBy Page List. Com isso, teremos um caminho onde se terá conhecimento sobre a quantidade de memória que a aplicação deixou em “Espera” por não estar em uso constante. Em continuidade ao monitoramento (Process Monitor) deste processo, podemos analisar, também, os Modules que essa aplicação está tentando levantar e o que está acontecendo na aba Stack.

      Desta forma, teremos um ponto de saber se a aplicação está tentando usar, novamente, a memória da Standby Page List e, por algum motivo de extrema necessidade de outro processo, essa mesma quantidade de memória que estava em “espera”, não está mais disponível.

  4. DIOGO CARVALHO FERNANDES

    Dadas todas as possíveis soluções acima e ainda o problema continuando.

    O GC pode estar trabalhando demais, com muitas coletas. Então:

    – Validaria se a configuração do GC está de acordo com o servidor onde está alocada a aplicação. Caso o servidor seja dedicado para a aplicação e o processador tenha múltiplos núcleos, o GCServer precisa estar habilitado (por padrão está habilitado GCWorkstation).

    Também analisaria se existem exceptions não tratadas em background que podem estar sobrecarregando o servidor.

  5. Andre

    Eu olharia o número de elementos na geração 2 do GC. Se estiver aumentando, deve ter elementos não sendo coletados (armazenados em variáveis globais ou estáticas?).

    Mas qual é a resposta certa? O que estava acontecendo?

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *