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

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

我们的设置：

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

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

从容器中logging（可能稍微不按顺序，因为我们把它们全部用相同的时间戳记）：

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杀手显示一堆数字，不符合我们的任何设置和其他统计（页面大小是默认的4kB）：

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

所以这里是问题 ：

• JVM报告内存使用量为380MB，但是杀手锏说这个过程使用的是450MB。 在哪里可以失去70MB？
• 容器仍然有30MB剩余空间，而杀手锏说其他进程只用了17MB，所以仍然有13MB可用内存，但是容器大小等于容器限制。 失踪的13MB在哪里？

我曾经看到类似的问题，build议Java应用程序可能会分叉其他进程并使用操作系统的内存，这些内存不会显示在JVM内存使用情况中。 我们自己不这样做，但是我们仍然在检查和testing我们的任何一个图书馆是否会这样做。 无论如何，这是对第一个问题的一个很好的解释，但是第二个对我来说仍然是一个谜。