Um assassino que não posso explicar

Question

Eu não sou capaz de entender por que o kernel enviaria este oom killer quando eu vejo memória suficiente disponível:

Eu digo que memória suficiente está disponível depois de olhar para

Normal

DMA

Linhas livres normais

Este é um dispositivo baseado em flash nand com 256 MB de RAM

Kernel: 2.6.31

 myshellscript invoked oom-killer: gfp_mask=0xd0, order=2, oomkilladj=0 
 Backtrace: 
 [<c0106494>] (dump_backtrace+0x0/0x110) from [<c03641a0>] (dump_stack+0x18/0x1c) 
 r6:000000d0 r5:c9040c60 r4:00000002 r3:c0448690 
 [<c0364188>] (dump_stack+0x0/0x1c) from [<c015a314>] (oom_kill_process.clone.11+0x60/0x1b4) 
 [<c015a2b4>] (oom_kill_process.clone.11+0x0/0x1b4) from [<c015a738>] (__out_of_memory+0x154/0x178) 
 r8:c21e86e0 r7:001fb000 r6:00000002 r5:000000d0 r4:c9b6e000 
 [<c015a5e4>] (__out_of_memory+0x0/0x178) from [<c015a980>] (out_of_memory+0x68/0xa0) 
 [<c015a918>] (out_of_memory+0x0/0xa0) from [<c015d230>] (__alloc_pages_nodemask+0x42c/0x520) 
 r5:00000002 r4:000000d0 
 [<c015ce04>] (__alloc_pages_nodemask+0x0/0x520) from [<c015d388>] (__get_free_pages+0x18/0x44) 
 [<c015d370>] (__get_free_pages+0x0/0x44) from [<c0109418>] (get_pgd_slow+0x1c/0xe0) 
 [<c01093fc>] (get_pgd_slow+0x0/0xe0) from [<c0129ab0>] (mm_init.clone.43+0xb0/0xf0) 
 r7:c90858c0 r6:00000000 r5:c90858c0 r4:ce1a6680 
 [<c0129a00>] (mm_init.clone.43+0x0/0xf0) from [<c0129c40>] (mm_alloc+0x34/0x44) 
 r6:0009230c r5:c90858c0 r4:ce1a6680 r3:00000000 
 [<c0129c0c>] (mm_alloc+0x0/0x44) from [<c0180f70>] (bprm_mm_init+0x14/0x148) 
 r4:c5154000 r3:cd472564 
 [<c0180f5c>] (bprm_mm_init+0x0/0x148) from [<c01812d0>] (do_execve+0xa8/0x254) 
 [<c0181228>] (do_execve+0x0/0x254) from [<c0106000>] (sys_execve+0x3c/0x5c) 
 [<c0105fc4>] (sys_execve+0x0/0x5c) from [<c0102e80>] (ret_fast_syscall+0x0/0x2c) 
 r7:0000000b r6:0009230c r5:0009237c r4:000922fc 
 Mem-info: 
 DMA per-cpu: 
 CPU 0: hi: 18, btch: 3 usd: 0 
 Normal per-cpu: 
 CPU 0: hi: 42, btch: 7 usd: 0 
 Active_anon:28162 active_file:16 inactive_anon:18037 
 inactive_file:13 unevictable:0 dirty:0 writeback:0 unstable:0 
 free:9998 slab:2447 mapped:164 pagetables:701 bounce:0 
 DMA free:17128kB min:1560kB low:1948kB high:2340kB active_anon:51068kB inactive_anon:10320kB active_file:24kB inactive_file:0kB unevictable:0kB present:97536kB pages_scanned:0 all_unreclaimable? no 
 lowmem_reserve[]: 0 158 158 
 Normal free:22864kB min:2600kB low:3248kB high:3900kB active_anon:61580kB inactive_anon:61828kB active_file:40kB inactive_file:52kB unevictable:0kB present:162560kB pages_scanned:0 all_unreclaimable? no 
 lowmem_reserve[]: 0 0 0 
 DMA: 2358*4kB 912*8kB 25*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 17128kB 
 Normal: 4266*4kB 657*8kB 32*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 22864kB 
 26591 total pagecache pages 
 0 pages in swap cache 
 Swap cache stats: add 0, delete 0, find 0/0 
 Free swap = 0kB 
 Total swap = 0kB 
 65536 pages of RAM 
 10471 free pages 
 3967 reserved pages 
 2447 slab pages 
 892 shared page count 
 389 shared pages
 620 mapped shared page count
 177 mapped shared pages
 0 pages swap cached
 2481 dma reserved pages
 19892 total user pages
 20512 RSS sum by tasks
 20512 RSS sum by page stats
 164 user cache pages
 26427 kernel cache pages

    

Answer 1

OK, então vamos passar por cada bit.

Memória ativa são regiões de memória que são lançadas no topo da pilha LRU (basicamente, são chamadas muito).

Memória inativa é algo que não está sendo muito usado e é uma troca de nome caso a memória precise ser trocada.

Grátis é uma memória genuinamente livre. Cerca de 40Mb. O que dá?

A pista está nas seguintes linhas:

 DMA: 2358*4kB 912*8kB 25*16kB 0*32kB 0*64kB 0*128kB 
      0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 
      0*16384kB = 17128kB 
 Normal: 4266*4kB 657*8kB 32*16kB 1*32kB 0*64kB 0*128kB 
      0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB
      0*16384kB = 22864kB 

Este material denota fragmentação de memória. Isso basicamente mostra quanta memória está contiguamente disponível. E aqui está o seu problema.

De memória normal livre, você não tem mais que 32kb de memória contígua disponível. Sua memória está terrivelmente fragmentada. Isso significa que, se qualquer aplicativo precisar alocar mais de 32k de espaço, não haverá memória - então o killer chega para chutar alguma coisa para dar memória para fazer isso.

Então, o que você pode fazer?

A pista para que é esta:

Free swap = 0kB 
Total swap = 0kB 

Oh querida! Nenhuma troca! Então, memória que está comprometida - só fica lá. Kernels mais novos atualmente 'desfragmentam' a memória para tornar a região da memória contígua, os mais antigos não fazem isso.

Você tinha 70Mb de memória que poderia foi trocada! Além disso, isso não ocorreria de uma só vez, mas gradualmente, não teria sido um sucesso para você. Mas sem troca, então sem sorte. Você também tem pouca memória para o pagecache, que também é ruim e lento para o seu sistema. Isso potencialmente poderia dar muito mais espaço contíguo livre, o que seria bom para você.

Meu conselho para você. Arranja 768Mb de swap. Honestamente, você realmente presta um desserviço ao seu kernel, não permitindo isso.

O swap é realmente importante para liberar memória não usada (um quarto dela no seu caso) e também teria evitado os problemas desagradáveis de fragmentação que você experimentou, já que a memória poderia ter sido trocada e liberada mais espaço contíguo. E mesmo se ele fosse trocado de volta, ele poderia ter sido colocado de volta em uma região de memória que lhe proporcionaria maiores intervalos contíguos.