我正在分析我们软件中的高内存消耗问题。我有一个对应于这种高内存消耗的核心文件（这个核心文件是通过杀死我们生成核心文件的应用程序来生成的）。但是我无法使用这个核心文件查看实际的内存消耗。我使用了 Totalview 和 gdb ......使用这两个我没有得到我的进程消耗的总内存的快照以及哪个库正在消耗所有内存。
这种内存消耗持续了 10 到 20 天，因此我试图找出导致这种高内存消耗的原因。
valgrind 可以帮我分析这个核心文件吗？
非常感谢任何输入/建议。
问问题
865 次
1 回答
0
@suresh，
您好，我是 Rogue Wave Software 的 TotalView 产品经理。
你能再描述一下这个场景吗？程序是否在“正常内存消耗”的情况下运行了很长时间，然后突然内存消耗达到顶峰？还是程序缓慢而稳定地消耗内存，直到耗尽可用资源？
当它崩溃时，它崩溃是因为它确实耗尽了内存，还是因为它已经开始交换并且没有响应而杀死它？
一般来说，我建议在 MemoryScape 下运行它（在 TotalView 或独立版本中），当它开始显示意外的内存消耗时，你想暂停它并运行内存泄漏报告。这很可能会指出问题所在。
内存使用可能不是“经典”泄漏，因为您仍然有引用数据的指针 - 但您只是过度分配。在这种情况下，您不会在泄漏报告中看到任何内容，但是您可以通过观察哪些分配正在增长来找出哪个分配“变坏了”。有很多方法可以做到这一点。
定期暂停并注意堆使用情况如何在堆状态源代码报告中分解。例如，您可能会注意到与特定源代码文件关联的分配数量不断增加。
如果您使用的是 TotalView，您可以在程序似乎表现良好时使用“设置堆基线”功能，然后根据此基线进行过滤。同样，您可能希望使用源代码报告（尽管图形或回溯报告也支持过滤）。
或者您可以使用“导出内存数据”功能来存储“正常”堆状态的图像。这将创建一个二进制堆状态文件。然后让程序运行，直到您进入程序具有高内存消耗的状态。此时您暂停您的实时应用程序，加载存储的堆数据文件，然后您可以进行比较。
哇，这越来越长了。最后一个想法。你说你正在获取核心文件。在调试器下，您应该有机会在清理运行程序之前检查它。如果这没有发生，请告诉我。如果您真的想通过核心文件工作（例如，这发生在生产环境中并且您不想在那里运行调试器），请告诉我们——我们可以通过一些技术使用 HIA 和然后使您能够对堆状态进行离线分析。
祝你好运！
克里斯·戈布拉斯
Rogue Wave Software TotalView 和 ThreadSpotter 首席产品经理
电子邮件：第一。最后在 roguewave 。com
于 2013-08-29T21:15:02.503 回答