日本熟妇hd丰满老熟妇,中文字幕一区二区三区在线不卡 ,亚洲成片在线观看,免费女同在线一区二区

AI 助理
備案控制臺(tái)
文檔
輸入文檔關(guān)鍵字查找
首頁 Alibaba Cloud Linux 服務(wù)支持 Alibaba Cloud Linux常見問題 出現(xiàn)OOM Killer的原因及解決方案

出現(xiàn)OOM Killer的原因及解決方案

更新時(shí)間：
產(chǎn)品詳情
我的收藏

Linux操作系統(tǒng)內(nèi)存不足時(shí)，會(huì)先觸發(fā)內(nèi)存回收機(jī)制釋放內(nèi)存，并將這部分被釋放的內(nèi)存分配給其他進(jìn)程。如果內(nèi)存回收機(jī)制不能處理系統(tǒng)內(nèi)存不足的情況，則系統(tǒng)會(huì)觸發(fā)OOM Killer（Out of Memory Killer）強(qiáng)制釋放進(jìn)程占用的內(nèi)存，達(dá)到給系統(tǒng)解壓的目的。本文介紹Alibaba Cloud Linux操作系統(tǒng)出現(xiàn)OOM Killer的可能原因及解決方案。

問題現(xiàn)象

Alibaba Cloud Linux操作系統(tǒng)出現(xiàn)OOM Killer的部分日志信息示例如下，表示test進(jìn)程引發(fā)了OOM Killer。

