当物理内存不足但有足够的交换空间时，如何让 Linux OOM 杀手不杀死我的进程？
我使用 sysctl vm.overcommit_memory=2 禁用了 OOM 杀戮和过度使用。
VM 有 3 GB 的完全免费的未碎片交换空间，被 OOM 杀死的进程的最大内存使用量小于 200MB。
我知道长期交换对性能来说会很糟糕，但是我现在需要使用交换来在内存要求更高的 valgrind 下进行功能测试。
Mar 7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0
Mar 7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0
Mar 7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar 7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar 7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18
Mar 7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2
Mar 7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc
Mar 7 02:43:11 myhost kernel: Call Trace:
Mar 7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50
Mar 7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd
Mar 7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d
Mar 7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar 7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f
Mar 7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406
Mar 7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8
Mar 7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0
Mar 7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a
Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar 7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f
Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar 7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a
Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar 7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0
Mar 7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d
Mar 7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar 7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291
Mar 7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52
Mar 7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a
Mar 7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71
Mar 7 02:43:11 myhost kernel: Mem-Info:
Mar 7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0
Mar 7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0
Mar 7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0
Mar 7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674
Mar 7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0
Mar 7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0
Mar 7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36
0 all_unreclaimable? yes
Mar 7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972
Mar 7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag
ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t
mp:0kB pages_scanned:792 all_unreclaimable? yes
Mar 7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0
Mar 7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar 7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
Mar 7 02:43:11 myhost kernel: 71 total pagecache pages
Mar 7 02:43:11 myhost kernel: 42 pages in swap cache
Mar 7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093
Mar 7 02:43:11 myhost kernel: Free swap = 3118172kB
Mar 7 02:43:11 myhost kernel: Total swap = 3334140kB
Mar 7 02:43:11 myhost kernel: 262014 pages RAM
Mar 7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
Mar 7 02:43:11 myhost kernel: 8149 pages reserved
Mar 7 02:43:11 myhost kernel: [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
Mar 7 02:43:11 myhost kernel: [ 2054] 0 2054 5101 1 15 4 283 0 upstart-udev-br
Mar 7 02:43:11 myhost kernel: [ 2063] 0 2063 12362 1 28 4 184 -1000 systemd-udevd
Mar 7 02:43:11 myhost kernel: [ 3342] 102 3342 9780 1 23 3 89 0 dbus-daemon
Mar 7 02:43:11 myhost kernel: [ 3423] 0 3423 10864 1 26 3 85 0 systemd-logind
Mar 7 02:43:11 myhost kernel: [ 3441] 0 3441 15344 0 34 3 184 -1000 sshd
Mar 7 02:43:11 myhost kernel: [ 3450] 0 3450 4786 0 14 3 43 0 atd
Mar 7 02:43:11 myhost kernel: [ 3451] 0 3451 5915 0 17 4 65 0 cron
Mar 7 02:43:11 myhost kernel: [ 3457] 101 3457 63962 0 28 3 202 0 rsyslogd
Mar 7 02:43:11 myhost kernel: [ 3516] 0 3516 3919 1 13 3 156 0 upstart-file-br
Mar 7 02:43:11 myhost kernel: [ 3518] 0 3518 4014 0 13 3 265 0 upstart-socket-
Mar 7 02:43:11 myhost kernel: [ 3557] 0 3557 66396 0 32 3 1802 0 fail2ban-server
Mar 7 02:43:11 myhost kernel: [ 3600] 0 3600 3956 1 13 3 39 0 getty
Mar 7 02:43:11 myhost kernel: [ 3601] 0 3601 3198 1 12 3 37 0 getty
Mar 7 02:43:11 myhost kernel: [ 3673] 0 3673 26411 1 55 3 252 0 sshd
Mar 7 02:43:11 myhost kernel: [ 3740] 1000 3740 26411 1 52 3 253 0 sshd
Mar 7 02:43:11 myhost kernel: [ 3741] 1000 3741 5561 0 16 3 431 0 bash
Mar 7 02:43:11 myhost kernel: [ 3820] 103 3820 7863 1 21 3 152 0 ntpd
Mar 7 02:43:11 myhost kernel: [ 3837] 1000 3837 31990 0 58 4 12664 0 memcheck-amd64-
Mar 7 02:43:11 myhost kernel: [ 3841] 1000 3841 32006 0 59 4 12812 0 memcheck-amd64-
Mar 7 02:43:11 myhost kernel: [ 3844] 1000 3844 31950 0 57 4 12035 0 memcheck-amd64-
Mar 7 02:43:11 myhost kernel: [ 3849] 1000 3849 31902 0 56 4 11482 0 memcheck-amd64-
Mar 7 02:43:11 myhost kernel: [ 3853] 1000 3853 1087 0 7 3 27 0 lsof
Mar 7 02:43:11 myhost kernel: [ 3854] 0 3854 26140 5 55 3 230 0 sshd
Mar 7 02:43:11 myhost kernel: [ 3855] 104 3855 15699 0 33 3 202 0 sshd
Mar 7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-amd64-) score 11 or sacrifice child
Mar 7 02:43:11 myhost kernel: Killed process 3841 (memcheck-amd64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB
这是/proc/meminfo
MemTotal: 1015460 kB
MemFree: 277508 kB
MemAvailable: 322032 kB
Buffers: 8336 kB
Cached: 42208 kB
SwapCached: 46088 kB
Active: 58844 kB
Inactive: 116100 kB
Active(anon): 34784 kB
Inactive(anon): 89620 kB
Active(file): 24060 kB
Inactive(file): 26480 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 3334140 kB
SwapFree: 3215756 kB
Dirty: 16 kB
Writeback: 0 kB
AnonPages: 121128 kB
Mapped: 15072 kB
Shmem: 4 kB
Slab: 22668 kB
SReclaimable: 8028 kB
SUnreclaim: 14640 kB
KernelStack: 2016 kB
PageTables: 2532 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3841868 kB
Committed_AS: 380460 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
DirectMap4k: 14208 kB
DirectMap2M: 1034240 kB
DirectMap1G: 0 kB
Mat*_*Ife 38
这似乎是结合两个因素的问题：
这部分是描述为什么会发生这种情况的行之一：
3 月 7 日 02:43:11 myhost 内核：memcheck-amd64-调用 oom-killer：gfp_mask=0x24002c2，order=0，oom_score_adj=0
另一行是这样的：
Mar 7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
|第一行是分配给分配的 GFP 掩码。它基本上描述了内核允许/不允许做什么来满足这个请求。掩码表示一堆标准标志。然而，最后一位“2”表示内存分配应该来自HighMem区域。
如果您仔细查看 OOM 输出，您会发现HighMem/Normal实际上不存在任何区域。
Mar 7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar 7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
HighMem（通常Normal在 x86_64 上也称为）倾向于为标准 896MiB 范围之外的区域映射内存，这些区域可在 32 位系统上直接由内核访问。在 x86_64 上HighMem/Normal似乎涵盖了大小超过 3GiB 的所有页面。
DMA32包含可在 32 位 DMA 设备上访问的用于内存的区域，也就是说，您可以使用 4 字节指针寻址它们。我相信DMA是针对 16 位 DMA 设备的。
一般来说，低内存系统Normal不会存在，因为它DMA32已经涵盖了所有可用的虚拟地址。
您 OOM 杀死的原因是因为有HighMem0 个页面可用的区域的内存分配。鉴于内存不足处理程序绝对无法通过交换、杀死其他进程或任何其他技巧来满足使该区域具有可使用的页面，OOM-killer 只会杀死它。
我相信这是由主机 VM 在启动时膨胀引起的。在 KVM 系统上，您可以设置两个值。
其工作方式是您可以将内存热添加到服务器，直至达到可用内存。但是，您的系统实际上已获得当前内存。
当 KVM 虚拟机启动时，它以可能分配的最大内存（可用内存）开始。在系统的引导阶段，KVM 会逐渐利用其膨胀来收回此内存，而留给您的是您拥有的当前内存设置。
我相信这就是这里发生的事情。Linode 允许您扩展内存，在系统启动时为您提供更多。
这意味着Normal/HighMem在系统生命周期的开始有一个区域。当管理程序将其膨胀时，正常区域就会从内存管理器中消失。但是，我怀疑设置该区域是否可用于分配的标志在应该清除时没有清除。这会导致内核尝试从不存在的区域进行分配。
在解决这个问题方面，您有两种选择。
在内核邮件列表上提出这个问题，看看这是否真的是一个错误、预期的行为或与我所说的完全无关。
请求 linode 将系统上的“可用内存”设置为与“当前内存”相同的 1GiB 分配。因此，系统永远不会膨胀，也永远不会在启动时获得正常区域，从而保持标志清晰。祝他们好运！
您应该能够通过在 6GiB 可用的 KVM 设置中设置您自己的 VM，当前为 1GiB 并使用相同的内核运行您的测试来测试是否是这种情况，以查看您在上面看到的这种行为是否发生。如果是，请将“可用”设置更改为等于 1GiB 电流并重复测试。
我在这里进行了一系列有根据的猜测，并在字里行间阅读以得出这个答案，但我所说的似乎符合已经概述的事实。
我建议测试我的假设并让我们都知道结果。
use*_*517 32
要回答您的标题问题，请使用oom_score_adj(kernel >=2.6.36) 或对于早期内核 (>=2.6.11) oom_adj，请参阅 man proc
/proc/[pid]/oom_score_adj（自 Linux 2.6.36 起）此文件可用于调整用于选择在内存不足情况下杀死哪个进程的 badness 启发式...
/proc/[pid]/oom_adj (Linux 2.6.11 起) 该文件可用于调整分数，用于选择在内存不足 (OOM) 情况下应终止哪个进程...
还有很多要阅读的内容，但是将 oom_score_adj 设置为 -1000 或 oom_adj 设置为 -17 将实现您想要的。
麻烦的是别的东西会被杀死。也许最好确定为什么调用 OOM 并处理它。
Oli*_*lac 12
一些想法（来自我上面的评论），以及有关您情况的有趣阅读的链接：
我建议您检查一下 1) 您可以使用当前内核和配置 (& cpu) 处理超过 3Gb [因为如果 3Gb 是您的系统和操作系统的限制，那么您就超过了它]。2) 您允许交换并且交换子系统已就位并正常工作。祝你好运（我不会解释如何，因为这取决于你的设置和细节。搜索引擎会有所帮助）。并且您没有溢出内核表（pids 的 nb？或其他任何东西（有些可以在内核编译时设置）。
检查整个事物（硬件或虚拟机的模拟硬件等）是否为 64 位。（例如参见：https : //askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381）。cpu & 主机操作系统 & vm 子系统 & vm OS 都应该启用 64 位，否则你将没有真正的 64 位 vm
一些不错的读物：
最后：http : //www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html显示了一种防止您的进程成为 oom 杀手目标的方法！( echo -17 > /proc/PROCESSPID/oom_adj) 。可能容易发生变化，也可能是一件坏事（导致其他类型的故障，因为系统现在不能简单地杀死主要罪犯......）请谨慎使用。@iain 请注意，“oom_adj”适用于较旧的内核，应在较新的内核中替换为“oom_score_adj”。谢谢，伊恩）
除了提到oom_score_adj增加有问题的进程（这可能不会有太大帮助 - 它会降低该进程首先被杀死的可能性，但由于这只是内存密集型进程系统可能不会恢复，直到它最终被杀死），这里有一些想法可以调整：
vm.overcommit_memory=2，也可以调整vm.overcommit_ratio到 90（或者，设置vm.overcommit_memory=0- 请参阅内核过量使用文档）vm.min_free_kbytes以始终保持一些物理 RAM 空闲，从而减少 OOM 需要杀死某些东西的机会（但不要过度，因为它会立即 OOM）。vm.swappiness100（使内核交换更容易）请注意，如果您的内存太少而无法完成手头的任务，即使您没有 OOM，它也可能（或可能不会）变得非常慢——半小时的工作（在具有足够 RAM 的系统上）很容易花费数周时间（当 RAM 替换为交换时）在极端情况下完成，甚至挂起整个 VM。如果交换位于经典旋转磁盘（而不是 SSD）上，则情况尤其如此，因为大量随机读/写对它们来说非常昂贵。
| 归档时间： |
|
| 查看次数： |
26854 次 |
| 最近记录： |