Resolvendo memory leak - Procurando o devorador de memória - parte 1
Algo que vejo recorrente em fóruns e listas de discussão, colegas que perguntam para mim, é "como detectar e resolver o memory leak ?"
Começarei uma série de dicas voltados a encontrar e resolver o problema de retenção de memória (memory leak) em aplicações Java. Posteriomente, será feito um tutorial para resolver problemas de CPU.
Estas dicas podem ser úteis para programadores que ainda não passaram por este problema ou não conhecem as ferramentas. Mesmo para profissionais experientes, espero que possa contribuir.
Isso é baseado em minha experiência, em ambiente linux e solaris. Será dado ênfase no uso de ferramentas gratuitas ou de código livre, para ajudar neste processo. Para ambiente windows, onde possível colocarei as dicas aplicáveis para este SO, mas devo dizer que não tenho especialidade neste SO, portanto desconheço as ferramentas mais adequadas.
Ambiente de produção e desenvolvimento
Também será mostrado como resolver esse problema, tanto em ambiente de produção como em ambiente de desenvolvimento, com as ferramentas disponíveis em cada amviente (exemplo: invocar profiler ou debug em ambiente de produção é bastante caro em termos de performance).
É importante endender que a aplicação pode sofrer monitoramento de maneira intrusiva e não intrusiva.
- Intrusivo: quando é necessário modificar as configurações de inicialização da aplicação para permitir uma introspecção de suas chamadas de sistemas e quando ocorre uma interceptação destas chamadas de sistemas pelo esquema de monitoramento intrusivo. Um exemplo disso são os profilers e debuggers. Isso gera penalidade em performance, modificação da configuração do ambiente e instalação de ferramentas, o que em ambiente de produção pode ser um grande problema
- Não intrusivo: Quando é usado ferramentas de monitoramento, que não geram interceptação das chamadas do sistema, não geram impacto negativo em desempenho e não precisam de instalação de software adicional.
Existem uma série de passos, começando por descobrir onde ocorre problema de retenção, até sua resoluçao.
Qual processo do sistema operacional consome memória em demasiado ?
Este é o 1o passo, para identificar se o programa (desktop ou servidor) consome memória sem manter estável.
É importante entender que a aplicação deve ter passado por todas as etapas de criação de objetos e recursos, que já tenha passado por um ciclo de vida. Isso pode ser alcançado, navegando pela aplicação, consultando relatórios, etc.
É necessário usar apenas o SO e suas ferramentas, para descobir qual o processo está neste estado.
Ferramentas:
- Linux: top, htop, ps
- Solaris: prstat, ps
- Windows: gerenciador de tarefas
Segue um exemplo de um programa que consome memória (propositadamente), e sua medição pelos respectivos utilitários do SO.
Vejam que existe um processo java que consome muita memória. O que neste caso interessa saber o PID (process ID) e a linha de comando.
Linux top
Percebe-se uma visualização com cores, linha de comando completa e ordenação diferentes, isso pode ser alcançado por atalhos
z => modifica o esquema de cores
c => mostra a linha de comando completa
shit M => ordena pelo consumo de memória
W => Torna esta configuração o padrão nas próximas invocações do comando top
O top tem uma vantagem, que ele já vem instalado em qualquer linux, então não é necessário efetuar download e instalá-lo. Já o htop, fornece uma visualização melhorada, mas é necessário efetuar download e instalar.
Para saber o consumo da memória por processo, veja na coluna RSS (ou RES), este é o valor de memória física consumido pelo processo (de fato, existem algumas discussões em fórums sobre o comando RSS ser bem uma aproximação do valor real, mas fico devendo uma explicação melhorada sobre isso em outro blog)
Linux htop
Este utilitário, fornece uma visualização melhorada sobre os processos e os recursos.
Linux ps
$ ps -eo pid,user,%cpu,rss,vsz,etime,nlwp,args
PID USER %CPU RSS VSZ ELAPSED NLWP COMMAND
7642 claudio 0.7 343536 658804 05:23 12 java TestReferences
A diferença do comando ps e top, é apenas a visualização, já que o ps recupera um snapshot do sistema.
O diferencial deste comando, é que mostra também a quantidade de threads por processo, na coluna NLWP.
Solaris prstat
$ prstat -s rss
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
617 claudio 102M 78M sleep 59 0 0:00:01 2.1% java/9
554 root 106M 32M sleep 59 0 0:00:01 0.2% ns-httpd/71
7 root 11M 10M sleep 59 0 0:00:03 0.0% svc.startd/12
9 root 11M 9384K sleep 59 0 0:00:07 0.0% svc.configd/17
308 root 12M 8528K sleep 59 0 0:00:01 0.0% fmd/16
553 root 27M 8088K sleep 59 0 0:00:00 0.0% ns-httpd/2
618 root 8936K 4416K sleep 59 0 0:00:00 0.0% sshd/1
Foi usada a opção prstat -s rss para ordenar a apresentação baseada no consumo de memória. Outra informação é a quantidade de threads por processo, na coluna NLWP
Windows task manager
Então foi identificado qual é o sistema que consome mais memória. Com isso é possível ter um ponto de partida na análise do processo.
No próximo blog, que pretendo escrever em dois dias (espero), será mostrado como detectar se existe memory leak.
Links del.icio.us
RedHat Brasil
