☰

当可用内存较高时触发 OOM Killer

tag-icon • tag-icon linux memory swap out-of-memory memory-leaks
当可用内存较高时触发 OOM Killer

即使可用 RAM -100MB，我也遇到了随机的 kswapd0 和 OOM 杀手。已经经历过许多其他类似的问题，但我不明白为什么 OOM 杀手会在我的案例中触发。希望有识之士能分享一些见解，为我的研究指明方向。

编辑：从顶部开始，当 OOM 杀手触发时我得到这个输出。另外，我想知道为什么 kswap 会触发 ~100MB 可用？我们的应用程序最多只需要 ~90 个，并且已经分配了 ~50MB。因此，当发生这种情况时，它只尝试了约 40MB。

top - 09:19:06 up 23:57,  0 users,  load average: 4.50, 2.61, 1.87
Tasks: 101 total,   2 running,  99 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.1 us, 62.5 sy,  0.0 ni,  0.0 id, 25.9 wa,  0.0 hi,  4.5 si,  0.0 st
KiB Mem :   507008 total,    99320 free,   355096 used,    52592 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   102308 avail Mem 

top - 09:19:09 up 23:57,  0 users,  load average: 4.50, 2.61, 1.87
Tasks: 100 total,   1 running,  98 sleeping,   0 stopped,   1 zombie
%Cpu(s): 35.8 us, 45.4 sy,  0.0 ni,  0.0 id, 17.4 wa,  0.0 hi,  1.4 si,  0.0 st
KiB Mem :   507008 total,   162280 free,   288952 used,    55776 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   168376 avail Mem

以下是我的回溯。

2022-07-29T09:19:09.117931Z,BTL200072600123,3,0,kernel:,[86254.933997] Out of memory: Kill process 25402 (application) score 181 or sacrifice child
2022-07-29T09:19:09.117941Z,BTL200072600123,3,0,kernel:,[86254.934006] Killed process 25402 (application) total-vm:159852kB, anon-rss:75664kB, file-rss:16020kB
2022-07-29T09:19:09.095963Z,BTL200072600123,4,1,kernel:, [86254.932989] acquisition invoked oom-killer: gfp_mask=0x2084d0, order=0, oom_score_adj=0
2022-07-29T09:19:09.096076Z,BTL200072600123,4,1,kernel:, [86254.933012] CPU: 0 PID: 17939 Comm: acquisition Tainted: G           O    4.1.46 #5
2022-07-29T09:19:09.096142Z,BTL200072600123,4,1,kernel:, [86254.933019] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
2022-07-29T09:19:09.096206Z,BTL200072600123,4,1,kernel:, [86254.933025] Backtrace:
2022-07-29T09:19:09.096270Z,BTL200072600123,4,1,kernel:, [86254.933054] [<800132e4>] (dump_backtrace) from [<80013500>] (show_stack+0x18/0x1c)
2022-07-29T09:19:09.096334Z,BTL200072600123,4,1,kernel:, [86254.933060]  r7:00000000 r6:80a83c70 r5:600f0113 r4:00000000
202
2022-07-29T09:19:09.098354Z,BTL200072600123,4,1,kernel:, [86254.933467] Mem-Info:
2022-07-29T09:19:09.098411Z,BTL200072600123,4,1,kernel:, [86254.933485] active_anon:50599 inactive_anon:6859 isolated_anon:0
2022-07-29T09:19:09.098472Z,BTL200072600123,4,1,kernel:, [86254.933485]  active_file:136 inactive_file:159 isolated_file:0
2022-07-29T09:19:09.098530Z,BTL200072600123,4,1,kernel:, [86254.933485]  unevictable:16 dirty:0 writeback:0 unstable:0
2022-07-29T09:19:09.098589Z,BTL200072600123,4,1,kernel:, [86254.933485]  slab_reclaimable:1089 slab_unreclaimable:2343
2022-07-29T09:19:09.098648Z,BTL200072600123,4,1,kernel:, [86254.933485]  mapped:5971 shmem:8154 pagetables:534 bounce:0
2022-07-29T09:19:09.098704Z,BTL200072600123,4,1,kernel:, [86254.933485]  free:23627 free_pcp:0 free_cma:23127
2022-07-29T09:19:09.098765Z,BTL200072600123,4,1,kernel:, [86254.933518] Normal free:94380kB min:1972kB low:2464kB high:2956kB active_anon:201792kB inactive_anon:27364kB active_file:476kB inactive_file:560kB unevictable:64kB isolated(anon):0kB isolated(file):0kB present:522240kB managed:505984kB mlocked:64kB dirty:0kB writeback:0kB mapped:23728kB shmem:32540kB slab_reclaimable:4356kB slab_unreclaimable:9372kB kernel_stack:1032kB pagetables:2136kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:92508kB writeback_tmp:0kB pages_scanned:6648 all_unreclaimable? yes
2022-07-29T09:19:09.098829Z,BTL200072600123,4,1,kernel:, [86254.933523] lowmem_reserve[]: 0 8 8
2022-07-29T09:19:09.098890Z,BTL200072600123,4,1,kernel:, [86254.933549] HighMem free:128kB min:128kB low:128kB high:132kB active_anon:604kB inactive_anon:72kB active_file:68kB inactive_file:76kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1024kB managed:1024kB mlocked:0kB dirty:0kB writeback:0kB mapped:156kB shmem:76kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:32 all_unreclaimable? no
2022-07-29T09:19:09.098950Z,BTL200072600123,4,1,kernel:, [86254.933555] lowmem_reserve[]: 0 0 0
2022-07-29T09:19:09.099011Z,BTL200072600123,4,1,kernel:, [86254.933564] Normal: 268*4kB (UEMRC) 128*8kB (UERC) 80*16kB (UERC) 8*32kB (RC) 0*64kB 1*128kB (C) 0*256kB 1*512kB (C) 0*1024kB 4*2048kB (C) 20*4096kB (C) = 94384kB
2022-07-29T09:19:09.099068Z,BTL200072600123,4,1,kernel:, [86254.933608] HighMem: 32*4kB (U) 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 128kB
2022-07-29T09:19:09.099126Z,BTL200072600123,4,1,kernel:, [86254.933638] 8449 total pagecache pages
2022-07-29T09:19:09.099183Z,BTL200072600123,4,1,kernel:, [86254.933646] 0 pages in swap cache
2022-07-29T09:19:09.099240Z,BTL200072600123,4,1,kernel:, [86254.933652] Swap cache stats: add 0, delete 0, find 0/0
2022-07-29T09:19:09.099297Z,BTL200072600123,4,1,kernel:, [86254.933656] Free swap  = 0kB
2022-07-29T09:19:09.099353Z,BTL200072600123,4,1,kernel:, [86254.933661] Total swap = 0kB
2022-07-29T09:19:09.099408Z,BTL200072600123,4,1,kernel:, [86254.933665] 130816 pages RAM
2022-07-29T09:19:09.099464Z,BTL200072600123,4,1,kernel:, [86254.933670] 256 pages HighMem/MovableOnly
2022-07-29T09:19:09.099521Z,BTL200072600123,4,1,kernel:, [86254.933675] 4294905824 pages reserved
2022-07-29T09:19:09.099578Z,BTL200072600123,4,1,kernel:, [86254.933680] 65536 pages cma reserved

