Todos os produtos
Search

Este produto

    Alibaba Cloud Linux:Troubleshoot the OOM Killer

    Central de documentação

    Alibaba Cloud Linux:Troubleshoot the OOM Killer

    Última atualização: Jun 29, 2026

    Quando a recuperação de memória não resolve a escassez de memória em um sistema Linux, o kernel aciona o OOM Killer para encerrar processos à força. Este tópico aborda as causas comuns de eventos do OOM Killer no Alibaba Cloud Linux e suas respectivas soluções.

    Descrição do problema

    O log a seguir mostra o processo test acionando o OOM Killer:

    565 [Sat Sep 11 12:24:42 2021] test invoked oom-killer: gfp_mask=0x62****(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
566 [Sat Sep 11 12:24:42 2021] test cpuset=/ mems_allowed=0
567 [Sat Sep 11 12:24:42 2021] CPU: 1 PID: 29748 Comm: test Kdump: loaded Not tainted 4.19.91-24.1.al7.x86_64 #1
568 [Sat Sep 11 12:24:42 2021] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS e62**** 04/01/2014

    Causas possíveis

    Eventos do OOM Killer resultam de memória global ou de cgroup insuficiente. A tabela a seguir lista cenários comuns:

    Causa

    Exemplo de cenário

    Memória de cgroup insuficiente

    Neste log, o OOM Killer é acionado para o cgroup /mm_test, que contém o processo test:

    [Wed Sep  8 18:01:32 2021] test invoked oom-killer: gfp_mask=0x240****(GFP_KERNEL), nodemask=0, order=0, oom_score_adj=0
[Wed Sep  8 18:01:32 2021] Task in /mm_test killed as a result of limit of /mm_test
[Wed Sep  8 18:01:32 2021] memory: usage 204800kB, limit 204800kB, failcnt 26

    Causa: O cgroup /mm_test atingiu o limite de memória de 200 MB.

    Memória insuficiente no cgroup pai

    Neste caso, o processo test no cgroup /mm_test/2 é encerrado porque o cgroup pai /mm_test atingiu o limite de memória:

    [Fri Sep 10 16:15:14 2021] test invoked oom-killer: gfp_mask=0x240****(GFP_KERNEL), nodemask=0, order=0, oom_score_adj=0
[Fri Sep 10 16:15:14 2021] Task in /mm_test/2 killed as a result of limit of /mm_test
[Fri Sep 10 16:15:14 2021] memory: usage 204800kB, limit 204800kB, failcnt 1607

    Causa: O cgroup pai /mm_test atingiu o limite de 200 MB e acionou o OOM Killer no cgroup filho /mm_test/2, mesmo sem este ter atingido o próprio limite.

    Memória global insuficiente

    Neste log, limit of host indica memória global insuficiente. A memória livre (free) no nó 0 caiu abaixo da marca d'água baixa (low):

    [Sat Sep 11 12:24:42 2021] test invoked oom-killer: gfp_mask=0x62****(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0,
[Sat Sep 11 12:24:42 2021] Task in /user.slice killed as a result of limit of host
[Sat Sep 11 12:24:42 2021] Node 0 DMA32 free:155160kB min:152412kB low:190512kB high:228612kB
[Sat Sep 11 12:24:42 2021] Node 0 Normal free:46592kB min:46712kB low:58388kB high:70064kB

    Causa: A memória livre caiu abaixo do limiar mínimo e a recuperação de memória não conseguiu liberar páginas suficientes.

    Memória insuficiente em um nó de memória

    Principais indicadores neste log:

    • limit of host indica que um nó de memória esgotou a memória disponível.

    • A instância possui dois nós de memória: Nó 0 e Nó 1.

    • A memória livre (free) no Nó 1 está abaixo da marca d'água baixa (low).

    • A memória livre total permanece alta (free:4111496).

    [Sat Sep 11 09:46:24 2021] main invoked oom-killer: gfp_mask=0x62****(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, oom_score_adj=0
[Sat Sep 11 09:46:24 2021] main cpuset=mm_cpuset mems_allowed=1
[Sat Sep 11 09:46:24 2021] Task in / killed as a result of limit of host
[Sat Sep 11 09:46:24 2021] Mem-Info:
[Sat Sep 11 09:46:24 2021] active_anon:172 inactive_anon:4518735 isolated_anon:
    free:4111496 free_pcp:1 free_cma:0
[Sat Sep 11 09:46:24 2021] Node 1 Normal free:43636kB min:45148kB low:441424kB high:837700kB
[Sat Sep 11 09:46:24 2021] Node 1 Normal: 856*4kB (UME) 375*8kB (UME) 183*16kB (UME) 184*32kB (UME) 87*64kB (ME) 45*128kB (UME) 16*256kB (UME) 5*512kB (UE) 14*1024kB (UME) 0     *2048kB 0*4096kB = 47560kB
[Sat Sep 11 09:46:24 2021] Node 0 hugepages_total=360 hugepages_free=360 hugepages_surp=0 hugepages_size=1048576kB
[Sat Sep 11 09:46:24 2021] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[Sat Sep 11 09:46:24 2021] Node 1 hugepages_total=360 hugepages_free=360 hugepages_surp=0 hugepages_size=1048576kB
[Sat Sep 11 09:46:25 2021] Node 1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB

    Causa: Em arquiteturas NUMA, cpuset.mems pode restringir um cgroup a nós de memória específicos. Se esses nós se esgotarem, o OOM Killer será acionado mesmo que outros nós tenham memória livre. Execute cat /proc/buddyinfo para visualizar o status dos nós.

    Memória insuficiente no buddy system devido à fragmentação

    Principais indicadores neste log:

    • O OOM Killer foi acionado durante uma alocação de order=3 (bloco contíguo de 32 KB).

    • A memória livre (free) no nó 0 está acima da marca d'água baixa (low).

    • O buddy system não tem blocos do tamanho necessário (0*32kB (M)).

    [Sat Sep 11 15:22:46 2021] insmod invoked oom-killer: gfp_mask=0x60****(GFP_KERNEL), nodemask=(null), order=3, oom_score_adj=0
[Sat Sep 11 15:22:46 2021] insmod cpuset=/ mems_allowed=0
[Sat Sep 11 15:22:46 2021] Task in /user.slice killed as a result of limit of host
[Sat Sep 11 15:22:46 2021] Node 0 Normal free:23500kB min:15892kB low:19864kB high:23836kB active_anon:308kB inactive_anon:194492kB active_file:384kB inactive_file:420kB unevi    ctable:0kB writepending:464kB present:917504kB managed:852784kB mlocked:0kB kernel_stack:2928kB pagetables:9188kB bounce:0kB
[Sat Sep 11 15:22:46 2021] Node 0 Normal: 1325*4kB (UME) 966*8kB (UME) 675*16kB (UME) 0*32kB (M) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =

    Causa: A fragmentação de memória impede o buddy system de alocar um bloco contíguo do tamanho necessário, mesmo com memória livre total suficiente.

    Nota

    O buddy system é um alocador de memória do kernel Linux que gerencia blocos contíguos de tamanhos variados para reduzir a fragmentação.

    Soluções

    Resolva o problema conforme a causa identificada.

    Memória insuficiente em um cgroup ou cgroup pai

    Encerre processos desnecessários para liberar memória. Caso a carga de trabalho exija mais memória, faça upgrade da instância.

    1. Faça upgrade da instância.

      Consulte Visão geral da alteração de configuração.

    2. Após o upgrade, ajuste manualmente o limite de memória do cgroup.

      sudo bash -c 'echo <value> > /sys/fs/cgroup/memory/<cgroup_name>/memory.limit_in_bytes'

      Substitua <value> pelo novo limite de memória do cgroup em bytes e <cgroup_name> pelo nome do cgroup.

    Memória global insuficiente

    Investigue as seguintes áreas:

    • Verifique o uso de memória slab_unreclaimable.

      cat /proc/meminfo | grep "SUnreclaim"

      slab_unreclaimable refere-se à memória que o sistema não consegue recuperar. Se esse valor exceder 10% da memória total, provavelmente há um vazamento de memória slab. Para solucionar, siga as instruções em O que devo fazer se uma instância tiver uma alta porcentagem de memória slab_unreclaimable?. Se o problema persistir, envie um ticket.

    • Verifique o uso de memória do systemd.

      cat /proc/1/status | grep "RssAnon"

      O kernel ignora o processo 1 (systemd) durante encerramentos por OOM; portanto, o uso de memória do systemd não deve exceder 200 MB. Se o consumo estiver anormalmente alto, atualize o systemd para uma versão mais recente.

    • Analise o desempenho das Transparent Huge Pages (THP).

      As THPs podem causar inchaço de memória e levar a eventos de OOM. Para mitigar esse efeito, ajuste as configurações de THP conforme descrito em Como usar THP para ajustar o desempenho no Alibaba Cloud Linux?.

    Memória insuficiente em um nó de memória

    Configure cpuset.mems para permitir que o cgroup use memória de nós adicionais.

    1. Identifique os nós de memória do sistema.

      cat /proc/buddyinfo

    2. Configure o parâmetro cpuset.mems.

      sudo bash -c 'echo <value> > /sys/fs/cgroup/cpuset/<cgroup_name>/cpuset.mems'

      Substitua <value> pelos números dos nós de memória correspondentes e <cgroup_name> pelo nome do cgroup.

      Por exemplo, se o sistema tiver três nós (Nó 0, Nó 1 e Nó 2) e você desejar que o cgroup utilize memória do Nó 0 e do Nó 2, defina <value> como 0,2.

    Memória insuficiente no buddy system devido à fragmentação

    Execute a compactação de memória fora dos horários de pico:

    sudo bash -c 'echo 1 > /proc/sys/vm/compact_memory'