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?

Compartilhe este insight:

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

Autorização, em qualquer aplicação não é processo simples. Quando estamos implementando Microsserviços, o desafio pode ser um pouco maior. Neste...
NOTA DO ELEMAR: Este post foi escrito por Fernando Neiva de Paiva e editado por mim. Já fui cético com...
Sou privilegiado. Há anos, em função do meu trabalho, tenho a oportunidade de viajar para fora do país. Recentemente, passei,...
No modelo C4, o diagrama de contexto descreve, com um nível de abstração bem elevado, um sistema de software indicando...
What kind of optimizations could we expect from the C# compiler and the JIT? In this post, I would like...
Outro dia, meu amigo Giovanni Bassi compartilhou o seguinte tuíte: Ele e eu concordamos em discordar muitas vezes. Esta é...
× Precisa de ajuda?