Question

我们在Docker中运行了一个Java应用程序。它有时会被oom-killer杀死，即使所有JVM统计数据看起来都不错。我们还有许多其他应用程序没有这样的问题。

我们的设置：

容器大小限制：480MB
JVM堆限制：250MB
JVM元空间限制：100MB

JVM报告的各种内存统计信息（我们每隔10秒获取一次数据）：

来自容器的日志（可能略有不正常，因为我们使用相同的时间戳获取所有内容）：

java invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
java cpuset=47cfa4d013add110d949e164c3714a148a0cd746bd53bb4bafab139bc59c1149 mems_allowed=0
CPU: 5 PID: 12963 Comm: java Tainted: G               ------------ T 3.10.0-514.2.2.el7.x86_64 #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/14/2014
0000000000000000 0000000000000000 0000000000000046 ffffffff811842b6
ffff88010c1baf10 000000001764470e ffff88020c033cc0 ffffffff816861cc
ffff88020c033d50 ffffffff81681177 ffff880809654980 0000000000000001
Call Trace:
[<ffffffff816861cc>] dump_stack+0x19/0x1b
[<ffffffff81681177>] dump_header+0x8e/0x225
[<ffffffff8118476e>] oom_kill_process+0x24e/0x3c0
[<ffffffff810937ee>] ? has_capability_noaudit+0x1e/0x30
[<ffffffff811842b6>] ? find_lock_task_mm+0x56/0xc0
[<ffffffff811f3131>] mem_cgroup_oom_synchronize+0x551/0x580
[<ffffffff811f2580>] ? mem_cgroup_charge_common+0xc0/0xc0
[<ffffffff81184ff4>] pagefault_out_of_memory+0x14/0x90
[<ffffffff8167ef67>] mm_fault_error+0x68/0x12b
[<ffffffff81691ed5>] __do_page_fault+0x395/0x450
[<ffffffff81691fc5>] do_page_fault+0x35/0x90
[<ffffffff8168e288>] page_fault+0x28/0x30
Task in /docker/47cfa4d013add110d949e164c3714a148a0cd746bd53bb4bafab139bc59c1149 killed as a result of limit of /docker/47cfa4d013add110d949e164c3714a148a0cd746bd53bb4bafab139bc59c1149
memory: usage 491520kB, limit 491520kB, failcnt 28542
memory+swap: usage 578944kB, limit 983040kB, failcnt 0
kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
Memory cgroup stats for /docker/47cfa4d013add110d949e164c3714a148a0cd746bd53bb4bafab139bc59c1149: cache:32KB rss:491488KB rss_huge:2048KB mapped_file:8KB swap:87424KB inactive_anon:245948KB active_anon:245660KB inactive_file:4KB active_file:4KB unevictable:0KB
[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
[12588]     0 12588       46        0       4        4             0 s6-svscan
[12656]     0 12656       46        0       4        4             0 s6-supervise
[12909]     0 12909       46        0       4        3             0 s6-supervise
[12910]     0 12910       46        0       4        4             0 s6-supervise
[12913]     0 12913     1541      207       7       51             0 bash
[12914]     0 12914     1542      206       8       52             0 bash
[12923] 10001 12923     9379     3833      23      808             0 telegraf
[12927] 10001 12927   611126   112606     588    23134             0 java
Memory cgroup out of memory: Kill process 28767 (java) score 554 or sacrifice child
Killed process 12927 (java) total-vm:2444504kB, anon-rss:440564kB, file-rss:9860kB, shmem-rss:0kB

请注意，JVM本身并不会报告任何内存不足错误。

JVM报告的统计数据显示240MB堆限制和140MB非堆使用，仅增加380MB，为其他进程（主要是telegraf）和JVM堆栈留下100MB内存（我们认为问题可能是一个数字线程提升但从这些统计数据来看似乎不是问题。）

Oom-killer显示了一堆与我们的任何设置和其他统计信息不匹配的数字（页面大小默认为4kB）：

JVM total-vm：611126（2.44GB）
JVM rss：112606（450MB）
JVM anon-rss：440MB
JVM文件-rss：10MB
其他进程总rss：4246（17MB）
容器内存限制：491.5MB

以下是问题：

JVM报告内存使用量为380MB，但是oom-killer表示这个过程使用的是450MB。丢失的70MB可以在哪里？
容器应该还剩30MB，而oom-killer说其他进程只使用17MB，所以仍然应该有13MB的可用内存，但它说容器大小等于容器限制。丢失的13MB可以在哪里？

我看到类似的问题，建议Java应用程序可能会分支其他进程并使用OS＆＃39;内存，不会出现在JVM内存使用中。我们自己不会这样做，但我们仍在审查和测试我们的任何图书馆是否可能这样做。无论如何，这是第一个问题的一个很好的解释，但第二个问题对我来说仍然是一个谜。

Answer 1

对于第一个问题，查看JVM的确切参数会很有帮助。

正如您所注意到的，除了堆，堆外和堆外，还有其他多个内存部分。元空间中。其中包括与GC相关的数据结构。如果你想控制jvm使用的绝对内存，你应该使用-XX：MaxRAM，尽管有一个tradefoff可以更精细地控制堆和其他区域。容器化应用程序的一个常见建议是：

-XX：MaxRAM =＆＃39; cat /sys/fs/cgroup/memory/memory.limit_in_bytes'

获得准确的使用测量并非易事。 Mechanical Sympathy列表中的This thread与该主题相关。我将备份复制粘贴，但链接依据Gil Tene的评论，其中第二段特别相关：报告的内存是实际触及的内存，未分配。 Gil建议使用-XX：+ AlwaysPreTouch来确保所有堆页面都被实际触摸（这将强制实际分配物理内存，这将使它们显示在使用的余额中）＆＃34;。与此相关，请注意你的total_vm是2.44GB，而这不是全部在物理内存中（根据* _rss），它表明进程可能分配了更多的内存，其中一些可能最终被拉入rs。

有了可用的数据，我认为最好的指针来自堆图。你的应用程序的工作量肯定会在~18：20更改：有更多的流失，这意味着分配和GC工作（因此，数据）。正如你所说，线程峰值可能不是问题，但它影响jvm内存使用（那些~25个额外线程可能需要> 25MB，具体取决于你的-Xss。）应用程序的基线靠近容器＆＃ 39; s限制因此，在对记忆施加更大压力之后，它会危险地靠近OOM土地。

转到第二个问题（我不是Linux专家，所以这更接近推测），在你的cgroup统计数据中，rss大小不匹配。 AFAIK，rss会计may include pages that are still on SwapCache，所以这可能是造成不匹配的原因。查看您的日志：

内存：使用量491520kB，限制491520kB，failcnt 28542

内存+交换：用法578944kB，限制983040kB，failcnt 0

物理内存确实已满，您可以互换。我的猜测是，导致更频繁GC循环的同一对象流失也可能导致数据被换出（可能发生会计不匹配）。你没有在oom-kill之前提供io统计数据，但这些将有助于确认应用程序确实在交换，以及以什么速率交换。此外，禁用交换容器可能会有所帮助，因为它将避免溢出交换并将流失限制在JVM本身，让您找到正确的-XX：MaxRAM或-Xmx。

我希望有所帮助！

Answer 2

好吧，这确实是一个较晚的答案，更多的是观察。当我尝试使用-XX：MaxRAM时，OOM Killer仍然存在，另外，NMT在Java进程中的读数如何？

也来看看这个article

oom-killer杀死了Docker中的java应用程序 - 报告的内存使用不匹配

2 个答案: