我们有一个在 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，剩下 100MB 内存用于其他进程(主要是 telegraf)和 JVM 堆栈(我们认为问题可能是一个数字线程提高，但从统计数据来看，这似乎不是问题)。
Oom-killer 显示了一堆与我们的任何设置和其他统计信息都不匹配的数字(页面大小默认为 4kB):
- JVM 总虚拟机:611126 (2.44GB)
- JVM RSS:112606 (450MB)
- JVM 匿名RSS:440MB
- JVM 文件-rss:10MB
- 其他进程总计 rss:4246 (17MB)
- 容器内存限制:491.5MB
以下是问题:
- JVM 报告内存使用量 380MB，但 oom-killer 说这个进程正在使用 450MB。丢失的 70MB 可能在哪里？
- 容器应该还有 30MB 剩余，而 oom-killer 说其他进程只使用了 17MB，所以应该还有 13MB 空闲内存，但它说容器大小等于容器限制。丢失的 13MB 可能在哪里？
我看到过类似的问题，建议 Java 应用程序可能会 fork 其他进程并使用操作系统的内存，这不会显示在 JVM 内存使用情况中。我们自己不这样做，但我们仍在审查和测试我们的任何库是否可能这样做。无论如何，这是对第一个问题的一个很好的解释，但第二个问题对我来说仍然是一个谜。
最佳答案
对于第一个问题，查看 JVM 的确切参数会很有帮助。
正如您所注意到的，除了堆、堆外和元空间之外，内存还有多个其他部分。与 GC 相关的数据结构就是其中之一。如果您想控制 jvm 使用的绝对内存，您应该使用 -XX:MaxRAM，尽管需要权衡对堆和其他区域进行更精细的控制。容器化应用的一个常见建议是:
-XX:MaxRAM='cat /sys/fs/cgroup/memory/memory.limit_in_bytes'
获得准确的使用情况测量并非易事。 This thread机械同情列表中的内容与该主题相关。我将不进行复制粘贴，但链接位于 Gil Tene 的评论中，其中第二段特别相关:报告的内存是实际触及的内存，未分配。 Gil 建议使用 -XX:+AlwaysPreTouch 来“确保实际触及所有堆页面(这将强制实际分配物理内存，这将使它们显示在已用余额中)”。与此相关，请注意，您的 total_vm 为 2.44GB，虽然这并非全部在物理内存中(根据 *_rss)，但它表明该进程可能正在分配更多内存，其中一些最终可能会被拉入 rss。
有了可用的数据，我认为最好的指针来自堆图。您的应用程序的工作负载肯定会在 ~18:20 发生变化:流失更多，这意味着分配和 GC 工作(因此是数据)。正如您所说，线程峰值可能不是问题，但它会影响 jvm mem 的使用(那些约 25 个额外线程可能需要 >25MB，具体取决于您的 -Xss。)应用程序的基线接近容器的限制，因此在给内存带来更大的压力，它危险地接近 OOM 土地。
转到第二个问题(我不是 Linux 专家，所以这更接近推测)，在您的 cgroup 统计数据中，rss 大小不匹配。 AFAIK，RSS 会计 may include pages that are still on SwapCache ，所以这可能是不匹配的原因。查看您的日志:
memory: usage 491520kB, limit 491520kB, failcnt 28542
memory+swap: usage 578944kB, limit 983040kB, failcnt 0
物理内存确实已满，而您正在交换。我的猜测是，导致更频繁 GC 周期的相同对象流失也可能导致数据被换出(可能发生会计不匹配)。您没有在 oom-kill 之前提供 io 统计信息，但这些将有助于确认该应用程序确实在交换，以及交换速度是多少。此外，禁用容器上的交换可能会有所帮助，因为它可以避免溢出交换和限制 JVM 本身的流失，让您找到正确的 -XX:MaxRAM 或 -Xmx。
希望对你有帮助!
关于linux - oom-killer 杀死 Docker 中的 java 应用程序 - 报告内存使用不匹配，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47886411/