Linux oom情况（32位内核）

Question 1

然而，一种“强力”的方法是升级到 64 位操作系统（这是 32 位），因为区域的布局不同。

好的，所以我将尝试回答您为什么会遇到 OOM。这里面有很多因素在起作用。

请求的订单规模以及内核如何处理某些订单规模。
正在选定的区域。
此区域使用的水印。
区域中存在碎片。

如果你查看 OOM 本身，显然有大量可用内存，但还是调用了 OOM-killer？为什么？

请求的订单大小以及内核如何处理某些订单大小

内核按顺序分配内存。“顺序”是连续 RAM 的一个区域，必须满足该区域才能使请求工作。顺序使用算法按数量级排列（因此称为顺序）2^(ORDER + 12)。因此，顺序 0 是 4096，顺序 1 是 8192，顺序 2 是 16384，依此类推。

内核有一个硬编码值，表示什么是“高阶”（> PAGE_ALLOC_COSTLY_ORDER）。这是 4 阶及以上（64kb 或以上为高阶）。

高阶页面分配的满足方式与低阶不同。如果高阶分配无法获取内存，则在现代内核中会这样做。

尝试运行内存压缩例程来对内存进行碎片整理。
绝不调用OOM-killer来满足请求。

您的订单尺寸列在此处

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

顺序 3 是低顺序请求中最高的，并且（如您所见）调用 OOM-killer 来尝试满足它。

请注意，大多数用户空间分配不使用高阶请求。通常，内核需要连续的内存区域。例外情况可能是用户空间使用大页面 - 但这里不是这种情况。

在您的情况下，内核调用顺序 3 分配来将数据包排队到网络堆栈中 - 需要 32kb 分配才能执行此操作。

正在选定的区域。

内核将内存区域划分为区域。之所以进行这种划分，是因为在 x86 上，某些内存区域只能由某些硬件寻址。例如，较旧的硬件可能只能寻址“DMA”区域中的内存。当我们想要分配一些内存时，首先选择一个区域，然后仅有的在做出分配决策时会考虑该区域的可用内存。

虽然我对区域选择算法并不完全了解，但典型的用例从来不是从 DMA 分配，而是通常选择能够满足请求的最低可寻址区域。

在 OOM 期间会吐出大量区域信息，这些信息也可以从中收集/proc/zoneinfo。

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

您拥有的区域 DMA、Normal 和 HighMem 表明是 32 位平台，因为 HighMem 区域在 64 位上不存在。此外，在 64 位系统上，Normal 映射到 4GB 及以上，而在 32 位上，它映射到最多 896Mb（尽管，在您的情况下，内核报告仅管理比这更小的部分：- managed:587540kB。）

通过再次查看第一行，可以知道此分配来自何处，gfp_mask=0x42d0告诉我们进行了哪种类型的分配。最后一个字节 (0) 告诉我们这是来自正常区域的分配。gfp 含义位于包括/linux/gfp.h。

此区域使用的水印。

当内存不足时，回收内存的操作由水印指定。它们显示在这里：min:3044kB low:3804kB high:4564kB。如果可用内存达到“低”，则将进行交换，直到我们超过“高”阈值。如果内存达到“最小”，我们需要通过 OOM-killer 来杀死一些东西以释放内存。

区域中存在碎片。

为了查看特定顺序的内存请求是否可以满足，内核会计算每个顺序的空闲页面数和可用页面数。这在中可读/proc/buddyinfo。OOM-killer 报告还会吐出 buddyinfo，如下所示：

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

为了满足内存分配必须可用内存大小按请求的顺序或更高的分配顺序排列。低阶中有大量可用数据，而高阶中没有可用数据，这意味着您的内存已碎片化。如果您获得非常高阶的分配，则可能（即使有大量可用内存）由于没有可用的高阶页面而无法满足要求。内核可以通过移动大量低阶页面来整理内存碎片（这称为内存压缩），这样它们就不会在可寻址 RAM 空间中留下空隙。

是否调用了 OOM-killer？为什么？

因此，如果我们考虑到这些因素，我们可以得出以下结论；

尝试分配 32kB 连续空间。来自正常区域。
所选区域有足够的可用内存。
有 3、5 和 6 阶内存可用13*32kB (MR) 1*128kB (R) 1*256kB (R)

因此，如果有曾是释放内存，其他命令可以满足请求。发生了什么？

其实，从订单中分配内存不仅仅是检查该订单或更高订单的可用内存量。内核会有效地从总可用内存行中减去所有较低订单的内存，然后对剩余内存执行最小水印检查。

在您的情况下发生的情况是检查我们必须执行的该区域的可用内存。

115000 - (5360*4) - (3667*8) - (3964*16) = 800

此可用内存量将与min水位线（即 3044）进行对比。因此，从技术上讲，您没有剩余可用内存来执行请求的分配。这就是您调用 OOM-killer 的原因。

