全部產品
Search
文件中心

:ECS執行個體宕機並報錯“Out of memory and no killable processes”如何處理?

更新時間:Jul 04, 2024

如果您的ECS執行個體出現宕機,並且報錯日誌中存在Out of memory and no killable processes資訊,則可以參考本文提供的方案解決問題。

問題現象

ECS執行個體在運行過程中出現宕機,並且有類似於如下所示的調用棧:

[28663.625353] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[28663.625363] [ 1799]     0  1799    26512      245      56       3        0         -1000 sshd
[28663.625367] [29219]     0 29219    10832      126      26       3        0         -1000 systemd-udevd
[28663.625375] Kernel panic - not syncing: Out of memory and no killable processes...
[28663.634374] CPU: 1 PID: 3578 Comm: kworker/u176:4 Tainted: G           OE   3.10.0-1062.9.1.el7.x86_64 #1
[28663.676873] Call Trace:
[28663.679312]  [<ffffffff8139f342>] dump_stack+0x63/0x81
[28663.684421]  [<ffffffff811b2245>] panic+0xf8/0x244
[28663.689184]  [<ffffffff811b98db>] out_of_memory+0x2eb/0x550
[28663.694726]  [<ffffffff811be254>] __alloc_pages_may_oom+0x114/0x1c0
[28663.700959]  [<ffffffff811bedb3>] __alloc_pages_slowpath+0x7d3/0xa40
[28663.707279]  [<ffffffff811bf229>] __alloc_pages_nodemask+0x209/0x260
[28663.713599]  [<ffffffff81216535>] alloc_pages_current+0x95/0x140
[28663.719573]  [<ffffffff811ba5ee>] __get_free_pages+0xe/0x40
[28663.725113]  [<ffffffff81075dae>] pgd_alloc+0x1e/0x160
[28663.730225]  [<ffffffff810875e4>] mm_init+0x184/0x240
[28663.735249]  [<ffffffff81088102>] mm_alloc+0x52/0x60
[28663.740186]  [<ffffffff81257640>] do_execveat_common.isra.37+0x250/0x780
[28663.759839]  [<ffffffff81257b9c>] do_execve+0x2c/0x30
[28663.764864]  [<ffffffff810a231b>] call_usermodehelper_exec_async+0xfb/0x150
[28663.777246]  [<ffffffff81741dd9>] ret_from_fork+0x39/0x50

問題原因

作業系統核心分配記憶體失敗後,嘗試通過kill進程來釋放記憶體,但系統沒有可被kill的進程,進而觸發了系統的主動宕機。出現該問題的可能原因有:

  • 系統核心存在記憶體流失,從而導致系統可用記憶體不足。

  • oom_score_adj-1000的進程佔用過多記憶體,該類進程無法被殺死從而導致系統可用記憶體不足。

    說明

    oom_score_adj 的值是一個整數,表示進程在Out of Memory(OOM)條件下被核心優先順序選擇的可能性。較低的值表示核心不可能選擇該進程進行OOM殺死,而較高的值表示該進程越有可能被選擇。

解決方案

重要

在操作前,建議您為ECS執行個體建立快照備份資料,避免因誤操作造成的資料丟失。建立快照的具體操作,請參見建立快照

  1. 檢查系統核心是否存在記憶體流失。

    具體操作,請參見如何排查slab_unreclaimable記憶體佔用高的原因?

  2. 檢查進程的oom_score_adj設定是否合理。

    1. 執行以下命令,擷取進程的PID。您可以使用命令如 pstoppgrep 來尋找進程的 PID。

      ps aux | grep <進程名稱>

      您需要將 <進程名稱> 替換為您要尋找的進程的名稱。

    2. 執行以下命令,檢查 oom_score_adj 設定。

      cat /proc/<PID>/oom_score_adj

      您需要將 <PID> 替換為已擷取的進程實際PID。

      根據您的環境和需求,可以根據oom_score_adj的值來評估進程的OOM行為是否合理。如果oom_score_adj的值為-1000,則表示該進程具有較低的優先順序,更不可能被核心選擇進行OOM殺死,從而導致系統可用記憶體不足。