我们有一个在Docker中运行的Java应用程序。尽管所有JVM统计数据看起来都很正常，但它有时会被oom-killer杀死。我们还有几十个其他没有这种问题的应用程序。
我们的设置：
容器大小限制：480MB
JVM堆限制：250MB
JVM元空间限制：100MB
JVM报告的各种内存统计数据（我们每10秒钟获取一次数据）：
请注意，JVM本身不会报告任何内存不足错误。
JVM报告的统计数据显示堆限制为240MB，非堆使用量为140MB，总共只有380MB，留下100MB的内存供其他进程（主要是telegraf）和JVM堆栈使用（我们认为问题可能是线程数量增加，但从这些统计数据中看来似乎不是问题）。
Oom-killer显示了一堆数字，这些数字与我们的任何设置和其他统计数据都不匹配（页面大小默认为4kB）：
我们的设置：
容器大小限制：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 total-vm: 611126 (2.44GB)
- JVM rss: 112606 (450MB)
- JVM anon-rss: 440MB
- JVM file-rss: 10MB
- other processes total rss: 4246 (17MB)
- container memory limit: 491.5MB
- JVM报告内存使用量为380MB，但oom-killer说该进程正在使用450MB。缺失的70MB在哪里？
- 容器应该仍然有30MB剩余，oom-killer说其他进程仅使用了17MB，因此应该还有13MB的空闲内存，但它说容器大小等于容器限制。缺失的13MB在哪里？
我看到类似的问题，有人建议Java应用程序可能会分叉其他进程并使用操作系统的内存，这不会显示在JVM内存使用情况中。我们自己没有这样做，但我们仍在审查和测试我们的任何库是否会这样做。无论如何，这是对第一个问题的很好的解释，但第二个问题对我来说仍然是一个谜。