定影

有两个修复方法。升级到 64 位会改变您的区域分区，使“正常”区域从 4GB 增加到 36GB，因此您不会最终将内存分配“默认”到可能严重碎片化的区域。并不是因为您拥有更多可寻址内存才能解决这个问题（因为您已经在使用 PAE），而是因为您选择的区域拥有更多可寻址内存。

第二种方法（我从未测试过）是尝试让内核更积极地压缩内存。

如果将的值vm.extfrag_threshold从 500 更改为 100，则更有可能压缩内存以尝试遵守高阶分配。虽然我以前从未弄乱过这个值 - 它还取决于中提供的碎片索引/sys/kernel/debug/extfrag/extfrag_index。我目前没有一个装有足够新内核的盒子，无法看到它能提供比这更多的东西。

或者，您可以运行某种 cron 作业（这非常非常丑陋）通过写入来手动压缩内存/proc/sys/vm/compact_memory。

不过说实话，我认为没有办法通过调整系统来避免这个问题——这是内存分配器的本质。改变你使用的平台的架构可能是唯一可以从根本上解决的方案。

Answer

然而，一种“强力”的方法是升级到 64 位操作系统（这是 32 位），因为区域的布局不同。

好的，所以我将尝试回答您为什么会遇到 OOM。这里面有很多因素在起作用。

请求的订单规模以及内核如何处理某些订单规模。
正在选定的区域。
此区域使用的水印。
区域中存在碎片。

如果你查看 OOM 本身，显然有大量可用内存，但还是调用了 OOM-killer？为什么？

请求的订单大小以及内核如何处理某些订单大小

内核按顺序分配内存。“顺序”是连续 RAM 的一个区域，必须满足该区域才能使请求工作。顺序使用算法按数量级排列（因此称为顺序）2^(ORDER + 12)。因此，顺序 0 是 4096，顺序 1 是 8192，顺序 2 是 16384，依此类推。

内核有一个硬编码值，表示什么是“高阶”（> PAGE_ALLOC_COSTLY_ORDER）。这是 4 阶及以上（64kb 或以上为高阶）。

高阶页面分配的满足方式与低阶不同。如果高阶分配无法获取内存，则在现代内核中会这样做。

尝试运行内存压缩例程来对内存进行碎片整理。
绝不调用OOM-killer来满足请求。

您的订单尺寸列在此处

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

顺序 3 是低顺序请求中最高的，并且（如您所见）调用 OOM-killer 来尝试满足它。

请注意，大多数用户空间分配不使用高阶请求。通常，内核需要连续的内存区域。例外情况可能是用户空间使用大页面 - 但这里不是这种情况。

在您的情况下，内核调用顺序 3 分配来将数据包排队到网络堆栈中 - 需要 32kb 分配才能执行此操作。

正在选定的区域。

内核将内存区域划分为区域。之所以进行这种划分，是因为在 x86 上，某些内存区域只能由某些硬件寻址。例如，较旧的硬件可能只能寻址“DMA”区域中的内存。当我们想要分配一些内存时，首先选择一个区域，然后仅有的在做出分配决策时会考虑该区域的可用内存。

虽然我对区域选择算法并不完全了解，但典型的用例从来不是从 DMA 分配，而是通常选择能够满足请求的最低可寻址区域。

在 OOM 期间会吐出大量区域信息，这些信息也可以从中收集/proc/zoneinfo。

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

您拥有的区域 DMA、Normal 和 HighMem 表明是 32 位平台，因为 HighMem 区域在 64 位上不存在。此外，在 64 位系统上，Normal 映射到 4GB 及以上，而在 32 位上，它映射到最多 896Mb（尽管，在您的情况下，内核报告仅管理比这更小的部分：- managed:587540kB。）

通过再次查看第一行，可以知道此分配来自何处，gfp_mask=0x42d0告诉我们进行了哪种类型的分配。最后一个字节 (0) 告诉我们这是来自正常区域的分配。gfp 含义位于包括/linux/gfp.h。

此区域使用的水印。

当内存不足时，回收内存的操作由水印指定。它们显示在这里：min:3044kB low:3804kB high:4564kB。如果可用内存达到“低”，则将进行交换，直到我们超过“高”阈值。如果内存达到“最小”，我们需要通过 OOM-killer 来杀死一些东西以释放内存。

区域中存在碎片。

为了查看特定顺序的内存请求是否可以满足，内核会计算每个顺序的空闲页面数和可用页面数。这在中可读/proc/buddyinfo。OOM-killer 报告还会吐出 buddyinfo，如下所示：

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

