问题标签 [objgraph]

我有一个 Python 客户端-服务器应用程序，它的服务器已经运行了大约 4 天......它的内存使用量（由 /proc/PID/status -> VmSize 报告）已经增长到大约 660Mb，我想知道是否有可能是内存泄漏，所以我使用objgraph打印出它的内存使用情况（前 20 个对象类型）：

我在那里没有看到任何特别“臭”的东西，我错过了什么吗？也许这只是因为 Python没有立即向操作系统释放未使用的内存？
（这是一个 CherryPy+SQLAlchemy 应用程序）

我有一个生成线程响应处理程序的服务器子类，这些处理程序依次启动应用程序线程。一切都很顺利，除非当我使用ObjGraph时，我看到正确数量的应用程序线程正在运行（我正在进行负载测试并对其进行限制以保持 35 个应用程序实例运行）。

调用objgraph.typestats()可以细分解释器中当前存在的每个对象的实例数量（根据 GC）。查看内存泄漏的输出，我发现 700 个记录器实例——这将是服务器产生的响应处理程序的总数。

当应用程序线程退出 run() 方法时，我调用了 logger.removehandler(memoryhandler) 和 logger.removehandler(filehandler) 以确保没有对记录器实例的延迟引用，而且记录器实例在应用程序线程中完全隔离（没有外部引用它）。作为消除这些记录器实例的最后一步，run() 中的最后一条语句是 del self.logger

为了在 init() 中获取记录器，我为它提供了一个适当大的随机数来命名它，这样它对于文件访问将是不同的——我使用相同的大数字作为日志文件名的一部分以避免应用程序日志冲突。

总而言之，我有 700 个被 GC 跟踪的记录器实例，但只有 35 个活动线程 - 我该如何杀死这些记录器？一个更麻烦的工程师解决方案是创建一个记录器池，并在应用程序线程的生命周期内只获取一个记录器，但这会创建更多代码来维护，什么时候 GC 应该简单地自动处理它。

使用objgraph，我发现了一堆这样的对象：

Python 的垃圾收集器会处理这样的循环，还是会泄漏？

循环的略宽视图：

我最近阅读了 objgraph文档，对以下代码感到困惑

它表明“一个非常明确且易于发现的'泄漏'”。这有内存泄漏吗？是dict _cache吗？

我一直在尝试使用 objgraph 调试 Coopr 包中的内存泄漏：https ://gist.github.com/3855150

我将它固定在一个_SetContainer对象上，但似乎无法弄清楚为什么该对象会持续存在于内存中。这是结果objgraph.show_refs：

如何找到循环引用以及如何让垃圾收集器收集_SetContainer实例？

我之前认为该类本身可能具有自引用（上图中右侧类正下方的元组）。但是 objgraph 总是将继承的类显示为具有自引用元组。您可以在这里看到一个非常简单的测试用例。

我pandas.DataFrame在多线程代码中使用（实际上是DataFrame被调用的自定义子类Sound）。我注意到我有内存泄漏，因为我的程序的内存使用量逐渐增加超过 1000 万，最终达到我的计算机内存的 ~100% 并崩溃。

我使用objgraph尝试跟踪此泄漏，并发现实例的数量MyDataFrame一直在增加，而它不应该：其run方法中的每个线程都创建一个实例，进行一些计算，将结果保存在一个文件中并退出......所以不应该保留任何引用。

使用objgraph我发现内存中的所有数据帧都有类似的参考图：

我不知道这是否正常……看起来这就是将我的对象保存在内存中的原因。任何想法，建议，见解？

我实际上试图在我的 python gtk 应用程序中修复我的内存问题。

我已经阅读了很多关于 python 内存使用的文章，但我无法全部了解，所以我希望你能在这里帮助我。

因此，如果我启动我的应用程序并打开设置窗口，我的内存使用量为 32368 KB。

现在，如果我关闭设置窗口，内存使用量也是 32368 KB。

这是我如何打开和关闭设置窗口的代码示例：

主文件

现在我尝试使用 objgraph 分析活动引用。这就是结果：

打开设置窗口

关闭设置窗口后

有人可以帮助如何释放内存吗？

我正在尝试使用 C/Cython 扩展和multiprocessing.

每个子进程处理一个图像列表，并为每个子进程将输出数组（通常约为 200-300MB 大）通过 aQueue发送到主进程。相当标准的地图/减少设置。

正如您可以想象的那样，对于这么大的数组，内存泄漏可能会占很大比例，并且当多个进程只需要 5-6GB 内存时，它们会愉快地超过 20GB RAM，这很烦人。

• 我尝试通过 Valgrind 运行 Python 的调试版本，并四次检查了我的扩展是否存在内存泄漏，但一无所获。

• 我已经检查了我的 Python 代码中对我的数组的悬空引用，并且还使用 NumPy 的分配跟踪器来检查我的数组是否确实被释放了。他们是。

我做的最后一件事是将 GDB 附加到我的一个进程（这个坏小子现在运行在 27GB RAM 上并且还在计数）并将大部分堆转储到磁盘。令我惊讶的是，转储的文件全是零！大约7G价值的零。

这是 Python/NumPy 中的标准内存分配行为吗？我是否错过了一些明显的东西，可以解释为什么没有使用这么多内存？如何正确管理内存？

编辑：为了记录，我正在运行 NumPy 1.7.1 和 Python 2.7.3。

编辑 2：我一直在用 监视进程strace，似乎它不断增加每个进程的断点（使用brk()系统调用）。

CPython 实际上是否正确释放内存？C 扩展、NumPy 数组呢？谁决定何时调用brk()，是 Python 本身还是底层库（libc...）？

下面是一个带有注释的示例 strace 日志，来自一次迭代（即一个输入图像集）。请注意，断点不断增加，但我确保（使用objgraph）没有有意义的 NumPy 数组保存在 Python 解释器中。

编辑 3： 对于小型/大型 numpy 数组，释放的处理方式是否不同？可能是相关的。我越来越相信我只是分配了太多没有释放到系统的数组，因为它确实是标准行为。将尝试预先分配我的数组并根据需要重用它们。

我有一个 Python 实用程序，它遍历一个tar.xz文件并处理每个单独的文件。这是一个 15MB 的压缩文件，包含 740MB 的未压缩数据。

在一台内存非常有限的特定服务器上，程序由于内存不足而崩溃。我使用objgraph来查看创建了哪些对象。事实证明，这些TarInfo实例没有被释放。主循环与此类似：

输出非常一致：

这种情况一直持续到处理完所有 30,000 个文件。

只是为了确保，我已经注释掉了创建流和处理它的行。内存使用量保持不变 - TarInfo 实例被泄露。

我使用的是 Python 3.4.1，这种行为在 Ubuntu、OS X 和 Windows 上是一致的。

我需要在一些 python 代码中直观地检查对象依赖关系以找到内存泄漏。我正在尝试使用 objgraph，但遇到了问题，因为它的依赖项之一 xdot 需要 gobject，而我找不到在 osx 中获取它的位置。这就是我得到的：

osx上有这个错误的修复吗？或者是否有 objgraph 的替代品可以在 osx 上正常工作？