565 [六 9月 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 [六 9月 11 12:24:42 2021] test cpuset=/ mems_allowed=0
567 [六 9月 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 [六 9月 11 12:24:42 2021] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS e62**** 04/01/2014

可能原因

系統(tǒng)出現(xiàn)OOM Killer表示內(nèi)存不足，內(nèi)存不足可以分為實(shí)例全局內(nèi)存不足和實(shí)例內(nèi)cgroup的內(nèi)存不足。目前常見的出現(xiàn)OOM Killer的場(chǎng)景及原因說明如下：

原因類型

場(chǎng)景示例

cgroup內(nèi)存不足

如下日志記錄的出現(xiàn)OOM Killer場(chǎng)景示例中，test進(jìn)程所在的cgroup /mm_test發(fā)生了OOM Killer。

[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

原因：cgroup /mm_test的內(nèi)存使用率達(dá)到上限（200 MB），因此觸發(fā)了OOM Killer。

父cgroup內(nèi)存不足

如下日志記錄的出現(xiàn)OOM Killer場(chǎng)景示例中，test進(jìn)程屬于cgroup /mm_test/2，而發(fā)生OOM Killer的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/2的內(nèi)存使用率沒有達(dá)到上限，但父cgroup /mm_test的內(nèi)存使用率達(dá)到上限（200 MB），因此觸發(fā)了OOM Killer。

系統(tǒng)全局內(nèi)存不足

如下日志記錄的出現(xiàn)OOM Killer場(chǎng)景示例中，limit of host表示實(shí)例的全局內(nèi)存出現(xiàn)了不足。在日志記錄的數(shù)據(jù)中，內(nèi)存節(jié)點(diǎn)Node 0的空閑內(nèi)存（free）已經(jīng)低于了內(nèi)存最低水位線（low）。

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

原因：由于實(shí)例的空閑內(nèi)存低于內(nèi)存最低水位線，無法通過內(nèi)存回收機(jī)制解決內(nèi)存不足的問題，因此觸發(fā)了OOM Killer。

內(nèi)存節(jié)點(diǎn)（Node）的內(nèi)存不足

如下日志記錄的出現(xiàn)OOM Killer場(chǎng)景示例中，部分日志記錄說明：

  • limit of host表示內(nèi)存節(jié)點(diǎn)的內(nèi)存出現(xiàn)了不足。

  • 實(shí)例存在Node 0和Node 1兩個(gè)內(nèi)存節(jié)點(diǎn)。

  • 內(nèi)存節(jié)點(diǎn)Node 1的空閑內(nèi)存（free）低于內(nèi)存最低水位線（low）。

  • 實(shí)例的空閑內(nèi)存還有大量剩余（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存儲(chǔ)模式下，操作系統(tǒng)可能存在多個(gè)內(nèi)存節(jié)點(diǎn)（可運(yùn)行cat /proc/buddyinfo命令查看相關(guān)資源信息）。如果通過cpuset.mems參數(shù)指定cgroup只能使用特定內(nèi)存節(jié)點(diǎn)的內(nèi)存，則可能導(dǎo)致實(shí)例在具備充足的空閑內(nèi)存的情況下，仍出現(xiàn)OOM Killer的情況。

內(nèi)存碎片化時(shí)伙伴系統(tǒng)內(nèi)存不足

如下日志記錄的出現(xiàn)OOM Killer場(chǎng)景示例中，部分日志記錄分析說明：

  • 操作系統(tǒng)在內(nèi)存分配的order=3階段出現(xiàn)了OOM Killer。

  • 內(nèi)存節(jié)點(diǎn)Node 0的空閑內(nèi)存（free）仍高于內(nèi)存最低水位線（low）。

  • 內(nèi)存節(jié)點(diǎn)Node 0對(duì)應(yīng)的伙伴系統(tǒng)內(nèi)存為0（0*32kB (M)）。

[六 9月 11 15:22:46 2021] insmod invoked oom-killer: gfp_mask=0x60****(GFP_KERNEL), nodemask=(null), order=3, oom_score_adj=0
[六 9月 11 15:22:46 2021] insmod cpuset=/ mems_allowed=0
[六 9月 11 15:22:46 2021] Task in /user.slice killed as a result of limit of host
[六 9月 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
[六 9月 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 =

原因：操作系統(tǒng)的內(nèi)存在進(jìn)行內(nèi)存分配的過程中，如果伙伴系統(tǒng)的內(nèi)存不足，則系統(tǒng)會(huì)通過OOM Killer釋放內(nèi)存，并將內(nèi)存提供至伙伴系統(tǒng)。

說明

在Linux操作系統(tǒng)中，伙伴系統(tǒng)（Buddy System）是內(nèi)核內(nèi)存管理的一種機(jī)制，它能夠減輕內(nèi)存碎片問題，并且高效地分配和釋放不同大小的內(nèi)存塊。

解決方案

請(qǐng)您結(jié)合實(shí)際出現(xiàn)的OOM Killer場(chǎng)景，按照以下步驟排查并解決問題：

子cgroup或父cgroup內(nèi)存不足

建議您自行評(píng)估實(shí)例內(nèi)當(dāng)前占用內(nèi)存的進(jìn)程情況，及時(shí)清理不需要的進(jìn)程，以釋放內(nèi)存。如果您的業(yè)務(wù)所需的內(nèi)存較大，當(dāng)前實(shí)例規(guī)格不滿足您對(duì)內(nèi)存的需求，可以升配實(shí)例以提升實(shí)例的內(nèi)存容量。

  1. 升配實(shí)例。

    更多信息，請(qǐng)參見升降配方式概述。

  2. 根據(jù)內(nèi)存實(shí)際的提升情況，手動(dòng)調(diào)整cgroup的內(nèi)存上限。

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

    其中，<value>為您為cgroup設(shè)置的內(nèi)存上限、<cgroup_name>為您實(shí)際的cgroup名稱，請(qǐng)根據(jù)實(shí)際情況替換。

系統(tǒng)全局內(nèi)存不足

如果出現(xiàn)系統(tǒng)全局內(nèi)存不足，請(qǐng)您重點(diǎn)排查以下幾項(xiàng)：

  • 查看slab_unreclaimable內(nèi)存使用情況。

    cat /proc/meminfo | grep "SUnreclaim"

    slab_unreclaimable內(nèi)存為系統(tǒng)不可回收的內(nèi)存，當(dāng)占用總內(nèi)存的10%以上時(shí)，表示系統(tǒng)可能存在slab內(nèi)存泄露。如果存在內(nèi)存泄露問題，您可以手動(dòng)排查并解決，具體操作，請(qǐng)參見如何排查slab_unreclaimable內(nèi)存占用高的原因？。如果問題始終未解決，可以提交工單尋求技術(shù)支持。

  • 查看systemd內(nèi)存使用情況。

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

    內(nèi)核發(fā)生OOM Killer時(shí)，會(huì)跳過系統(tǒng)的1號(hào)進(jìn)程。此時(shí)您查看systemd內(nèi)存使用情況時(shí)，一般不會(huì)超過200 MB。如果出現(xiàn)異常，您可以嘗試自行更新systemd工具的版本。

  • 查看透明大頁THP的性能。

    開啟THP會(huì)出現(xiàn)內(nèi)存膨脹（memory bloating），從而導(dǎo)致OOM Killer，您可以對(duì)THP進(jìn)行調(diào)優(yōu)。具體操作，請(qǐng)參見Alibaba Cloud Linux系統(tǒng)中與透明大頁THP相關(guān)的性能調(diào)優(yōu)方法。

內(nèi)存節(jié)點(diǎn)（Node）的內(nèi)存不足

內(nèi)存節(jié)點(diǎn)（Node）的內(nèi)存不足導(dǎo)致的OOM Killer，您需要重新配置cpuset.mems接口的值，使cgroup能夠合理使用內(nèi)存節(jié)點(diǎn)的內(nèi)存。

  1. 運(yùn)行以下命令，確定系統(tǒng)中內(nèi)存節(jié)點(diǎn)（Node）的數(shù)量信息。

    cat /proc/buddyinfo

  2. 配置cpuset.mems接口。

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

    其中，<value>為對(duì)應(yīng)的內(nèi)存節(jié)點(diǎn)號(hào)、<cgroup_name>為您實(shí)際的cgroup名稱，請(qǐng)根據(jù)實(shí)際情況替換。

    例如，系統(tǒng)中存在三個(gè)Node，分別為Node 0、Node 1、Node 2。您需要讓cgroup使用Node 0和Node 2兩個(gè)節(jié)點(diǎn)的內(nèi)存。則<value>取值為0,2。

內(nèi)存碎片化時(shí)伙伴系統(tǒng)內(nèi)存不足

內(nèi)存碎片化時(shí)導(dǎo)致的OOM Killer，建議您定期在業(yè)務(wù)空閑時(shí)間段，進(jìn)行內(nèi)存整理。開啟內(nèi)存整理功能的命令為：

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