Por que meu kernel Linux não pode recuperar sua memória slab?

Question

Eu tenho um sistema que sofria de um uso de memória cada vez maior até chegar ao ponto em que ele estava atingindo o swap mesmo para coisas mundanas e, consequentemente, tornando-se pouco responsivo. O culpado parece ter sido memória alocada pelo kernel, mas estou tendo dificuldade em descobrir o que exatamente estava acontecendo no kernel.

Como posso saber quais threads / módulos do kernel / o que quer que seja responsável por partes específicas do uso de memória do kernel?

Aqui está um gráfico do uso de memória do sistema ao longo do tempo:

O valor slab_unrecl , que cresce com o tempo, corresponde ao campo SUnreclaim em /proc/meminfo .

Quando eu executei slabtop no final desse gráfico e o classifiquei pelo tamanho do cache, aqui está o que ele me mostrou:

 Active / Total Objects (% used)    : 15451251 / 15530002 (99.5%)
 Active / Total Slabs (% used)      : 399651 / 399651 (100.0%)
 Active / Total Caches (% used)     : 85 / 113 (75.2%)
 Active / Total Size (% used)       : 2394126.21K / 2416458.60K (99.1%)
 Minimum / Average / Maximum Object : 0.01K / 0.16K / 18.62K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
3646503 3646503 100%    0.38K 173643       21   1389144K kmem_cache
3852288 3851906  99%    0.06K  60192       64    240768K kmalloc-64
3646656 3646656 100%    0.06K  56979       64    227916K kmem_cache_node
1441760 1441675  99%    0.12K  45055       32    180220K kmalloc-128
499136 494535  99%    0.25K  15598       32    124784K kmalloc-256
1066842 1066632  99%    0.09K  25401       42    101604K kmalloc-96
101430 101192  99%    0.19K   4830       21     19320K kmalloc-192
 19168  17621  91%    1.00K    599       32     19168K kmalloc-1024
  8386   7470  89%    2.00K    525       16     16800K kmalloc-2048
 15000   9815  65%    1.05K    500       30     16000K ext4_inode_cache
 66024  45955  69%    0.19K   3144       21     12576K dentry
369536 369536 100%    0.03K   2887      128     11548K kmalloc-32
 18441  16586  89%    0.58K    683       27     10928K inode_cache
 44331  42665  96%    0.19K   2111       21      8444K cred_jar
 12208   7529  61%    0.57K    436       28      6976K radix_tree_node
   627    580  92%    9.12K    209        3      6688K task_struct
  6720   6328  94%    0.65K    280       24      4480K proc_inode_cache
 36006  36006 100%    0.12K   1059       34      4236K kernfs_node_cache
266752 266752 100%    0.02K   1042      256      4168K kmalloc-16
134640 133960  99%    0.02K    792      170      3168K fsnotify_mark_connector
  1568   1461  93%    2.00K     98       16      3136K mm_struct
  1245   1165  93%    2.06K     83       15      2656K sighand_cache

Conclusões:

• O alocador slab do kernel está usando cerca de 2,3 GB de RAM
• Quase tudo isso é irrecuperável
• Cerca de 1,3 GB dele é ocupado pelo kmem_cache cache
• Outro 0,5 GB pertence aos caches kmalloc de vários tamanhos

Aqui é onde eu bati na parede. Eu não descobri como olhar para dentro desses caches e ver por que eles ficaram tão grandes (ou porque a memória deles é irrecuperável). Como posso ir mais longe nas minhas investigações?

    

Answer 1

perf kmem record --slab irá capturar dados de criação de perfil e perf kmem stat --slab --caller será subtotal pelo símbolo do kernel.

Isso não explica por que sua carga de trabalho faz isso no entanto. Adicione em perf record e observe o relatório para ver o que está chamando no kernel.

O kprobes pode rastrear pilhas de kernel específicas, levando a um tipo de alocação. Eu não estou super familiarizado com isso, mas tente ler os exemplos que acompanham scripts eBPF como o slabratetop .

Também varie um pouco as coisas no seu host. Adicione RAM para ter certeza de que você não está sob o tamanho. Experimente versões mais recentes do kernel ou uma distribuição diferente.