Como fazer com que o assassino do Linux OOM não mate meu processo?

Como faço para que o killer do Linux OOM não mate meus processos quando a memória física está baixa, mas há bastante espaço de troca?

Desativei a eliminação do OOM e a confirmação excessiva com sysctl vm.overcommit_memory = 2.

A VM possui 3 GB de swap não fragmentado absolutamente livre e os processos que estão sendo eliminados pelo OOM têm um uso máximo de memória inferior a 200 MB.

Eu sei que a troca a longo prazo será horrível para o desempenho, mas preciso usar a troca agora para fazer testes funcionais no valgrind, onde os requisitos de memória são muito maiores.

Mar  7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0
Mar  7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0
Mar  7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar  7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar  7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18
Mar  7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2
Mar  7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc
Mar  7 02:43:11 myhost kernel: Call Trace:
Mar  7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50
Mar  7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd
Mar  7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f
Mar  7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406
Mar  7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0
Mar  7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0
Mar  7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a
Mar  7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71
Mar  7 02:43:11 myhost kernel: Mem-Info:
Mar  7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0
Mar  7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0
Mar  7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0
Mar  7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674
Mar  7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0
Mar  7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0
Mar  7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
 mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36
0 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972
Mar  7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag
ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t
mp:0kB pages_scanned:792 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0
Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
Mar  7 02:43:11 myhost kernel: 71 total pagecache pages
Mar  7 02:43:11 myhost kernel: 42 pages in swap cache
Mar  7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093
Mar  7 02:43:11 myhost kernel: Free swap  = 3118172kB
Mar  7 02:43:11 myhost kernel: Total swap = 3334140kB
Mar  7 02:43:11 myhost kernel: 262014 pages RAM
Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
Mar  7 02:43:11 myhost kernel: 8149 pages reserved
Mar  7 02:43:11 myhost kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Mar  7 02:43:11 myhost kernel: [ 2054]     0  2054     5101        1      15       4      283             0 upstart-udev-br
Mar  7 02:43:11 myhost kernel: [ 2063]     0  2063    12362        1      28       4      184         -1000 systemd-udevd
Mar  7 02:43:11 myhost kernel: [ 3342]   102  3342     9780        1      23       3       89             0 dbus-daemon
Mar  7 02:43:11 myhost kernel: [ 3423]     0  3423    10864        1      26       3       85             0 systemd-logind
Mar  7 02:43:11 myhost kernel: [ 3441]     0  3441    15344        0      34       3      184         -1000 sshd
Mar  7 02:43:11 myhost kernel: [ 3450]     0  3450     4786        0      14       3       43             0 atd
Mar  7 02:43:11 myhost kernel: [ 3451]     0  3451     5915        0      17       4       65             0 cron
Mar  7 02:43:11 myhost kernel: [ 3457]   101  3457    63962        0      28       3      202             0 rsyslogd
Mar  7 02:43:11 myhost kernel: [ 3516]     0  3516     3919        1      13       3      156             0 upstart-file-br
Mar  7 02:43:11 myhost kernel: [ 3518]     0  3518     4014        0      13       3      265             0 upstart-socket-
Mar  7 02:43:11 myhost kernel: [ 3557]     0  3557    66396        0      32       3     1802             0 fail2ban-server
Mar  7 02:43:11 myhost kernel: [ 3600]     0  3600     3956        1      13       3       39             0 getty
Mar  7 02:43:11 myhost kernel: [ 3601]     0  3601     3198        1      12       3       37             0 getty
Mar  7 02:43:11 myhost kernel: [ 3673]     0  3673    26411        1      55       3      252             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3740]  1000  3740    26411        1      52       3      253             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3741]  1000  3741     5561        0      16       3      431             0 bash
Mar  7 02:43:11 myhost kernel: [ 3820]   103  3820     7863        1      21       3      152             0 ntpd
Mar  7 02:43:11 myhost kernel: [ 3837]  1000  3837    31990        0      58       4    12664             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3841]  1000  3841    32006        0      59       4    12812             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3844]  1000  3844    31950        0      57       4    12035             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3849]  1000  3849    31902        0      56       4    11482             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3853]  1000  3853     1087        0       7       3       27             0 lsof
Mar  7 02:43:11 myhost kernel: [ 3854]     0  3854    26140        5      55       3      230             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3855]   104  3855    15699        0      33       3      202             0 sshd
Mar  7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-amd64-) score 11 or sacrifice child
Mar  7 02:43:11 myhost kernel: Killed process 3841 (memcheck-amd64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB

Este é / proc / meminfo

MemTotal:        1015460 kB
MemFree:          277508 kB
MemAvailable:     322032 kB
Buffers:            8336 kB
Cached:            42208 kB
SwapCached:        46088 kB
Active:            58844 kB
Inactive:         116100 kB
Active(anon):      34784 kB
Inactive(anon):    89620 kB
Active(file):      24060 kB
Inactive(file):    26480 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       3334140 kB
SwapFree:        3215756 kB
Dirty:                16 kB
Writeback:             0 kB
AnonPages:        121128 kB
Mapped:            15072 kB
Shmem:                 4 kB
Slab:              22668 kB
SReclaimable:       8028 kB
SUnreclaim:        14640 kB
KernelStack:        2016 kB
PageTables:         2532 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3841868 kB
Committed_AS:     380460 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
DirectMap4k:       14208 kB
DirectMap2M:     1034240 kB
DirectMap1G:           0 kB

Isso parece ser um problema na combinação de dois fatores:

• Usando uma máquina virtual.
• Um possível bug do kernel.

Esta é parcialmente uma das linhas que descreve por que isso acontece:

7 de março 02:43:11 Kernel myhost: oom-killer chamado memcheck-amd64: gfp_mask = 0x24002c2, order = 0, oom_score_adj = 0

A outra linha é esta:

Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

| A primeira linha é a máscara GFP atribuída à alocação. Ele basicamente descreve o que o kernel pode ou não fazer para satisfazer essa solicitação. A máscara indica um monte de sinalizadores padrão. O último bit, '2', no entanto, indica que a alocação de memória deve vir da HighMemzona.

Se você olhar atentamente para a saída do OOM, verá que nenhuma HighMem/Normalzona realmente existe.

Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem(geralmente chamado também Normalem x86_64) tende a mapear a memória para zonas fora dos intervalos padrão do 896MiB diretamente acessíveis ao kernel em sistemas de 32 bits. No x86_64, HighMem/Normalparece cobrir todas as páginas acima do tamanho 3GiB.

DMA32contém uma zona usada para a memória que seria acessível em dispositivos DMA de 32 bits, ou seja, é possível endereçá-los com ponteiros de 4 bytes. Eu acredito que DMAé para dispositivos DMA de 16 bits.

De um modo geral, em sistemas com pouca memória Normalnão existiria, dado que já DMA32abrange todos os endereços virtuais disponíveis.

A razão pela qual você mata o OOM é porque existe uma alocação de memória para uma HighMemzona com 0 páginas disponíveis. Dado que o manipulador de falta de memória não tem absolutamente nenhuma maneira de satisfazer, fazendo com que esta zona tenha páginas a serem trocadas, eliminando outros processos ou qualquer outro truque, o OOM-killer simplesmente o mata.

Acredito que isso seja causado pelo VM host do balão na inicialização. Nos sistemas KVM, existem dois valores que você pode definir.

• A memória atual.
• A memória disponível.

A maneira como isso funciona é que você pode adicionar memória a quente do servidor até a memória disponível. Seu sistema, no entanto, recebe a memória atual.

Quando uma VM KVM é inicializada, ela começa com a atribuição máxima de memória possível (a memória disponível). Gradualmente, durante a fase de inicialização do sistema, o KVM recupera essa memória usando seu balão, deixando você com a configuração de memória atual que possui.

É minha crença que foi o que aconteceu aqui. O Linode permite expandir a memória, oferecendo muito mais na inicialização do sistema.

Isso significa que existe uma Normal/HighMemzona no início da vida útil dos sistemas. Quando o hipervisor o empurra para longe, a zona normal desaparece corretamente do gerenciador de memória. Mas suspeito que o sinalizador que define se a zona está disponível para alocação não é limpo quando deveria. Isso leva o kernel a tentar alocar a partir de uma zona que não existe.

Em termos de resolução, você tem duas opções.

1. Traga isso para as listas de discussão do kernel para ver se realmente é um erro, comportamento esperado ou nada a ver com o que estou dizendo.

2. Solicite que o linode defina a 'memória disponível' no sistema como a mesma atribuição de 1 GiB da 'memória atual'. Portanto, o sistema nunca balança e nunca recebe uma zona Normal na inicialização, mantendo a bandeira limpa. Boa sorte para fazê-los fazer isso!

Você deve poder testar se esse é o caso, configurando sua própria VM na configuração KVM disponível para 6GiB, atual para 1GiB e executando seu teste usando o mesmo kernel para verificar se esse comportamento que você vê acima ocorre. Nesse caso, altere a configuração 'disponível' para igualar a corrente de 1 GiB e repita o teste.

Estou fazendo um monte de suposições educadas aqui e lendo as entrelinhas um pouco para chegar a essa resposta, mas o que estou dizendo parece se encaixar nos fatos já delineados.

Sugiro testar minha hipótese e informar a todos sobre o resultado.

Para responder à sua pergunta principal, use oom_score_adj(kernel> = 2.6.36) ou para kernels anteriores (> = 2.6.11) oom_adj, consulte man proc

/ proc / [pid] / oom_score_adj (desde o Linux 2.6.36) Esse arquivo pode ser usado para ajustar a heurística de badness usada para selecionar qual processo será eliminado em condições de falta de memória ...

/ proc / [pid] / oom_adj (desde Linux 2.6.11) Esse arquivo pode ser usado para ajustar a pontuação usada para selecionar qual processo deve ser eliminado em uma situação de falta de memória (OOM) ...

Há muito mais para ler, mas definir oom_score_adj como -1000 ou oom_adj como -17 alcançará o que você deseja.

O problema é que outra coisa será morta. Talvez seja melhor determinar por que o OOM está sendo invocado e lidar com isso.

Vários pensamentos (dos meus comentários acima) e links para interessantes notícias sobre sua situação:

• Eu recomendo que você verifique se 1) você pode endereçar mais de 3Gb com seu kernel e configuração atual (& cpu) [porque se 3Gb é um limite para o seu sistema e sistema operacional, você o está excedendo]. 2) que você permita a troca e o subsistema de troca esteja no local e funcionando. boa sorte (não vou explicar como, pois depende de suas configurações e detalhes. Os mecanismos de pesquisa ajudarão). E que você não está sobrecarregando uma tabela do kernel (nb de pids? Ou qualquer outra coisa (alguns podem ser configurados no tempo de compilação do kernel).

• Verifique se a coisa toda (hardware ou hardware simulado da VM, etc) tem 64 bits. (veja por exemplo: /ubuntu/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). O sistema operacional cpu e host e o subsistema vm e o sistema operacional vm devem estar todos habilitados para 64 bits, caso contrário, você não terá um vm real de 64 bits

• Algumas boas leituras:

  • Como diagnosticar as causas dos processos de matança de assassinos de horrores : neste site. Fornece um link legal, http://linux-mm.org/OOM_Killer , e outro usuário apresenta a ferramenta top, que pode ajudar a diagnosticar o que acontece
  • https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12 mostra a árvore de decisão para o OOM (de uma versão mais antiga, portanto, sim. Leia a fonte ^^)
  • https://lwn.net/Articles/317814/ : "Domesticar o assassino do OOM" mostra, entre outras coisas, como criar um grupo "inviável" e colocar seu processo nele
  • http://eloquence.marxmeier.com/sdb/html/linux_limits.html : mostra alguns limites comuns do kernel
  • http://win.tue.nl/~aeb/linux/lk/lk-9.html : é uma boa leitura (espaço desperdiçado com alguns métodos de alocação, etc.), embora esteja realmente datada (e, portanto, trata apenas 32- arquiteturas de bits ...)
  • http://bl0rg.krunch.be/oom-frag.html mostra alguns motivos pelos quais "o assassino do OOM pode ser chamado mesmo quando ainda há muita memória disponível"
  • /programming/17935873/malloc-fails-when-there-still-plenty-of-swap-left : fornece uma maneira de verificar como o sistema aloca memória
  • /server//a/724518/146493 : resposta excelente, oferecendo uma maneira detalhada de realmente saber o que aconteceu (mas ... direcionou uma pergunta de 32 bits, então sim. Ainda assim, uma leitura e resposta incríveis).

• e, finalmente: http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html mostra uma maneira de impedir que seu processo seja direcionado pelo assassino do oom! ( echo -17 > /proc/PROCESSPID/oom_adj) Pode estar sujeito a mudanças e pode ser uma coisa ruim (causar outros tipos de falhas, pois o sistema agora não pode simplesmente matar o principal infrator ...) Use com cuidado. @iain note que "oom_adj" é para kernels mais antigos e deve ser substituído por "oom_score_adj" nos mais novos. Obrigado, Iain)

