A memória irrecuperável é alocada para a laje considerada um cache usado ou disponível?


10

Depois de avaliar / proc / meminfo, vejo as seguintes informações:

$cat /proc/meminfo
MemTotal:       197852592 kB
MemFree:        64755992 kB
MemAvailable:   65655112 kB
Buffers:            4388 kB
Cached:           759952 kB
SwapCached:            0 kB
Active:           649472 kB
Inactive:         308340 kB
Active(anon):     193840 kB
Inactive(anon):    25316 kB
Active(file):     455632 kB
Inactive(file):   283024 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       4095932 kB
SwapFree:        4095932 kB
Dirty:                 8 kB
Writeback:             0 kB
AnonPages:        193560 kB
Mapped:            86208 kB
Shmem:             25684 kB
Slab:           49141432 kB
SReclaimable:     667284 kB
SUnreclaim:     48474148 kB
KernelStack:       25600 kB
PageTables:        15152 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    103022228 kB
Committed_AS:    1097276 kB
VmallocTotal:   34359738367 kB
VmallocUsed:    82484800 kB
VmallocChunk:   34126392952 kB
HardwareCorrupted:     0 kB
AnonHugePages:      4096 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      762368 kB
DirectMap2M:    51664896 kB
DirectMap1G:    148897792 kB

E especificamente a laje:

Slab:         46.8651GB
SReclaimable: 0.63637GB
SUnreclaim:   46.2286GB

Depois de avaliar o slabtop, vejo os seguintes como os maiores usuários:

      OBJS    ACTIVE  USE OBJ    SIZE   SLABS  OBJ/SLAB  CACHE SIZE                    NAME
  10855309  10855309     100%   1.07K  374321        29      11.42G         zfs_znode_cache
  10893059  10893059     100%   0.85K  294407        37       8.98G                 dnode_t
    412694    410756      99%  16.00K  206347         2       6.30G           zio_buf_16384
  12502304  12290111      98%   0.50K  390697        32       5.96G             kmalloc-512
  12776610  12744002      99%   0.29K  232302        55       3.54G          dmu_buf_impl_t
  10855309  10855309     100%   0.27K  374321        29       2.86G                sa_cache
    370776    370718      99%   8.00K   92694         4       2.83G            kmalloc-8192
   3269280   3028688      92%   0.32K   66720        49       1.02G               taskstats
  10899924  10899924     100%   0.08K  213724        51       0.82G  selinux_inode_security
  12161408  12150615      99%   0.06K  190022        64       0.72G              kmalloc-64
   3266592   3266072      99%   0.19K   77776        42       0.59G                  dentry
   5577600   5519569      98%   0.09K  132800        42       0.51G              kmalloc-96
     92872     82422      88%   4.00K   11609         8       0.35G            kmalloc-4096
   1962464   1953555      99%   0.12K   61327        32       0.23G             kmalloc-128
   6022528   6022428      99%   0.03K   47051       128       0.18G              kmalloc-32
      8356      8346      99%  12.00K    4178         2       0.13G           zio_buf_12288

O que torna a memória da laje recuperável versus irrecuperável? O que significa "irrecuperável" quando o sistema precisa alocar e não há memória suficiente disponível? É tão flexível quanto buff / cache?

Respostas:


1

A memória recuperável do SLAB pode ser reutilizada pelo kernel para outras coisas, irrecuperável não pode. O local em que qualquer alocação SLAB é contabilizada depende das propriedades do pool em que está alocado, o que, por sua vez, significa que é uma propriedade da própria alocação.

Um pouco OT, mas, pelo que vale a pena, esse enorme pedaço de memória SLAB irrecuperável é provavelmente o ZFS ARC.


Como esta é uma pergunta muito técnica, você poderia fornecer citações para sua resposta?
Zhro 27/07

Claro, mas pode demorar um pouco, já que vou ter que pesquisar no código do kernel para encontrar os bits relacionados a isso (infelizmente não está documentado muito em nenhum lugar, e meu conhecimento sobre isso é amplamente baseado na inspeção do código) .
Austin Hemmelgarn

@AustinHemmelgarn já faz um tempo e também estou interessado.
Gregg Leventhal
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.