我有一个内部 C++ 应用程序，它会无限增长——增长如此之大，以至于我们不得不实现逻辑，一旦 RSS 达到某个峰值大小 (2.0G)，我们就不得不执行实际终止它的逻辑，只是为了保持某种秩序。但是，这显示了一些奇怪的行为。
首先，我通过带有 memcheck 的 Valgrind 运行应用程序，并修复了一些随机内存泄漏。但是，这些内存泄漏的范围以 10 兆字节为单位进行测量。这是有道理的，因为可能没有实际的内存泄漏——它可能只是应用程序端的内存管理不善。
接下来，我使用带有 massif 的 Valgrind 来检查内存的去向，这就是它变得奇怪的地方。峰值快照为 161M——远不及我们使用 RSS 字段看到的 1.9G+ 峰值。最大的消耗是我预期的地方——在 std::string 中——但这并不异常。
最后，这是最令人费解的——在我们意识到这个内存泄漏之前，我实际上是在 AWS 上测试这个服务，只是为了好玩，在 CC2.8XL 上将 worker 数量设置为较高的数量机，44名 worker 。那是 60.5G RAM，没有交换空间。快进一个月:我去查看主机——发现它的 RAM 已达到极限——但是!进程仍然运行良好，并停留在内存使用的不同阶段——几乎均匀分布在 800M 到 1.9G 之间。每隔一段时间 dmesg 就会打印出一个关于无法分配内存的 Xen 错误，但除此之外，进程永远不会死掉并继续积极处理(即，它们不会“卡住”) .
我在这里缺少什么吗？它基本上是有效的，但对于我的生活，我无法弄清楚为什么。关于接下来要寻找什么的好的建议是什么？有什么工具可以帮助我解决这个问题吗？
最佳答案
请注意，valgrind memcheck 仅在您“放弃”内存时发现。 while(1) vec.push_back(n++); 将填充所有可用内存但不报告任何泄漏。从事物的声音来看，你正在某个地方收集字符串，占用了大量空间。我还研究过使用大量内存但并没有真正泄漏它的代码 [valgrind 很高兴在各个地方都没有泄漏!]。有时您可以通过简单地向内存分配添加一些标记或类似的标记来跟踪它，以指示您在何处分配内存。
在 std:: 函数中，通常有一个 Allocator 参数。如果你实现了几个不同的内存池，你可能会发现你在哪里分配内存。
我还看到过这样的情况，我认为进程的内存是碎片化的，因此堆中有很多小的可用空间——例如，如果您通过添加到字符串的大小。
关于c++ - OOM 时不会崩溃的内存泄漏，或出现在 massif/valgrind 中，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22514065/