Para onde minha RAM foi e como interpretar a saída de memória do topo?

Question

Por um tempo, eu encontro falta de RAM no meu servidor web Debian (VPS / máquina virtual). Isso não seria incomum, se acontecesse regularmente. Mas eles não. Aqui está um gráfico de Munin:

Pararesolveressesenigmas,acompanheimeusistemacomatop.Aquiestãodoisinstantâneosdas7:00AMe9:00AM-duranteeapósafaltadeRAM(usandoaopção-mparaverasinformaçõesrelacionadasàmemória):

ATOP-<snip>2014/09/1007:00:02------10m0selapsed<snip>MEM|tot2.0G|free79.1M|cache102.4M|dirty0.1M|buff53.2M|slab90.8M|||SWP|tot2.0G|free2.0G|||||vmcom748.1M|vmlim3.0G|DSK|sda|busy1%|read917|write1695|KiB/w13|MBr/s0.01|MBw/s0.04|avio1.22ms|<snip>PIDMINFLTMAJFLTVSTEXTVSIZERSIZEVGROWRGROWRUIDEUIDMEMCMD1/15137171021810709K874.5M206.2M0K128Kmysqlmysql10%mysqld40861660450K228.1M21896K0K0Kwww-datawww-data1%apache219131165999450K225.5M19604K-2652K-2292Kwww-datawww-data1%apache214696080450K222.6M18508K256K64Kwww-datawww-data1%apache2230383470450K222.3M18496K0K0Kwww-datawww-data1%apache240857210450K222.1M18308K0K0Kwww-datawww-data1%apache2106397900450K224.9M18284K768K932Kwww-datawww-data1%apache2191581991450K222.1M18064K0K52Kwww-datawww-data1%apache218953300450K221.8M18020K0K0Kwww-datawww-data1%apache26661334622450K224.0M17700K1512K-780Kwww-datawww-data1%apache2125708080450K221.7M17668K512K508Kwww-datawww-data1%apache21981700450K214.5M15336K0K0Krootroot1%apache218209399602277K55592K14728K55592K14728Ktilltill1%python18210276004K43292K10544K43292K10544Kmuninmunin1%munin-update119765060149K18788K6512K0K0Krootroot0%atop193417504K52228K5852K0K0Krootroot0%munin-node17993004K67020K5712K0K0Kpostgreypostgrey0%/usr/sbin/post200000346K244.3M5668K0K0Krootroot0%rsyslogd14557007163K234.9M5284K0K0Krootroot0%php5-fpm14558007163K234.9M4564K0K0Kwww-datawww-data0%php5-fpm14559007163K234.9M4564K0K0Kwww-datawww-data0%php5-fpm32800134K572.6M2932K0K0Krootroot0%console-kit-da<snip>

E...

