NewRelic还是NewRe-Leak?

Spot.IM是网络上最大的评论系统,可以管理许多著名域上的对话,每天处理数十亿的PageView(aol.com,engadget.com,thedrive.com,rt.com等)。 作为解决方案的一部分,我们使用REACT在Node.JS上编写了一个预渲染(也称为服务器端渲染)服务器。 在上个月,我们开始看到预渲染容器中的内存泄漏。 它最初是一个小泄漏,偶尔会突然弹出并消耗整个容器内存,直到崩溃为止。 我们将AWS ECS(EC2容器服务)与Docker和CloudWatch结合使用进行监视(所有泄漏图像均来自该图像)。 这个故事很简单。 我们的服务稳定了几个小时,甚至一天,然后内存开始泄漏。 最近,情况变得更糟,每分钟内存泄漏。 我们到处都看过问题,可以追溯到历史,采摘樱桃并找到造成泄漏的提交。 同时,我们以数千美元的价格购买了NewRelic Pro帐户,以帮助我们定位泄漏(我们已经在系统上运行了NewRelic免费模块) 当我们开始寻找泄漏时,它看起来像这样: 渲染前AVG是平均内存。 您会看到它稳定了一段时间,并且每隔几个小时就会出现一次跳跃。 每次您看到一个drop时,我们都会部署一个新版本来重置内存。 因此,我们使用了很好的旧的众所周知的方法来捕获泄漏-二进制搜索。 由于我们无法使用其他任何工具(堆转储和其他工具)来定位它,因此我们添加了越来越多的NewRelic逻辑和日志来捕获它。…

Java中较弱的Soft和Phantom引用及其重要性

几乎每个Java程序员都知道存在软弱引用,但是通常它们并没有被完全理解。 幻影的鲜为人知。 我认为这有点可惜,因为它们并不复杂(例如,与Locks相比),并且对于了解应用程序是否存在内存问题非常有用。 因此,我准备了一个很小的Github项目,以展示如何使用它们。 同样有趣的是,不同的垃圾收集器如何处理它们,但这将是下一篇文章的主题。 在分析代码之前,让我们考虑一下为什么我们根本需要内存引用。 问题 在所有允许动态分配内存的计算机语言中,一个普遍的问题是找到一种在不再使用内存之后“收集”内存的方法。 有点像在餐厅里,一开始您可以将客户容纳到空表中,但是当您不再有空表时,您需要检查同时已经分配的一些表是否有空。 诸如C之类的某些语言将责任留给用户:您拥有了内存,现在有责任释放它。 这有点像快餐,应该在饭后清理餐桌。 如果每个人的行为正确,这将非常有效。 但是,如果有些客户忘记清理,这很容易成为问题。 与内存相同:很容易忘记释放内存区域。 因此,垃圾收集器(此处为GC)将为您提供帮助。 某些语言(即Java)使用特殊的算法来收集所有未使用的内存。 它们非常好用,对于程序员来说非常方便。 如果您认为GC是相对较新的技术,您可能会被原谅。…