O que usou a memória Linux? Cache baixo, buffer baixo, não uma VM

Antes de tudo, sim, eu li o LinuxAteMyRAM , o que não explica minha situação.

# free -tm
             total       used       free     shared    buffers     cached
Mem:         48149      43948       4200          0          4         75
-/+ buffers/cache:      43868       4280
Swap:        38287          0      38287
Total:       86436      43948      42488
#

Como mostrado acima, a -/+ buffers/cache:linha exibida indica que a taxa de memória usada é muito alta. No entanto, da saída de top, não vejo nenhum processo usado com mais de 100 MB de memória.

Então, o que usou a memória?

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28078 root      18   0  327m  92m  10m S    0  0.2   0:25.06 java
31416 root      16   0  250m  28m  20m S    0  0.1  25:54.59 ResourceMonitor
21598 root     -98   0 26552  25m 8316 S    0  0.1  80:49.54 had
24580 root      16   0 24152  10m  760 S    0  0.0   1:25.87 rsyncd
 4956 root      16   0 62588  10m 3132 S    0  0.0  12:36.54 vxconfigd
26703 root      16   0  139m 7120 2900 S    1  0.0   4359:39 hrmonitor
21873 root      15   0 18764 4684 2152 S    0  0.0  30:07.56 MountAgent
21883 root      15   0 13736 4280 2172 S    0  0.0  25:25.09 SybaseAgent
21878 root      15   0 18548 4172 2000 S    0  0.0  52:33.46 NICAgent
21887 root      15   0 12660 4056 2168 S    0  0.0  25:07.80 SybaseBkAgent
17798 root      25   0 10652 4048 1160 S    0  0.0   0:00.04 vxconfigbackupd

Esta é uma máquina x86_64 (não um servidor de marca comum) executando o x84_64 Linux, não um contêiner em uma máquina virtual. Kernel ( uname -a):

Linux 2.6.16.60-0.99.1-smp #1 SMP Fri Oct 12 14:24:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Conteúdo de /proc/meminfo:

MemTotal:     49304856 kB
MemFree:       4066708 kB
Buffers:         35688 kB
Cached:         132588 kB
SwapCached:          0 kB
Active:       26536644 kB
Inactive:     17296272 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:     49304856 kB
LowFree:       4066708 kB
SwapTotal:    39206624 kB
SwapFree:     39206528 kB
Dirty:             200 kB
Writeback:           0 kB
AnonPages:      249592 kB
Mapped:          52712 kB
Slab:          1049464 kB
CommitLimit:  63859052 kB
Committed_AS:   659384 kB
PageTables:       3412 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    478420 kB
VmallocChunk: 34359259695 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

dfrelata que não há grande consumo de memória dos tmpfssistemas de arquivos.

A memória no Linux pode ser uma fera estranha para diagnosticar e entender.

Sob operação normal, a maioria, se não a totalidade, sua memória será alocada para uma tarefa ou outra. Alguns serão alocados aos processos em primeiro plano em execução no momento. Alguns estarão armazenando dados armazenados em cache do disco. Alguns manterão dados associados a processos que não estão sendo executados ativamente naquele momento específico no tempo.

Um processo no Linux possui seu próprio espaço de endereço virtual (VIRT na saída de top). Ele contém todos os dados associados ao processo e pode ser considerado o quão "grande" o processo é. No entanto, é raro que toda essa memória faça parte ativamente do mapa de memória "real" (RES na saída de top). O RES, ou memória residente, são os dados diretamente acessíveis na RAM no momento. Além disso, também há memória compartilhada (SHR). Isso pode ser compartilhado entre várias instâncias do mesmo processo. Portanto, a memória em uso por um processo está em qualquer momento RES mais SHR, mas se houver mais de uma instância do processo usando a memória compartilhada, o uso será RES mais RES mais RES ... mais SHR.

Então, por que a diferença entre RES e VIRT? Certamente, se um processo tem um bloco de memória alocada, ele está alocado, não é? Não. A memória é alocada em páginas e as páginas podem ser Ativas ou Inativas. Os ativos são os que estão em RES. Inativos são "o resto". Eles podem ser empurrados para um lado, pois não estão sendo acessados ​​no momento. Isso significa que eles podem ser trocados para o disco se a memória ficar fraca. Mas eles não vão direto ao disco. Primeiro eles se sentam em um cache. Você não deseja trocar o tempo todo, portanto, há um buffer entre o aplicativo e o espaço de troca. Esses buffers estão mudando constantemente à medida que o trocador seleciona um processo diferente para executar e diferentes páginas se tornam ativas e inativas. E tudo o que está acontecendo é muito rápido para um mero humano acompanhar.

E acima de tudo, há os buffers de disco. Não apenas a memória inativa vai para um cache, mas quando esse cache é trocado para o disco, ele primeiro vai para um buffer de disco para ser enfileirado para gravação. Portanto, essa é uma segunda camada de cache na mistura. E esses buffers de disco também são usados ​​por outras partes do sistema para buffer de E / S geral. Então eles estão mudando constantemente também.

