江门网站seo关键词排名优化,wordpress 提速 插件,常德网站建设哪家快,银川建设公司网站现在是早上6点。 我清醒地总结了导致我太早醒来的电话的事件序列。 这些故事开始时#xff0c;我的电话警报响了。 困倦而脾气暴躁的我检查了电话#xff0c;看我是否真的疯了以至于无法在凌晨5点设置唤醒警报。 不#xff0c;这是我们的监视系统#xff0c;表明Plumbr服务… 现在是早上6点。 我清醒地总结了导致我太早醒来的电话的事件序列。 这些故事开始时我的电话警报响了。 困倦而脾气暴躁的我检查了电话看我是否真的疯了以至于无法在凌晨5点设置唤醒警报。 不这是我们的监视系统表明Plumbr服务之一已关闭。 作为该领域经验丰富的资深人士我开启了浓缩咖啡机朝着解决方案迈出了正确的第一步。 喝杯咖啡我有能力解决这些问题。 首先怀疑的是应用程序本身在崩溃之前似乎表现完全正常。 没有错误没有警告标志在应用程序日志中没有任何可疑的痕迹。 我们已经进行的监视已注意到该进程已终止并且已经重新启动了崩溃的服务。 但是由于我的血液中已经含有咖啡因所以我开始收集更多证据。 30分钟后我发现自己盯着/var/log/kern.log中的以下内容 Jun 4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice child Jun 4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB 显然我们成为了Linux内核内部的受害者。 众所周知Linux是由一堆邪恶的生物称为“ 守护程序 ”构建的。 这些守护程序由多个内核作业管理其中之一似乎特别危险。 显然所有现代Linux内核都具有一种称为“ 内存不足杀手 ”的内置机制该机制可以在极低内存条件下消除您的进程。 当检测到这种情况时将启动杀手并选择要杀死的进程。 使用一组对所有过程进行评分的启发式方法选择目标然后选择得分最差的目标来杀死目标。 了解“内存不足的杀手”” 默认情况下Linux内核允许进程请求的内存比系统中当前可用的内存更多。 考虑到大多数进程实际上从未真正使用过它们分配的所有内存因此这在世界范围内都是有意义的。 与这种方法最简单的比较是与电缆运营商进行比较。 他们向所有消费者提供100Mbit的下载承诺远远超出了他们网络中的实际带宽。 再次押注的事实是用户将不会同时全部使用其分配的下载限制。 因此一个10Gbit链路可以成功服务超过我们的简单数学所允许的100个用户。 如果您的某些程序正在耗尽系统内存的路径上这种方法的副作用是显而易见的这可能导致内存极低无法分配任何页面进行处理。 您可能已经遇到过这样的情况即使没有root帐户也无法杀死有问题的任务。 为防止此类情况杀手启动并确定要杀死的进程。 您可以从RedHat文档中的本文中了解有关微调“ 内存不足杀手 ”行为的更多信息。 是什么触发了内存不足杀手 现在我们有了上下文仍然不清楚是什么触发了“杀手”并在凌晨5点将我叫醒 更多调查显示 / proc / sys / vm / overcommit_memory中的配置允许过量使用内存–设置为1表示每个malloc应该成功。 该应用程序在EC2 m1.small实例上运行。 EC2实例默认情况下已禁用交换。 这两个事实再加上我们服务中流量的突然激增导致应用程序请求越来越多的内存来支持那些额外的用户。 过量使用配置允许为这个贪婪的过程分配越来越多的内存最终触发了“ 内存不足杀手 ”他正在按照自己的意图去做。 在半夜杀死我们的应用程序并将我叫醒。 例 当我向工程师描述这种行为时其中一位工程师很感兴趣可以创建一个小的测试用例来重现错误。 在Linux上编译并启动以下Java代码段时我使用了最新的稳定Ubuntu版本 package eu.plumbr.demo; public class OOM {public static void main(String[] args){ java.util.List l new java.util.ArrayList(); for (int i 10000; i 100000; i) {try {l.add(new int[100_000_000]);} catch (Throwable t) {t.printStackTrace();}} } } 那么您将面临同样的内存不足杀死进程PIDjava得分SCORE或牺牲子消息。 请注意您可能需要调整交换文件和堆大小在我的测试用例中我使用了通过-Xmx2g指定的2g堆以及以下配置进行交换 swapoff -a dd if/dev/zero ofswapfile bs1024 count655360 mkswap swapfile swapon swapfile解 有几种方法可以处理这种情况。 在我们的示例中我们只是将系统迁移到具有更多内存的实例。 我还考虑了允许交换但是在咨询了工程人员之后我想起了一个事实那就是JVM上的垃圾回收进程不擅长在交换下运行因此该选项不在讨论之列。 其他可能性包括微调OOM杀手 在几个小实例上水平扩展负载或减少应用程序的内存需求。 如果您发现研究有趣– 在Twitter或RSS 上关注Plumbr 我们将继续发布有关Java内部知识的见解。 翻译自: https://www.javacodegeeks.com/2014/06/out-of-memory-kill-process-or-sacrifice-child.html