ECS執行個體宕機並報錯“Out of memory and no killable processes”如何處理？ - Elastic Compute Service

如果您的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執行個體建立快照備份資料，避免因誤操作造成的資料丟失。建立快照的具體操作，請參見建立快照。

檢查系統核心是否存在記憶體流失。
具體操作，請參見如何排查slab_unreclaimable記憶體佔用高的原因？。
檢查進程的oom_score_adj設定是否合理。
1. 執行以下命令，擷取進程的PID。您可以使用命令如 ps、top 或 pgrep 來尋找進程的 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殺死，從而導致系統可用記憶體不足。