すべてのプロダクト
Search

このプロダクト

    Alibaba Cloud Linux:OOM Killer のトラブルシューティング

    ドキュメントセンター

    Alibaba Cloud Linux:OOM Killer のトラブルシューティング

    最終更新日:May 28, 2026

    Linux システムでメモリ回収によって低メモリ状態を解決できない場合、カーネルは OOM Killer を呼び出してプロセスを強制的に終了させます。このトピックでは、Alibaba Cloud Linux での OOM Killer イベントの一般的な原因とその解決方法について説明します。

    現象

    次のログは、test プロセスが 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

    考えられる原因

    OOM Killer イベントは、グローバルメモリの不足または cgroup のメモリ不足が原因で発生します。次の表に、一般的なシナリオを示します：

    原因

    シナリオ例

    cgroup のメモリ不足

    このログでは、OOM Killer は test プロセスを含む cgroup /mm_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

    原因: /mm_test cgroup が 200 MB のメモリ制限に達しました。

    親 cgroup のメモリ不足

    ここでは、cgroup /mm_test/2 内の test プロセスが、親 cgroup である /mm_test がメモリ制限に達したために強制終了されています：

    [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

    原因: 親 cgroup /mm_test が 200 MB の上限に達したため、子 cgroup /mm_test/2 は自身の上限に達していなかったにもかかわらず、OOM Killer がトリガーされました。

    グローバルメモリの不足

    このログでは、limit of host はグローバルメモリの不足を示しています。ノード 0 の空きメモリ (free) が 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

    原因：空きメモリが最小しきい値を下回り、メモリ回収で十分なページを解放できませんでした。

    メモリノードのメモリ不足

    このログの主要な指標：

    • limit of host はメモリノードのメモリが枯渇したことを示します。

    • インスタンスには、ノード 0 とノード 1 の 2 つのメモリノードがあります。

    • ノード 1 の空きメモリ (free) は、低ウォーターマーク (low) を下回っています。

    • 全体の空きメモリは高いままです (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

    原因: NUMA アーキテクチャでは、cpuset.mems は cgroup を特定のメモリノードに制限できます。これらのノードが枯渇すると、他のノードに空きメモリがある場合でも OOM Killer が起動します。ノードのステータスを確認するには、cat /proc/buddyinfo を実行します。

    メモリの断片化によるバディシステムのメモリ不足

    このログの主要な指標：

    • OOM Killer は order=3 の割り当て（32 KB の連続ブロック）時にトリガーされました。

    • ノード 0 の空きメモリ (free) は、低ウォーターマーク (low) を上回っています。

    • バディシステムには、要求されたサイズのブロックがありません (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 =

    原因：メモリの断片化により、全体の空きメモリは十分であっても、バディシステムは要求されたサイズの連続ブロックを割り当てることができません。

    説明

    バディシステムは、断片化を軽減するためにさまざまなサイズの連続ブロックを管理する Linux カーネルのメモリアロケーターです。

    ソリューション

    原因に基づいて問題を解決します。

    cgroup または親 cgroup のメモリ不足

    不要なプロセスを終了してメモリを解放してください。ワークロードがより多くのメモリを必要とする場合は、インスタンスをアップグレードしてください。

    1. インスタンスをアップグレードしてください。

      詳細については、「設定変更の概要」をご参照ください。

    2. アップグレード後、cgroup のメモリ制限を手動で調整してください。

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

      <value> をバイト単位の cgroup の新しいメモリ制限に、<cgroup_name> を cgroup の名前に置き換えます。

    グローバルメモリの不足

    次の領域を調査してください：

    • slab_unreclaimable メモリの使用状況を確認してください。

      cat /proc/meminfo | grep "SUnreclaim"

      slab_unreclaimable は、システムが回収できないメモリです。合計メモリの 10% を超える場合、slab メモリリークの可能性があります。トラブルシューティングについては、「インスタンスの slab_unreclaimable メモリの割合が高い場合の対処方法」をご参照ください。問題が解決しない場合は、チケットを送信してください。

    • systemd のメモリ使用状況を確認してください。

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

      カーネルは OOM の強制終了中にプロセス 1 (systemd) をスキップするため、systemd のメモリ使用量は 200 MB を超えないようにする必要があります。使用量が異常に多い場合は、systemd を新しいバージョンに更新してください。

    • 透過的ヒュージページ (THP) のパフォーマンスを確認してください。

      THP はメモリの肥大化を引き起こし、OOM イベントにつながる可能性があります。これを軽減するには、「Alibaba Cloud Linux で THP を使用してパフォーマンスをチューニングする方法」の説明に従って THP 設定をチューニングしてください。

    メモリノードのメモリ不足

    cgroup が追加のノードからメモリを使用できるように、cpuset.mems を再設定してください。

    1. システム内のメモリノードを特定してください。

      cat /proc/buddyinfo

    2. cpuset.mems パラメーターを設定してください。

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

      <value>を対応するメモリノード番号に、<cgroup_name>を cgroup の名前に置き換えます。

      たとえば、システムに 3 つのノード (ノード 0、ノード 1、およびノード 2) があり、cgroup でノード 0 とノード 2 のメモリを使用する場合、<value> を 0,2 に設定します。

    メモリの断片化によるバディシステムのメモリ不足

    オフピーク時にメモリコンパクションを実行してください：

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