"Usar muita memória" e "vazar memória" são problemas diferentes. Um vazamento é um processo cujo RSS sobe de forma constante e nunca cai, mesmo com a máquina ociosa. Uma única captura não mostra isso — são necessárias duas, tiradas com intervalo.
1. Quem é o maior agora
$ clai lista os processos ordenados por uso de memória→ ps -eo pid,comm,rss,%mem --sort=-rss | head -4 PID COMMAND RSS %MEM 218979 firefox 2089376 3.1 269458 verba 1257196 1.9 727108 telegram 1249824 1.9RSS está em kilobytes e é o número que importa: memória física realmente residente. Esta é sua lista de suspeitos, não a resposta.
2. Observe um processo ao longo do tempo
$ clai amostre a memória do pid 269458 a cada 10 segundos, 6 vezes→ pidstat -r -p 269458 10 6Este é o teste de verdade. RSS subindo nas seis amostras com carga estável é vazamento. Subir e depois estabilizar é um cache enchendo, o que é normal e vai parar sozinho.
3. Amostragem barata sem pacotes extras
$ clai registre a memória deste processo a cada minuto em um arquivo→ while sleep 60; do printf '%s %s\n' "$(date +%T)" "$(grep VmRSS /proc/269458/status)"; done | tee mem.logVmRSS: 1257196 kBpidstat vive no pacote sysstat e nem sempre está instalado. /proc/<pid>/status está sempre lá. Deixe rodando por uma hora e a forma da resposta ficará óbvia.
4. Para onde foi a memória dentro do processo
$ clai mostre o mapa de memória do pid 269458 ordenado por tamanho→ sudo pmap -x 269458 | sort -k3 -rn | headUm único mapeamento anônimo que cresce entre duas execuções do pmap é o heap. Muitos mapeamentos pequenos que continuam se multiplicando geralmente indicam pilhas de threads vazadas ou arquivos mapeados com mmap não fechados.
5. Descarte primeiro o cache de arquivos
$ clai mostre o uso de memória sem contar cache e buffers→ free -h total used free shared buff/cache availableMem: 62Gi 18Gi 2.1Gi 1.2Gi 42Gi 43GiOlhe para available, não para free. O Linux enche de propósito a RAM livre com cache de páginas e a devolve sob demanda. "Só 2 GB livres" com 43 GB available é um sistema saudável, não um vazamento.
6. Confirme que é o processo, não a máquina
$ clai verifique se o kernel andou matando processos por falta de memória→ sudo dmesg -T | grep -i 'killed process'Se o OOM killer disparou, o kernel registra qual processo escolheu e sua memória naquele momento. É a confirmação mais forte que você vai conseguir, e já está anotada para você.
Pegadinhas
- RSS conta a memória compartilhada duas vezes. Dois processos que compartilham uma biblioteca reportam ambos as mesmas páginas. Para um número real por processo, use o PSS de
smemou/proc/<pid>/smaps_rollup. - Reiniciar é um paliativo, não um diagnóstico. Isso zera o gráfico e esconde as evidências. Primeiro meça, depois reinicie.
- Limites de contêiner são invisíveis de dentro. Um processo em um contêiner vê a memória total do host em
free; o limite real está em/sys/fs/cgroup/memory.max.
Perguntas relacionadas
Quanto crescimento é um vazamento? Qualquer inclinação sustentada para cima com carga estável. Um processo que ganha 50 MB por hora e nunca devolve vai bater no OOM killer mais cedo ou mais tarde, não importa quanta RAM você adicione.
Uso alto de memória no Linux é ruim? Não por si só. RAM não usada é RAM desperdiçada — o kernel a usa como cache e a recupera sob pressão. Fique de olho no available e na atividade de swap.
Qual ferramenta encontra a linha de código que vaza? Valgrind (--leak-check=full) para C e C++, ou o profiler de heap da sua linguagem. Os comandos daqui encontram qual processo; corrigi-lo é outra ferramenta.
Veja também
- "Quem está comendo minha CPU agora?" — monitoramento de sistema em linguagem simples
- Mate o processo na porta 8080 — e outras coisas que você sempre pesquisa no Google
- df diz que o disco está cheio, du diz que não está
Diga o que você quer medir, e o CliAI escreve a chamada do pidstat que você teria que procurar de outro jeito. Instale em uma linha.