Alto uso de RAM do Linux por motivo desconhecido


9

depois de pesquisar isso e encontrar apenas postagens de pessoas que não interpretam a figura "em cache" corretamente, decidi fazer essa pergunta.

Eu tenho alguns servidores em mãos, que agem estranhamente. Ou seja, seu uso de RAM é muito alto, sem motivo aparente. Parece que um processo invisível possui muita RAM "usada" (e eu quero dizer "usada").

Aqui estão algumas informações:

  • todos os servidores executam o SLES 11
  • o kernel é 3.0.76
  • todos os servidores são executados como convidados em uma infraestrutura VMWare ESX
  • Não configurei os servidores e não tive voz na escolha do SO nem tenho acesso à infraestrutura de virtualização
  • todos os servidores são configurados da mesma forma e executam o mesmo conjunto de software (é um cluster e sim, eu sei, cluster virtualizado, yada yada, como foi dito: eu tinha e não tenho voz nisso)

E alguma saída do shell:

root@good-server:# free -m
             total       used       free     shared    buffers     cached
Mem:         15953      14780       1173          0        737       8982
-/+ buffers/cache:       5059      10894
Swap:        31731          0      31731

root@good-server:# python ps_mem.py
[... all processes neatly listed ...]
---------------------------------
                          4.7 GiB
=================================

root@bad-server:# free -m
             total       used       free     shared    buffers     cached
Mem:         15953      15830        123          0        124       1335
-/+ buffers/cache:      14370       1583
Swap:        31731         15      31716

root@bad-server:# python ps_mem.py
[... all processes neatly listed ...]
---------------------------------
                          4.0 GiB
=================================

Conteúdo de / proc / meminfo do bom servidor

MemTotal:       16336860 kB
MemFree:          112356 kB
Buffers:          138384 kB
Cached:          1145208 kB
SwapCached:         1244 kB
Active:          4344336 kB
Inactive:        1028744 kB
Active(anon):    3706796 kB
Inactive(anon):   382724 kB
Active(file):     637540 kB
Inactive(file):   646020 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32493560 kB
SwapFree:       32477728 kB
Dirty:              1248 kB
Writeback:             0 kB
AnonPages:       4087776 kB
Mapped:            60132 kB
Shmem:               156 kB
Slab:             274968 kB
SReclaimable:     225864 kB
SUnreclaim:        49104 kB
KernelStack:        4352 kB
PageTables:        16400 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40661988 kB
Committed_AS:    6576912 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      311400 kB
VmallocChunk:   34359418748 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       73728 kB
DirectMap2M:    16703488 kB

Conteúdo de / proc / meminfo do servidor inválido

MemTotal:       16336860 kB
MemFree:         1182320 kB
Buffers:          756244 kB
Cached:          8695688 kB
SwapCached:            0 kB
Active:         13499680 kB
Inactive:         843208 kB
Active(anon):    4853460 kB
Inactive(anon):    37372 kB
Active(file):    8646220 kB
Inactive(file):   805836 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32493560 kB
SwapFree:       32493560 kB
Dirty:              1268 kB
Writeback:             0 kB
AnonPages:       4890180 kB
Mapped:            84672 kB
Shmem:               252 kB
Slab:             586084 kB
SReclaimable:     503716 kB
SUnreclaim:        82368 kB
KernelStack:        5176 kB
PageTables:        19684 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40661988 kB
Committed_AS:    6794180 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      311400 kB
VmallocChunk:   34359419468 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      112640 kB
DirectMap2M:    16664576 kB

TL; DR - se você comparar estes lado a lado, eis as principais diferenças (BADserver - GOODserver):

MemFree       -1070 MB
Cached        -7550 MB
Active        -9155 MB
Active(anon)  -1147 MB
Active(file)  -8009 MB
AnonPages     - 802 MB

As outras diferenças são bastante pequenas e dentro dos limites que se pode esperar (mas você pode ver por si mesmo)

Como você pode ver, no bom servidor, o total de toda a memória RES e SHR de todos os processos está praticamente alinhado com free -ma saída do valor "usado - / + buffers / cache" - que é o que você esperaria, certo ?

Agora olhe para o servidor inválido: free -ma saída do valor "usado - / + buffers / cache" é cerca de três vezes maior do que você poderia esperar, resumindo tudo o que pspode lhe mostrar.

Isso também corresponde ao que /proc/meminfome diz.

Até agora, não tenho ideia de como isso é possível. O que pode estar acontecendo aqui?


Ambas as saídas que /proc/meminfovocê alega são para o bom servidor? Você também pode fornecer uma referência ruim ao servidor?
— Matthew Ife

Você tem acesso ao console do VMware vSphere ou ao Virtual Center? Ou alguma maneira de ver algumas coisas relacionadas à memória do hóspede?
— ewwhite

Por favor, postar a saída do / proc / zoneinfo
— Matthew Ife

@whwhite não, infelizmente não tenho acesso a nada além do próprio sistema operacional.
— Luxifer

@MatthewIfe o rótulo meminfo foi um erro de digitação - corrigiu ... agora puxando o conteúdo da zoneinfo
— luxifer

Respostas:


12

Eu acho que você pode ter um problema de balão de memória do VMware . Há uma chance de o comprometimento excessivo da memória na infraestrutura do vSphere ser muito alto. Você não conseguirá corrigir isso sem acessar o vSphere vCenter, mas poderá detectá-lo de dentro de suas máquinas virtuais, supondo que o vmtools esteja instalado:

Você pode postar a saída de vmware-toolbox-cmd stat balloon?

Além disso, você recebeu 16 GB de RAM. Pergunte a quem está no controle da infraestrutura se há algum limite manual de RAM colocado nas VMs em questão.


Depois de ler como o balão funciona no vmware linux vms, acho que essa é a causa. Estou bastante impressionado, pois eles não oferecem uma maneira do lado da VM para dar conta das páginas 'usadas'.
— Matthew Ife

1
Isso está realmente correto, eu acho ... o servidor bom mostra "o MB" ... o servidor ruim mostra "10092 MB", o que está praticamente alinhado com o que estamos vendo!
— Luxifer

@ luxifer Então agora vocês tem que consertar isso . O que significa remover um limite de RAM artificial na VM ou vMotioning para outro host ESXi. Peça à equipe de infraestrutura da VMware para verificar se esse é um problema mais amplo .
— ewwhite

@ewwhite eu os notifico com certeza. No entanto, é a infraestrutura de um de nossos clientes e, normalmente, eles deveriam ter identificado isso. Infelizmente, não é assim que os grandes provedores de serviços de TI em todo o mundo parecem funcionar;)
— luxifer

@luxifer Sério, acho que isso pode acontecer em todos os tipos de organizações , e as pessoas encarregadas de gerenciar a infraestrutura do vSphere parecem não perceber.
— ewwhite
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.