Linux: a memória do processo foi responsável pelo valor armazenado em cache

Question

Eu tenho um caso muito estranho de uso de memória em nosso servidor Ubuntu. Um processo (que é pesquisado a partir de sphinxsearch) alocou quase toda a memória disponível, e seu VSize, RSS e SHR são quase iguais (cerca de 18 GB). Mas o que me deixa realmente surpreso é que o comando free trata a maior parte dessa memória como "armazenada em cache" - o que sempre achei ser "propriedade do kernel", isto é - não vinculada a um processo específico. Além disso, ao mesmo tempo, ele é marcado como "compartilhado", embora não haja outros processos com esse uso de memória tão alto.

Então, free -h mostra:

root@st3:/proc/31633# free -h
             total       used       free     shared    buffers     cached
Mem:           23G        22G       649M        18G        62M        18G
-/+ buffers/cache:       4.4G        19G
Swap:           0B         0B         0B

Mas, para o processo searchd, temos:

VmPeak: 20451512 kB
VmSize: 20413352 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:  20325488 kB
VmRSS:  20287332 kB
VmData:  1344768 kB
VmStk:       136 kB
VmExe:      4268 kB
VmLib:     16204 kB
VmPTE:     39924 kB
VmSwap:        0 kB

Portanto, não consigo realmente entender o que é uso real aqui - parece que a maioria da memória é usada apenas para cache, então não deve ser uma preocupação, OTOH já encontramos várias falhas com "Não é possível alocar memória" para simples garfo, é por isso que estou tentando entender isso.

Se você quiser mais, aqui está o meminfo completo da máquina , e aqui é a lista completa de mapeamentos de memória do searchd '.

E olhando para o último, eu vejo muito:

7f7c905b7000-7f7c90713000 rw-s 00000000 00:05 226801755                  /dev/zero (deleted)
7f7c90713000-7f7c91fff000 rw-s 00000000 00:05 225400928                  /dev/zero (deleted)
7f7c92055000-7f7c921c7000 rw-s 00000000 00:05 226767567                  /dev/zero (deleted)
7f7c921da000-7f7c92338000 rw-s 00000000 00:05 226774289                  /dev/zero (deleted)

... então eu posso apenas imaginar que isso poderia ser um ponto, que o searchd está fazendo alguns truques inteligentes para manter a memória, mas no mesmo ponto tê-lo disponível para o sistema quando necessário. E talvez não funcione totalmente como esperado. Mas esse é apenas meu palpite, e posso estar completamente errado aqui.

    

Answer 1

A entrada 'Em cache' está contando o número de páginas marcadas como 'compartilhadas'. Os mapeamentos fornecidos são marcados como compartilhados.

O kernel internamente não vê nenhuma diferença na memória que é definida com o sinalizador compartilhado e um arquivo que simplesmente foi criado pelo sistema operacional e armazenado em cache (todos os arquivos no cache são efetivamente mapeamentos compartilhados).

O fato de isso ser apoiado por / dev / zero é irrelevante. A razão pela qual eles são compartilhados é quase certamente porque os mesmos dados de memória precisam ser disponibilizados para todos os processos filhos que modificam os dados.

De uma perspectiva semântica, ele se comporta como memória normalmente alocada (ou memória anônima), dado que realmente não há nenhum arquivo utilizável para o qual você possa remover páginas (/ dev / zero é um arquivo que você não pode salvar) e as páginas mova-se para swap se eles não estiverem em uso.

Então - confusamente - as contas de dados são 'armazenadas em cache', mas na verdade são tratadas como memória anonimamente apoiada.

Você pode ver isso exatamente no seu meminfo:

root@st3:/proc/31633# cat /proc/meminfo 
MemTotal:       24690512 kB
...
Cached:         19504260 kB
...
Active(anon):    3734376 kB
Inactive(anon): 18973184 kB
Active(file):     227128 kB
Inactive(file):   365828 kB
...
Mapped:         19237684 kB
Shmem:          18985464 kB
...

O mesmo comportamento ocorre se você estiver usando memória compartilhada IPC também.

'file' é realmente o que é suportado, 'anon' é o que não tem um ficheiro que o suporte - como os seus mapeamentos.