além do oom_score_adjaumento mencionado para o processo em questão (o que provavelmente não ajudará muito - seria menos provável que esse processo fosse morto PRIMEIRO, mas como esse é apenas o sistema de processo com uso intenso de memória, provavelmente não se recuperará até que seja finalmente mortos), eis algumas idéias para ajustar:

• se você definir vm.overcommit_memory=2, também ajuste vm.overcommit_ratiopara talvez 90 (alternativamente, defina vm.overcommit_memory=0- consulte a documentação de confirmação do kernel )
• aumentar vm.min_free_kbytespara manter sempre alguma RAM física livre e, assim, reduzir as chances de o OOM precisar matar alguma coisa (mas não exagere, pois o OOM instantaneamente).
• aumente vm.swappinesspara 100 (para facilitar a troca do kernel )

Observe que se você tiver pouca memória para realizar a tarefa em mãos, mesmo que não tenha OOM, ela pode (ou não) ficar extremamente lenta - o trabalho de meia hora (no sistema com RAM suficiente) pode levar várias semanas ( quando a RAM é substituída pela troca) para concluir em casos extremos ou até travar a VM inteira. Esse é especialmente o caso se a troca for feita em discos rotacionais clássicos (em oposição aos SSDs) devido a enormes leituras / gravações aleatórias que são muito caras para eles.

