在非常复杂的Ruby应用程序中查找内存泄漏

各位!

使用Ruby并编写一些代码很好。但在过去的这周里，我注意到我们的申请中有一些问题。内存使用量正在像O（x*3）函数一样增长

我们的应用程序非常复杂，它基于EventMachine和其他外部LIB。更重要的是，它使用Ruby 1.8.7-p382在FreeBSD的amd64位版本下运行

我试着自己研究如何在我们的应用程序中发现内存泄漏。 我发现了很多工具和库，但它们在FreeBSD的64位下无法工作，我不知道如何在巨大的ruby应用程序中找到漏洞。如果你只有很少的文件有200-300行代码，这没关系，但是这里你有大约30个文件，平均有200-300行代码

我只是意识到，我需要太多的时间来发现这些漏洞，做一些愚蠢的行为：相信/研究/假设这段代码的某些部分实际上可能正在泄漏，并包装一些跟踪代码，比如使用ruby prof gem技术。但它的速度非常慢，因为正如我所说的，我们有太多的代码

所以，我的问题是，如何在非常复杂的Ruby应用程序中发现内存泄漏，而不将我的全部精力投入到这项工作中

---

提前Thx

在linux设备上运行应用程序有多困难？如果没有同样的内存问题，可能是ruby运行时的特定问题。如果您确实有相同的问题，那么您可以使用所有仅适用于linux的工具和库

---

另一种选择——你能用一些内存跟踪代码来包装你的单元测试吗？大多数单元测试框架使得在每次测试之前/之后添加一些代码变得容易。或者您可以只运行每个测试100000000次，看看内存是否失控？如果是这样，您知道该测试中发生的某些事情导致了泄漏，您可以继续隔离该问题。

尝试一件事，即使它会严重降低性能，也可以通过每隔一段时间调用

GC.start

手动触发垃圾收集器。多久运行一次有点主观，因为运行得越多，应用程序运行得越慢，运行得越少，内存占用就越大

无论出于何种原因，垃圾收集器可能会不时休假，如果有一些繁重的处理正在进行，可能不想干预。因此，您可能需要手动打电话将垃圾带走

避免创建垃圾的一种方法是更有效地使用内存。当数组可以完成任务时，不要创建哈希，当单个字符串足够时，不要创建数组，等等。在您开始随机黑客攻击之前，对您的应用程序进行概要分析，以查看堆中乱七八糟的对象是什么，这一点很重要

---

如果可以，请尝试使用1.9.2，它在内存管理方面取得了显著的进步。如果您需要1.8.7兼容性，Ruby Enterprise Edition也是一个选项，因为它本质上是该版本更好的垃圾收集器。

您是否尝试过使用？虽然您打算使用小批量，但可能您只拥有您认为更多的对象

count = ObjectSpace.each_object() {}
# => 7216

---

例如，我想在我自己的本地linux机器上运行它，但在我的env bsc中执行它太困难了。它是一个巨大的网络应用程序，它依赖于许多其他配置。所以，很快，它只是在配置下硬编码（我知道，它很糟糕），泄漏只发生在生产环境中。不幸的是，我加入了这个项目，在我之前没有人开始编写任何类型的测试。你是故意将很多东西加载到内存中，还是按顺序处理较小的批？区分合法使用的内存和垃圾收集器中占用的内存是很重要的。如果您提到您已经尝试过的工具，这会很有帮助。@tadman这是一种处理小批量的工具sequentially@Andrew格林我提到了ruby教授gem，这是it@CodeGroover例如我以为你已经试过了其他一些工具，基于“我发现了很多工具和库，但它们在FreeBSD的64位下不起作用”。你所说的一切太棒了！现在很有帮助。有太多的物体是件坏事吗？我有193048！我还想知道是我们的托管公司还是我们的代码导致了这一减速。