linux – oom-killer杀死了Docker中的java应用程序 – 报告的内存使用不匹配
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了linux – oom-killer杀死了Docker中的java应用程序 – 报告的内存使用不匹配，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5658字，纯文字阅读大概需要9分钟。
内容图文
我们有一个在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应用程序可能会分支其他进程并使用操作系统的内存,这些内存将不会显示在JVM内存使用中.我们自己不这样做,但我们仍在审查和测试我们的任何库是否可能这样做.无论如何,这是第一个问题的一个很好的解释,但第二个问题对我来说仍然是一个谜.
解决方法:
对于第一个问题,查看JVM的确切参数会很有帮助.
正如您所注意到的,除了堆,堆外和堆外,还有其他多个内存部分.元空间中.其中包括与GC相关的数据结构.如果你想控制jvm使用的绝对内存,你应该使用-XX：MaxRAM,尽管有一个tradefoff可以更精细地控制堆和其他区域.容器化应用程序的常见建议是：
-XX:MaxRAM=’cat /sys/fs/cgroup/memory/memory.limit_in_bytes’
获得准确的使用测量并非易事.来自Mechanical Sympathy列表的This thread与该主题相关.我将不遗余力地复制粘贴,但链接依据Gil Tene的评论,其中第二段特别相关：报告的内存是实际触及的内存,未分配. Gil建议使用-XX：AlwaysPreTouch来“确保所有堆页面都被实际触摸(这将强制实际分配物理内存,这将使它们显示在使用的余额中”).与此相关,请注意你的total_vm是2.44GB,而这不是全部在物理内存中(根据* _rss),它表明该进程可能分配更多的内存,其中一些可能最终被拉入rss.
有了可用的数据,我认为最好的指针来自堆图.您的应用程序的工作量肯定会在~18：20更改：有更多的流失,这意味着分配和GC工作(因此,数据).正如你所说,线程峰值可能不是问题,但它会影响jvm内存使用(那些~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应用程序 – 报告的内存使用不匹配全部内容，希望文章能够帮你解决linux – oom-killer杀死了Docker中的java应用程序 – 报告的内存使用不匹配所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。