Eu tentaria ativar o overcommit e ver se isso ajuda. Seu processo parece falhar dentro de uma forkchamada, o que requer tanta memória virtual quanto o processo inicial. overcommit_memory=2não torna seu processo imune ao OOM killer, apenas impede que seu processo o acione alocando demais. Outros processos podem produzir erros de alocação não relacionados (por exemplo, obter um bloco de memória contíguo), que ainda acionam o killer do OOM e descartam seu processo.

Como alternativa (e mais ao ponto), como vários comentários sugerem, compre mais RAM.

Breve história - tente uma versão diferente do kernel. Eu tenho um sistema que mostrou erros de OOM com os kernels 4.2.0-x e 4.4.0-x, mas não com os 3.19.0-x.

Longa história: (não muito longo!) Eu tenho um Compaq DC5000 ainda em serviço aqui - atualmente com 512 MB de RAM (e uma parte disso, como 32-128 MB, é fornecida ao vídeo de bordo). NFS, eu tenho um monitor conectado a ele, então ocasionalmente irei entrar nele (Ubuntu Classic, no Unity.)

Via Ubuntu HWE, eu estava executando o kernel 3.19.x por um bom tempo; acabaria trocando entre 200 e 300 MB de material, mas aparentemente não era usado, não haveria nenhuma atividade de troca por ter que trocá-lo mais tarde, tanto quanto eu poderia dizer.

Com o kernel 4.2.0-x e agora o kernel 4.4.0-x, posso iniciar uma gravação robusta do NFS, apenas 220 MB no swap (ou seja, 1,3 GB livre) e iniciará o OOM matando coisas. Não vou afirmar se é um bug do kernel ou um "problema de ajuste" (como uma reserva de 64 MB normalmente normal, mas muito alta em um sistema de ~ 400 MB ou mais?)

Sem desrespeito a quem está dizendo que está de alguma forma quebrando só porque ele espera usar swap; com todo o respeito, você está errado. Não será rápido, mas eu costumava usar 1 ou 2 GB na troca em alguns sistemas de 512 MB-1 GB. É claro que alguns tipos de software mlock são um monte de RAM, mas no meu caso (já que estou executando o mesmo software apenas em um kernel diferente), esse claramente não é o caso.