Então, o que você está vendo em coisas como tope freeetc são instantâneos instantâneos do estado atual da máquina ou estatísticas agregadas por um período de tempo. Quando você lê os dados, está desatualizado.

Qualquer processo pode acessar grandes quantidades de memória, mas raramente é sensato fazê-lo. De qualquer maneira, ele não pode acessar toda a memória de uma só vez; portanto, a memória que não está sendo visualizada no momento é movida para o cache, a menos que seja sinalizada especificamente como "bloqueada no núcleo".

Portanto, a quantidade de memória "usada" por um aplicativo e a quantidade de memória que "possui" são duas coisas completamente diferentes. Na verdade, grande parte do espaço de dados de um aplicativo está no cache, não na memória "principal", mas como o cache está na RAM na maioria das vezes, é disponibilizado instantaneamente e só precisa ser "ativado" para se tornar a memória "principal". Ou seja, a menos que tenha sido trocado para o disco, quando for necessário desassociar (o que pode ser rápido se estiver no buffer).

Devido à natureza de alta velocidade da fera e ao fato de os números estarem sempre mudando, os números podem até mudar parcialmente no cálculo do que são, portanto, nunca é possível dizer exatamente "isso é quanta memória está sendo usada" perspectiva de um usuário. O meminfo é um instantâneo fornecido pelo kernel, mas como é o kernel que está sendo executado, não está necessariamente mostrando o estado real de qualquer processo de uso da memória, pois nenhum processo está sendo executado ativamente naquele momento - é entre processos.

Como eu disse, é tudo muito confuso.

Mas no final das contas, isso realmente não importa. O que importa não é quanta memória você tem "livre", mas quanto espaço de troca você usou e com que frequência o espaço de troca está sendo acessado. É a troca que torna o sistema lento, e não a falta de memória (embora a falta de memória cause excesso de troca). Se você tem muita memória usada, mas não está usando nenhum espaço de troca (ou muito pouco), as coisas são normais. A memória livre em geral não é desejável e, geralmente, é apenas de transição, já que era usada para uma finalidade, mas ainda não foi alocada para outra; por exemplo, era memória cache e foi trocada para o disco, mas ainda não foi usado para mais nada, ou foram buffers de disco, os buffers foram liberados para o disco, mas nenhum aplicativo solicitou ainda o cache.

Esta é uma parte da resposta:

Há uma diferença entre o que é designado como memória "Usado" (no comando "livre") e "Memória alocada para processos ativos (do usuário)" (em / proc / meminfo). Ok, seu sistema tem 48149 MB no total (aproximadamente 47Gb)

Se você olhar para o seu / proc / meminfo, verá: Inativo: 17296272 kB = (aproximadamente 16,5 Gb) - A memória inativa pode ser proveniente de processos que foram finalizados. Também pode ser uma memória que não é usada há muito tempo por um processo ativo. A memória não é "liberada" apenas porque o processo foi finalizado. Por quê? porque é mais trabalho. A mesma página de memória pode ser usada novamente, então o kernel do linux apenas deixa os dados na lista "inativo" até que um processo precise.

Esta página explica um pouco disso. http://careers.directi.com/display/tu/Understanding+and+optimizing+Memory+utilization ; Leia a seção no PFRA (algoritmo de recuperação de quadro de página) usada pelo kernel do Linux: "As páginas incluídas nos caches de disco e memória não referenciados por qualquer processo devem ser recuperadas antes das páginas pertencentes aos espaços de endereço dos processos no modo de usuário" "Recuperando" significa removê-los de "usado" (inativo + ativo) e para "livre".

Isso explica o gerenciamento de memória com mais detalhes: como as listas ativas e inativas funcionam e como as páginas se movem entre elas https://www.cs.columbia.edu/~smb/classes/s06-4118/l19.pdf

Acredito que também haja memória usada pelo kernel para estruturas de dados e que isso apareça como "laje 1049464 kb" (~ 1 GB). Acredito, mas não tenho certeza de que isso seja contado separadamente.

Você usa o NFS?
Pode valer a pena correr de slabtop -oqualquer maneira, a nfs_inode_cachelata pode ficar fora de controle.

A figura que você deve observar é usada como swap , na saída "0", o que significa que você NÃO ficou sem memória RAM. Enquanto seu sistema não estiver trocando memória, não se preocupe com os outros números, que são muito difíceis de interpretar.

Edit: Ok, parece que minha resposta está sendo considerada enigmática e não concisa. Então deixe-me elaborar.

Eu acho que o principal problema aqui está na interpretação da saída de top / ps, o que não é muito preciso. Por exemplo, como vários usos das mesmas bibliotecas compartilhadas não são calculados como você esperaria, consulte, por exemplo, http://virtualthreads.blogspot.ch/2006/02/understanding-memory-usage-on-linux.html

O que é, no entanto, absolutamente preciso é que, se o tamanho da troca for exatamente zero, o sistema não ficará sem memória (ainda). Obviamente, essa é uma afirmação muito clara, mas, para criar um perfil do uso real da memória de seus sistemas, top não será a coisa certa. (E se você olhar para cima, pelo menos classifique a saída para virt ou% mem.)

Veja também http://elinux.org/Runtime_Memory_Measurement