ATOP-vmd19892014/09/1009:00:02------10m0selapsed<snip>MEM|tot2.0G|free1.5G|cache88.8M|dirty0.1M|buff19.2M|slab25.8M|||SWP|tot2.0G|free2.0G|||||vmcom748.0M|vmlim3.0G|DSK|sda|busy0%|read453|write1991|KiB/w12|MBr/s0.01|MBw/s0.04|avio1.01ms|<snip>PIDMINFLTMAJFLTVSTEXTVSIZERSIZEVGROWRGROWRUIDEUIDMEMCMD1/1613717189010709K874.5M206.3M0K0Kmysqlmysql10%mysqld230387437450K222.6M18620K0K40Kwww-datawww-data1%apache2239306920450K220.6M18568K0K0Kwww-datawww-data1%apache228738478404K126.4M18328K126.4M18328Kmuninmunin1%munin-update269903921450K220.5M18088K0K112Kwww-datawww-data1%apache22655211502450K220.3M17788K512K576Kwww-datawww-data1%apache228744144304K129.1M17636K129.1M17636Kmuninmunin1%/usr/share/mun274246020450K219.8M17504K8K240Kwww-datawww-data1%apache2270002160450K219.8M17308K8K104Kwww-datawww-data1%apache22829029770450K219.9M17200K219.9M17200Kwww-datawww-data1%apache219817680450K214.5M15340K0K0Krootroot1%apache2282874291450K215.0M10384K215.0M10384Kwww-datawww-data1%apache2287271840450K214.5M9300K214.5M9300Kwww-datawww-data0%apache2287281910450K214.5M9300K214.5M9300Kwww-datawww-data0%apache2119764900149K18788K6512K0K0Krootroot0%atop193442804K52228K5852K0K0Krootroot0%munin-node200000346K244.3M5668K0K0Krootroot0%rsyslogd28745103604K52228K5580K52228K5580Krootroot0%munin-node[::14557007163K234.9M5284K0K0Krootroot0%php5-fpm17993004K67020K4844K0K0Kpostgreypostgrey0%/usr/sbin/post14558007163K234.9M4564K0K0Kwww-datawww-data0%php5-fpm14559007163K234.9M4564K0K0Kwww-datawww-data0%php5-fpm32800134K572.6M2932K0K0Krootroot0%console-kit-da<snip>

Desculpepelalongalista-sónãoqueroperderacausa.Noentanto,meuproblemaé:nãovejoacausa.Hásignificativamentemenosmemória"livre" no status (superior), mas nenhum processo explicaria por que, onde está a memória ...

Meu pensamento está incorreto com isso?

Atualizar

De acordo com o conselho de Patrick, coletei /proc/meminfo - durante uma fase de falta de RAM e depois. Em prol da visibilidade fácil, coloco o conteúdo em uma tabela:

               mem-shortage   a bit later

MemTotal:        2060776 kB    2060776 kB
MemFree:          252896 kB    1608532 kB   *
Buffers:           15464 kB      12060 kB
Cached:            71864 kB      62800 kB
SwapCached:         4160 kB       4160 kB
Active:           268020 kB     253368 kB
Inactive:         134988 kB     132300 kB
Active(anon):     225940 kB     220872 kB
Inactive(anon):    97296 kB     220872 kB   *
Active(file):      42080 kB      32496 kB
Inactive(file):    37692 kB      29116 kB
Unevictable:        6540 kB       6680 kB
Mlocked:            6540 kB       6680 kB
SwapTotal:       2096476 kB    2096476 kB
SwapFree:        2081568 kB    2081568 kB
Dirty:                 0 kB        116 kB
Writeback:             0 kB          0 kB
AnonPages:        318084 kB     313364 kB
Mapped:            20692 kB      20408 kB
Shmem:              4208 kB       9896 kB
Slab:              24336 kB      23936 kB
SReclaimable:      10252 kB       9316 kB
SUnreclaim:        14084 kB      14620 kB
KernelStack:        1464 kB       1544 kB
PageTables:         8396 kB       9544 kB
NFS_Unstable:          0 kB          0 kB
Bounce:                0 kB          0 kB
WritebackTmp:          0 kB          0 kB
CommitLimit:     3126864 kB    3126864 kB
Committed_AS:     744764 kB     761812 kB
VmallocTotal:   34359738367 kB  34359738367 kB
VmallocUsed:         272976 kB       272976 kB
VmallocChunk:   34359464431 kB  34359464431 kB
HardwareCorrupted:     0 kB          0 kB
AnonHugePages:         0 kB          0 kB
HugePages_Total:       0             0
HugePages_Free:        0             0
HugePages_Rsvd:        0             0
HugePages_Surp:        0             0
Hugepagesize:       2048 kB       2048 kB
DirectMap4k:      282560 kB     282560 kB
DirectMap2M:     1814528 kB    1814528 kB

Eu só vejo duas diferenças significantes (não no sentido estatístico), marcadas com um asterisco (*), mas eu não acho, elas me dizem para onde foi a RAM.

Também verifiquei a memória compartilhada (o melhor que pude) ... e não encontrei nenhuma.

# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

Eu também verifico processos ocultos usando unhide . Mas, exceto por um falso positivo (problema conhecido com o Debian), parece não haver nenhum processo oculto.

Mais alguma idéia de por que 1.2 GB de RAM estão em uso - e depois não? Este poderia ser outro problema causado pela arquitetura do servidor virtual?

Atualizar

Eu segui a sugestão de Sergio para consultar lsmod e verificar se há balão de memória. A coluna size não diz nada de útil, mas há um processo vmw_balloon - então parece ser realmente uma questão de mudar a memória entre as máquinas virtuais. Pergunta respondida:)

# During high RAM usage (removed middle part)
$ lsmod | sort -r -k 2,2n
Module                  Size  Used by
crc16                  12343  1 ext4
crc_t10dif             12348  1 sd_mod
libcrc32c              12426  2 xfs,btrfs
mperf                  12453  0
ata_generic            12490  0
pcspkr                 12632  0
vmw_balloon            12657  0           <=
ac                     12668  0
i2c_piix4              12704  0
coretemp               12898  0
<snip>
reiserfs              193501  0
drm                   211856  2 ttm,vmwgfx
ext4                  381419  1
xfs                   628913  0
btrfs                 641551  0

    

Answer 1

Provavelmente, sua máquina virtual está sofrendo algum tipo de operação de balão de memória solicitada na plataforma de virtualização. Você pode tentar confirmar isso procurando por um módulo relacionado com lsmod (o nome muda de uma plataforma de virtualização para outra, mas deve ser bastante distinto).

Quando o ballooning de memória está ativado, um Host de virtualização pode mover recursos de memória de uma VM para outra, quando necessário. A pedido do referido Host, o módulo do kernel do Guest reserva a quantidade indicada de RAM física (física do ponto de vista do SO em execução no Guest), para garantir que nenhum outro processo possa fazer uso disso. Em seguida, o Host reatribui os recursos físicos reais a outro convidado.

O efeito no Guest é exatamente o que você está vendo, muita memória usada na memória sem proprietário aparente.

Se você não tem controle sobre essa plataforma de virtualização, peça ao seu provedor informações sobre a configuração real dos parâmetros de balão para a sua máquina virtual.