为了满足内存分配必须可用内存大小按请求的顺序或更高的分配顺序排列。低阶中有大量可用数据，而高阶中没有可用数据，这意味着您的内存已碎片化。如果您获得非常高阶的分配，则可能（即使有大量可用内存）由于没有可用的高阶页面而无法满足要求。内核可以通过移动大量低阶页面来整理内存碎片（这称为内存压缩），这样它们就不会在可寻址 RAM 空间中留下空隙。

是否调用了 OOM-killer？为什么？

因此，如果我们考虑到这些因素，我们可以得出以下结论；

尝试分配 32kB 连续空间。来自正常区域。
所选区域有足够的可用内存。
有 3、5 和 6 阶内存可用13*32kB (MR) 1*128kB (R) 1*256kB (R)

因此，如果有曾是释放内存，其他命令可以满足请求。发生了什么？

其实，从订单中分配内存不仅仅是检查该订单或更高订单的可用内存量。内核会有效地从总可用内存行中减去所有较低订单的内存，然后对剩余内存执行最小水印检查。

在您的情况下发生的情况是检查我们必须执行的该区域的可用内存。

115000 - (5360*4) - (3667*8) - (3964*16) = 800

此可用内存量将与min水位线（即 3044）进行对比。因此，从技术上讲，您没有剩余可用内存来执行请求的分配。这就是您调用 OOM-killer 的原因。

定影

有两个修复方法。升级到 64 位会改变您的区域分区，使“正常”区域从 4GB 增加到 36GB，因此您不会最终将内存分配“默认”到可能严重碎片化的区域。并不是因为您拥有更多可寻址内存才能解决这个问题（因为您已经在使用 PAE），而是因为您选择的区域拥有更多可寻址内存。

第二种方法（我从未测试过）是尝试让内核更积极地压缩内存。

如果将的值vm.extfrag_threshold从 500 更改为 100，则更有可能压缩内存以尝试遵守高阶分配。虽然我以前从未弄乱过这个值 - 它还取决于中提供的碎片索引/sys/kernel/debug/extfrag/extfrag_index。我目前没有一个装有足够新内核的盒子，无法看到它能提供比这更多的东西。

或者，您可以运行某种 cron 作业（这非常非常丑陋）通过写入来手动压缩内存/proc/sys/vm/compact_memory。

不过说实话，我认为没有办法通过调整系统来避免这个问题——这是内存分配器的本质。改变你使用的平台的架构可能是唯一可以从根本上解决的方案。

Question 2

一开始：你应该真的选择 64 位操作系统。您有充分的理由继续使用 32 位吗？

如果不仔细检查系统（最好是在系统出现故障时），就很难诊断出这个问题，因此我的（快速）帖子或多或少是针对 32 位系统上的内存问题。我是否提到过使用 64 位系统会让这些问题全部消失？

你的问题有三个方面。

首先，即使在 PAE 内核上，每个进程的地址空间也限制为 4GiB[1]。这意味着您的 squid 实例每个进程占用的 RAM 永远不能超过 4GiB。我对 squid 不太熟悉，但如果这是您的主代理服务器，那么这可能还不够。

其次，在具有大量 RAM 的 32 位系统上，所谓的“ZONE_NORMAL”中的大量内存用于存储使用 ZONE_HIGHMEM 中的内存所需的数据结构。这些数据结构本身不能移动到 ZONE_HIGHMEM 中，因为内核用于自身目的的内存必须始终位于 ZONE_NORMAL 中（即前 1GiB 左右）。ZONE_HIGHMEM 中的内存越多（就您而言，很多），这就越成问题，因为内核随后需要越来越多的 ZONE_NORMAL 内存来管理 ZONE_HIGHMEM。随着 ZONE_NORMAL 中的可用内存量耗尽，您的系统可能会在某些任务中失败，因为 ZONE_NORMAL 是很多32 位系统上会发生很多事情。例如，所有与内核相关的内存操作 ;)

第三，即使 ZONE_NORMAL 中还剩下一些内存（我还没有详细查看您的日志），一些内存操作仍需要未碎片化的内存。例如，如果您的所有内存都碎片化为非常小的碎片，那么一些需要更多碎片的操作将会失败。[3] 简单查看一下您的日志，确实会发现 ZONE_DMA 和 ZONE_NORMAL 中存在相当多的碎片。

编辑：Mlfe 的上述回答对其工作原理进行了详细的解释。

再次说明：在 64 位系统上，所有内存都处于 ZONE_NORMAL 中。64 位系统上没有 HIGHMEM 区域。问题解决了。

编辑：你可以看看这里 [4]，看看你是否可以告诉 oom-killer 不要管你重要的进程。这并不能解决所有问题（如果有的话），但可能值得一试。

[1]http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html和https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Answer

一开始：你应该真的选择 64 位操作系统。您有充分的理由继续使用 32 位吗？

如果不仔细检查系统（最好是在系统出现故障时），就很难诊断出这个问题，因此我的（快速）帖子或多或少是针对 32 位系统上的内存问题。我是否提到过使用 64 位系统会让这些问题全部消失？

