Eu sempre uso top
para procurar os maiores processos VSIZE / VSS ou RSS,
Depois, vou para o subdiretório /proc/<.PID>/.
E examine o arquivo smaps
para o arquivo de objeto mais ofensivo, o soquete e, muitas vezes, a biblioteca.
Em um servidor Centos 7 com 32GB de memória RAM, estou executando alguns programas, como MySQL, Apache2, PHP. Recentemente, eu queria verificar a quantidade de memória RAM deixada enquanto eu planejava instalar mais alguns programas, para minha surpresa, a quantidade de memória estava baixa! Depois de investigar, descobri que mais de 20 GB estavam sendo usados pela Slab. 2 dias atrás eu abandonei o cache para que o uso da placa baixasse para 0 e aumentasse lentamente novamente. Ao monitorá-lo com um programa, notei o uso subindo em um padrão linear. Nas últimas 24 horas aumentou com ~ 5200MB (aumento total de 13GB em 60 horas). O total de dados no disco está abaixo de 40 GB. A saída de 'find /' é meramente alguns MB. Parece que existem muitas coisas se os dentries estão em cache?
Tenho postagens dizendo que o NSS que veio com curl foi a causa. Verifiquei a versão do NSS que está instalada e é uma versão que deve ter a correção aplicada.
Também encontrei postagens sugerindo o uso de vfs_cache_pressure, mas o aumento não parece impedir que o uso suba para valores extremamente altos.
Gostaria de saber o que é uma quantidade normal de memória de identidades para um disco pequeno < 50 GB? E como posso encontrar a fonte e como corrigir isso?
Imagens relacionadas:
Screenshot of slabtop: aqui
Gráfico da memória recuperável e armazenada em cache da laje: aqui
Editar:
# sysctl -n vm.vfs_cache_pressure
10000
(costumava ser 100, eu aumentei em x100, mas a memória ainda aumenta a mesma quantidade)
# find / -type d -size +10M -ls
#
(sem saída)
Quanto ao cronjobs, além da rotação diária de log existe um script que faz algumas conexões tcp para obter dados e armazena isso em um banco de dados (sockets Raw, sem curvatura ou qualquer coisa). Além do cronjob existem 2 cronjobs de backup que são executados uma vez por semana. A única coisa que deve ser capaz de causar E / S é o servidor web apache2 com o SMF instalado. Pessoalmente, eu suspeito que possa ser mod_rewrite verificando se existem arquivos ou algo assim.
Versão completa do kernel:
Linux #1 SMP Tue Mar 18 14:48:24 CET 2014 x86_64 x86_64 x86_64 GNU/Linux
Software instalado: pastebin
Saída de ps aux: pastebin
# strace -fc -e trace=access curl 'https://www.google.com' > /dev/null
Process 7342 attached
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 259 100 259 0 0 903 0 --:--:-- --:--:-- --:--:-- 905
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.000048 0 7877 7872 access
------ ----------- ----------- --------- --------- ----------------
100.00 0.000048 7877 7872 total
Eu sempre uso top
para procurar os maiores processos VSIZE / VSS ou RSS,
Depois, vou para o subdiretório /proc/<.PID>/.
E examine o arquivo smaps
para o arquivo de objeto mais ofensivo, o soquete e, muitas vezes, a biblioteca.