0

我有一个内部 C++ 应用程序，它会无限增长——以至于我们不得不实现一旦 RSS 达到某个峰值大小 (2.0G) 时实际上会杀死它的逻辑，只是为了保持某种秩序。但是，这显示了一些奇怪的行为。

首先，我通过 Valgrind w/memcheck 运行应用程序，并修复了一些随机内存泄漏。但是，这些内存泄漏的程度以 10 兆字节为单位。这是有道理的，因为可能没有实际的内存泄漏——这可能只是应用程序端的内存管理不善。

接下来，我使用 Valgrind w/massif 来检查内存的去向，这就是它变得奇怪的地方。峰值快照为 161M——与我们使用 RSS 字段看到的 1.9G+ 峰值相差甚远。最大的消耗是我所期望的——在 std::string 中——但这并不异常。

最后，这是最令人费解的——在我们意识到这个内存泄漏之前，我实际上是在 AWS 上测试这个服务，只是为了好玩，在 CC2.8XL 机器上将工作人员的数量设置为一个很高的数字，44工人。那是 60.5G 的 RAM，没有交换。快进一个月：我去看主机——低头看，它的内存已经用完了——但是！这些进程仍然运行良好，并且卡在内存使用的不同阶段——几乎均匀分布在 800M 到 1.9G 之间。每隔一段时间就会dmesg打印出关于无法分配内存的 Xen 错误，但除此之外，进程永远不会死亡并继续积极处理（即，它们没有“卡住”）。

我在这里缺少什么吗？它基本上可以工作，但对于我的生活，我不知道为什么。关于下一步要寻找什么，有什么好的建议？有什么工具可以帮助我弄清楚吗？

4

1 回答 1

1

请注意，valgrind memcheck 仅在您“放弃”内存时才发现。while(1) vec.push_back(n++);将填满所有可用内存但不报告任何泄漏。根据事物的声音，您正在某个地方收集占用大量空间的弦乐。我还研究过使用大量内存但没有真正泄漏它的代码[valgrind 很高兴在各个地方都没有泄漏！]。有时您可以通过简单地在内存分配中添加一些标记来跟踪它，或者一些类似的标记，以指示您分配内存的位置。

在std::函数中，通常有一个Allocator参数。如果你实现了几个不同的内存池，你可能会发现你在哪里分配内存。

我还看到过一些情况，我认为进程的内存碎片化了，所以堆中有很多小的空闲空间 - 例如，如果您通过增加细绳。

于 2014-03-19T19:01:56.273 回答