你的问题有三个方面。

首先，即使在 PAE 内核上，每个进程的地址空间也限制为 4GiB[1]。这意味着您的 squid 实例每个进程占用的 RAM 永远不能超过 4GiB。我对 squid 不太熟悉，但如果这是您的主代理服务器，那么这可能还不够。

其次，在具有大量 RAM 的 32 位系统上，所谓的“ZONE_NORMAL”中的大量内存用于存储使用 ZONE_HIGHMEM 中的内存所需的数据结构。这些数据结构本身不能移动到 ZONE_HIGHMEM 中，因为内核用于自身目的的内存必须始终位于 ZONE_NORMAL 中（即前 1GiB 左右）。ZONE_HIGHMEM 中的内存越多（就您而言，很多），这就越成问题，因为内核随后需要越来越多的 ZONE_NORMAL 内存来管理 ZONE_HIGHMEM。随着 ZONE_NORMAL 中的可用内存量耗尽，您的系统可能会在某些任务中失败，因为 ZONE_NORMAL 是很多32 位系统上会发生很多事情。例如，所有与内核相关的内存操作 ;)

第三，即使 ZONE_NORMAL 中还剩下一些内存（我还没有详细查看您的日志），一些内存操作仍需要未碎片化的内存。例如，如果您的所有内存都碎片化为非常小的碎片，那么一些需要更多碎片的操作将会失败。[3] 简单查看一下您的日志，确实会发现 ZONE_DMA 和 ZONE_NORMAL 中存在相当多的碎片。

编辑：Mlfe 的上述回答对其工作原理进行了详细的解释。

再次说明：在 64 位系统上，所有内存都处于 ZONE_NORMAL 中。64 位系统上没有 HIGHMEM 区域。问题解决了。

编辑：你可以看看这里 [4]，看看你是否可以告诉 oom-killer 不要管你重要的进程。这并不能解决所有问题（如果有的话），但可能值得一试。

[1]http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html和https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Question 3

@MIfe 已经提供关于内核如何处理内存分配的出色文章并且还为您提供了适当的解决方案，例如切换到 64 位操作系统以及通过进行手动内存压缩等恶意黑客/proc/sys/vm/compact_memory攻击cron。

我的意见是另一个可能对您有帮助的解决方法：
我注意到您tcp_tso_segment的内核回溯中有这样的情况，因此请执行以下操作：

# ethtool -K ethX tso off gso off lro off

mm可以通过强制其使用较低的订单来减轻压力。

附言. 可以通过以下方式获取所有卸载列表# ethtool -k ethX

Answer

@MIfe 已经提供关于内核如何处理内存分配的出色文章并且还为您提供了适当的解决方案，例如切换到 64 位操作系统以及通过进行手动内存压缩等恶意黑客/proc/sys/vm/compact_memory攻击cron。

我的意见是另一个可能对您有帮助的解决方法：
我注意到您tcp_tso_segment的内核回溯中有这样的情况，因此请执行以下操作：

# ethtool -K ethX tso off gso off lro off

mm可以通过强制其使用较低的订单来减轻压力。

附言. 可以通过以下方式获取所有卸载列表# ethtool -k ethX

Question 4

崩溃是因为设置了 sysctl“vm.panic_on_oom = 1”——其原理是重新启动系统会使其恢复正常状态。您可以在 sysctl.conf 中更改此设置。

最上面我们可以看到 squid 调用了 oom killer。您可以检查 squid 配置及其最大内存使用量（或者直接换成 64 位操作系统）。

/proc/meminfo 显示高内存区域正在使用中，因此您正在运行具有 36GB 内存的 32 位内核。您还可以看到，在正常区域中，为了满足 squid 对内存的需求，内核扫描了 982 个页面，但没有成功：

pages_scanned:982 all_unreclaimable? yes

Answer

崩溃是因为设置了 sysctl“vm.panic_on_oom = 1”——其原理是重新启动系统会使其恢复正常状态。您可以在 sysctl.conf 中更改此设置。

最上面我们可以看到 squid 调用了 oom killer。您可以检查 squid 配置及其最大内存使用量（或者直接换成 64 位操作系统）。

/proc/meminfo 显示高内存区域正在使用中，因此您正在运行具有 36GB 内存的 32 位内核。您还可以看到，在正常区域中，为了满足 squid 对内存的需求，内核扫描了 982 个页面，但没有成功：

pages_scanned:982 all_unreclaimable? yes

Linux oom情况（32位内核）

答案1

请求的订单大小以及内核如何处理某些订单大小

正在选定的区域。

此区域使用的水印。

区域中存在碎片。

是否调用了 OOM-killer？为什么？

定影

答案2

答案3

答案4

相关内容