答案1

粗略地把这些数字加起来，一切似乎都井然有序：你的 RAM 耗尽了，OOM 杀手杀死了你：

2022-07-29T09:19:09.098704Z,BTL200072600123,4,1,kernel:, [86254.933485]  free:23627 free_pcp:0 free_cma:23127

这是 23627 kB 的可用 RAM，您的 systemd.resource-control 设置为MemoryLow24.6 MB：

… Normal free:94380kB min:1972kB low:2464kB

嗯是的。

我变得随机kswap0

嗯，您有 0 个免费掉期：

Free swap  = 0kB

答案2

Linux 不会随机终止出现 OOM 的进程，除非该进程无法为其预期执行的工作分配更多 RAM。

从数字（匿名 RSS:75664kB），看起来某个应用程序正在使用大量内存，这就是它被杀死的原因。

另外两点说明：

  1. 您没有任何交换内存（总交换量 = 0kB）

    这对于没有内存不足的应用程序的快速服务器来说非常有用......否则，最好添加一些交换，以防万一。在我公司的服务器上，99.9%的时间我都有足够的内存。不过，偶尔会有一些东西开始在后台运行，并且服务器会在短时间内耗尽内存（直到该进程退出）。在这种情况下进行交换可以节省 99.9% 的时间，并且不会像疯狂一样读/写，因为这只是一次性事件。

  2. 哪个进程被杀死是一个复杂的启发式。

    它不会自动成为一个试图分配更多内存的进程。它更有可能是分配最多内存的那个。我不知道具体的算法，但操作系统会踢掉一个进程，以便有更大的机会让所有其他进程顺利运行。因此进程 A 可能会调用malloc()，而进程 B 则会出现 OOM。

关于大型服务器的另一个注意事项：它们可能会在“文件”（单独的“部分”）中管理内存。我的服务器有 512Gb RAM，分为两个文件。如果进程尝试使用超过 200Gb 的 RAM，则可能会出现内存不足的情况（这种情况不应经常发生）。如果您还有两个文件，那么一个进程的大小可能会限制在 64Gb 左右。

相关内容