【问题标题】:Checking all sorts of memory usage during the runtime of a C++ Application在 C++ 应用程序运行时检查各种内存使用情况
【发布时间】:2016-08-19 09:05:27
【问题描述】:

我正在使用 CentOS 7 并且正在运行 C++ 应用程序。最近,我切换到了应用程序用于各种 MySQL C API 函数的库的较新版本。但是在集成新库之后,我看到程序的内存使用量大幅增加,即如果运行超过一两天,应用程序就会崩溃。确切地说,应用程序的内存使用量开始增加,直至应用程序单独使用系统总内存的 74.9%,然后被系统强制关闭。

有什么方法可以跟踪整个应用程序的内存使用情况,包括静态变量。我已经尝试过 valgrind 的工具 Massif

谁能告诉我内存使用量增加的可能原因或任何可以让我深入了解内存分配方式(静态和动态)的工具。有没有什么工具可以告诉我们在 linux 环境中运行的 C++ 应用程序的内存分配?

提前致谢!

【问题讨论】:

  • Valgrind 应该是分析这类问题的正确工具,这似乎是一个经典的内存泄漏。
  • @Torbjörn,我也检查了 valgrind,在运行时持续时间约为 10 分钟的情况下,用于执行应用程序的 HEAP 摘要部分中的内存分配差异约为 1 GB。
  • 您还可以覆盖全局 new 运算符和 delete 运算符。我以前这样做是为了保留尚未删除的堆分配内存指针的缓存。然后是一个单独的线程,每隔几分钟打印一次该信息。

标签: c++ linux memory-leaks heap-memory mysql-connector


【解决方案1】:

静态内存在程序启动时分配。您是否看到内存增长或启动增加?

由于“崩溃需要一两天”,因此问题可能是内存泄漏或数据结构的无限增长。 Valgrind 应该能够在这两个方面提供帮助。如果 valgrind 使用 --leak-check-full 选项显示大泄漏,那么您可能已经发现了问题。

要检查无限增长,请在程序中您怀疑堆已增长的位置放置一个抢占式 _exit()。例如,在主循环上放置一个计时器,并在 10 分钟后让程序 _exit。如果 valgrind 显示“退出时使用中”很大,那么您的数据结构可能会无限增长,但不会泄漏。 Massif 可以帮助追踪这一点。 ms_print 给出了函数堆栈分配的详细信息。

如果您发现问题,请尝试切换回旧版本的库。如果问题消失,请检查并确保您在新版本中正确使用 API。如果您没有源代码,那么您在修复方面有点卡住了。

如果你想更进一步,你可以为 malloc/free 编写一个共享库插入器,看看发生了什么。这是一个很好的start。 Linux 具有backtrace 功能,可以帮助确定确切的堆栈。

最后,如果你必须使用 3rd 方库并且发现堆在没有限制或泄漏的情况下增长,那么你可以使用共享库插入器直接调用 free/delete。这是一个冒险的最后一搏不推荐的策略,但我已经在生产中使用了一个流程。

【讨论】:

    猜你喜欢
    • 2011-09-20
    • 2010-10-02
    • 2012-11-12
    • 1970-01-01
    • 2013-05-11
    • 1970-01-01
    • 2011-06-01
    • 1970-01-01
    • 2015-05-25
    相关资源
    最近更新 更多