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

2 Comentários
  1. 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.

Deixe uma resposta

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