2012-03-09 14:13:35 +0000 2012-03-09 14:13:35 +0000
131
131

Linux: descubra que processo está a utilizar toda a RAM?

Antes de perguntar, só para ser claro: sim, eu sei sobre cache de disco, e não, não é o meu caso :) Desculpe, para este preâmbulo :)

estou a usar o CentOS 5. Todas as aplicações do sistema estão a trocar muito, e o sistema é muito lento. Quando faço free -m, aqui está o que tenho:

total used free shared buffers cached
Mem: 3952 3929 22 0 1 18
-/+ buffers/cache: 3909 42
Swap: 16383 46 16337

Então, na verdade, só tenho 42 Mb para usar! Tanto quanto sei, o -/+ buffers/cache não conta a cache do disco, por isso, na verdade, só tenho 42 Mb, certo? Pensei, posso estar errado, por isso tentei desligar o cache do disco e não teve qualquer efeito - a imagem permaneceu a mesma.

Então, decidi descobrir quem está a usar toda a minha RAM, e usei o top para isso. Mas, ao que parece, o relatório refere que nenhum processo está a utilizar a minha RAM. O único processo no meu topo é o MySQL, mas está a usar 0.1% da RAM e 400Mb de swap. A mesma imagem quando tento correr outros serviços ou aplicações - todos vão em swap, top mostra que o MEM não é utilizado (0.1% máximo para qualquer processo).

top - 15:09:00 up 2:09, 2 users, load average: 0.02, 0.16, 0.11
Tasks: 112 total, 1 running, 111 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4046868k total, 4001368k used, 45500k free, 748k buffers
Swap: 16777208k total, 68840k used, 16708368k free, 16632k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
 3214 ntp 15 0 23412 5044 3916 S 0.0 0.1 0:00.00 17m ntpd
 2319 root 5 -10 12648 4460 3184 S 0.0 0.1 0:00.00 8188 iscsid
 2168 root RT 0 22120 3692 2848 S 0.0 0.1 0:00.00 17m multipathd
 5113 mysql 18 0 474m 2356 856 S 0.0 0.1 0:00.11 472m mysqld
 4106 root 34 19 251m 1944 1360 S 0.0 0.0 0:00.11 249m yum-updatesd
 4109 root 15 0 90152 1904 1772 S 0.0 0.0 0:00.18 86m sshd
 5175 root 15 0 90156 1896 1772 S 0.0 0.0 0:00.02 86m sshd

Reiniciar não ajuda, e, por sinal é muito lento, o que eu normalmente não esperaria nesta máquina (4 núcleos, 4Gb de RAM, RAID1).

Então, com isso - tenho quase a certeza que isto não é uma cache de disco, quem está a usar a RAM, porque normalmente deveria ter sido reduzida e deixar outros processos usarem a RAM, em vez de ir para a troca.

Então, finalmente, a questão é - se alguém tem alguma ideia de como descobrir que processo está realmente a usar a memória tão intensamente?

Respostas (9)

115
115
115
2012-03-09 14:25:01 +0000

No Linux no processo top pode premir a tecla < para deslocar o visor de saída para a esquerda. Por defeito é ordenado pelo %CPU por isso se pressionar a tecla 4 vezes irá ordená-lo pelo VIRT que é o tamanho da memória virtual dando-lhe a sua resposta.

Outra forma de o fazer é:

ps -e -o pid,vsz,comm= | sort -n -k 2

deve dar-lhe e sair ordenado pelo tamanho virtual dos processos.

Aqui está a versão longa:

ps --everyone --format=pid,vsz,comm= | sort --numeric-sort --key=2
78
78
78
2016-02-09 21:12:26 +0000

Mostrar a memória de processos em megabytes e o caminho do processo.

ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n
14
14
14
2012-10-15 15:05:01 +0000

Apenas uma nota lateral num servidor mostrando os mesmos sintomas, mas ainda mostrando exaustão de memória. O que acabou por encontrar foi um sysctl.conf a partir de uma caixa com 32 GB de RAM e configuração para um DB com páginas enormes configuradas para 12000. Esta caixa tem apenas 2 GB de RAM, pelo que estava a atribuir toda a RAM livre às enormes páginas (apenas 960 delas). Configurando páginas enormes para 10, como nenhuma foi usada, liberou toda a memória.

Uma verificação rápida de /proc/meminfo para procurar as configurações HugePages_ pode ser um bom começo para a resolução de problemas em pelo menos um porco de memória inesperado.

5
5
5
2018-03-31 03:38:27 +0000

No meu caso a questão era que o servidor era um servidor virtual VMware com o módulo vmw_balloon activado:

$ lsmod | grep vmw_balloon
vmw_balloon 20480 0
vmw_vmci 65536 2 vmw_vsock_vmci_transport,vmw_balloon

Em execução:

$ vmware-toolbox-cmd stat balloon
5189 MB

Assim, cerca de 5 GB de memória foram de facto recuperados pelo anfitrião. Assim, apesar de ter 8 GB para o meu VM “oficialmente”, na prática foi muito menos:

$ free
              total used free shared buff/cache available
Mem: 8174716 5609592 53200 27480 2511924 2458432
Swap: 8386556 6740 8379816
2
2
2
2013-07-08 06:05:54 +0000

Você também pode usar o comando ps para obter mais informações sobre o processo.

ps aux | less
2
2
2
2016-10-21 10:51:37 +0000

Refiro isto e Memória total utilizada pelo processo Python? - Stack Overflow , esta é a minha resposta. Obtenho uma ferramenta específica de contagem de processos (python), agora.

# Megabyte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum/1024 " MB"}'
87.9492 MB

# Byte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum " KB"}'
90064 KB

Anexe a minha lista de processos.

$ ps aux | grep python
root 943 0.0 0.1 53252 9524 ? Ss Aug19 52:01 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root 950 0.6 0.4 299680 34220 ? Sl Aug19 568:52 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root 3803 0.2 0.4 315692 36576 ? S 12:43 0:54 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
jonny 23325 0.0 0.1 47460 9076 pts/0 S+ 17:40 0:00 python
jonny 24651 0.0 0.0 13076 924 pts/4 S+ 18:06 0:00 grep python

Referência

1
1
1
2016-03-14 20:50:46 +0000

Faça um script chamado show-memory-usage.sh com o conteúdo:

#!/bin/sh
ps -eo rss,pid,user,command | sort -rn | head -10 | awk '{ hr[1024**2]="GB"; hr[1024]="MB";
 for (x=1024**3; x>=1024; x/=1024) {
 if ($1>=x) { printf ("%-6.2f %s ", $1/x, hr[x]); break }
 } } { printf ("%-6s %-10s ", $2, $3) }
 { for ( x=4 ; x<=NF ; x++ ) { printf ("%s ",$x) } print ("\n") }
 '
0
0
0
2019-07-12 19:46:37 +0000

O meu servidor ubuntu DISTRIB RELEASE=18.04 no Hyper-V tinha a maior parte da memória utilizada, mas todos os processos eram bons. (Admito que removi pacotes snapd e unattended-upgr, mas 95% da memória ainda era utilizada)

A resposta é que o Hyper-V tem memória dinâmica, por isso levou memória para uso do sistema principal e o ubuntu sinalizou-o como usado.

Espero que ajude alguém.

0
0
0
2019-03-31 17:51:48 +0000

Isto também toma o id do processo, por tipo de MB utilizado, e descreve o comando (que criou o processo):

ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n