调试 Python/NumPy 内存泄漏

Question

我正在尝试使用 C/Cython 扩展和multiprocessing 在 Python/NumPy 程序中查找严重内存泄漏的根源。

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

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

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

• 我已经检查了我的 Python 代码中是否存在对我的数组的悬空引用，并且还使用 NumPy 的 allocation tracker 来检查我的数组是否确实已发布。他们是。

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

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

---

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

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

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

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

# Reading .inf files with metadata
# Pretty small, no brk()
open("1_tif_all/AIR00642_1.inf", O_RDONLY) = 6
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9387fff000
munmap(0x7f9387fff000, 4096)            = 0
open("1_tif_all/AIR00642_2.inf", O_RDONLY) = 6
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9387fff000
munmap(0x7f9387fff000, 4096)            = 0
open("1_tif_all/AIR00642_3.inf", O_RDONLY) = 6
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9387fff000
munmap(0x7f9387fff000, 4096)            = 0
open("1_tif_all/AIR00642_4.inf", O_RDONLY) = 6
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9387fff000
munmap(0x7f9387fff000, 4096)            = 0

# This is where I'm starting the heavy processing
write(2, "[INFO/MapProcess-1] Shot 642: Da"..., 68) = 68
write(2, "[INFO/MapProcess-1] Shot 642: Vi"..., 103) = 103
write(2, "[INFO/MapProcess-1] Shot 642: Re"..., 66) = 66

# I'm opening a .tif image (752 x 480, 8-bit, 1 channel)
open("1_tif_all/AIR00642_3.tif", O_RDONLY) = 6
read(6, "II*\0JC\4\0", 8)               = 8
mmap(NULL, 279600, PROT_READ, MAP_SHARED, 6, 0) = 0x7f9387fbb000
munmap(0x7f9387fbb000, 279600)          = 0
write(2, "[INFO/MapProcess-1] Shot 642: Pr"..., 53) = 53

# Another .tif
open("1_tif_all/AIR00642_4.tif", O_RDONLY) = 6
read(6, "II*\0\266\374\3\0", 8)         = 8
mmap(NULL, 261532, PROT_READ, MAP_SHARED, 6, 0) = 0x7f9387fc0000
munmap(0x7f9387fc0000, 261532)          = 0
write(2, "[INFO/MapProcess-1] Shot 642: Pr"..., 51) = 51
brk(0x1aea97000)                        = 0x1aea97000

# Another .tif
open("1_tif_all/AIR00642_1.tif", O_RDONLY) = 6
read(6, "II*\0\220\253\4\0", 8)         = 8
mmap(NULL, 306294, PROT_READ, MAP_SHARED, 6, 0) = 0x7f9387fb5000
munmap(0x7f9387fb5000, 306294)          = 0
brk(0x1af309000)                        = 0x1af309000
write(2, "[INFO/MapProcess-1] Shot 642: Pr"..., 53) = 53
brk(0x1b03da000)                        = 0x1b03da000

# Another .tif
open("1_tif_all/AIR00642_2.tif", O_RDONLY) = 6
mmap(NULL, 345726, PROT_READ, MAP_SHARED, 6, 0) = 0x7f9387fab000
munmap(0x7f9387fab000, 345726)          = 0
brk(0x1b0c42000)                        = 0x1b0c42000
write(2, "[INFO/MapProcess-1] Shot 642: Pr"..., 51) = 51

# I'm done reading my images
write(2, "[INFO/MapProcess-1] Shot 642: Fi"..., 72) = 72

# Allocating some more arrays for additional variables
# Increases by about 8M at a time
brk(0x1b1453000)                        = 0x1b1453000
brk(0x1b1c63000)                        = 0x1b1c63000
brk(0x1b2473000)                        = 0x1b2473000
brk(0x1b2c84000)                        = 0x1b2c84000
brk(0x1b3494000)                        = 0x1b3494000
brk(0x1b3ca5000)                        = 0x1b3ca5000

# What are these mmap calls doing here?
mmap(NULL, 270594048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9377df1000
mmap(NULL, 270594048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9367be2000
mmap(NULL, 270594048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f93579d3000
mmap(NULL, 270594048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f93477c4000
mmap(NULL, 270594048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f93375b5000
munmap(0x7f93579d3000, 270594048)       = 0
munmap(0x7f93477c4000, 270594048)       = 0
mmap(NULL, 270594048, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f93579d3000
munmap(0x7f93375b5000, 270594048)       = 0
mmap(NULL, 50737152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9354970000
munmap(0x7f9354970000, 50737152)        = 0
brk(0x1b4cc6000)                        = 0x1b4cc6000
brk(0x1b5ce7000)                        = 0x1b5ce7000

---

编辑 3： Is freeing handled differently for small/large numpy arrays? 可能是相关的。我越来越相信我只是分配了太多没有释放到系统的数组，因为它确实是标准行为。将尝试预先分配我的数组并根据需要重用它们。

Answer 1

哦。我真的应该第五次检查那些 C 扩展。

我忘记减少我从 C 分配的临时 NumPy 数组之一中的引用计数。该数组没有留下 C 代码，所以我没有看到我需要释放它。

我仍然不知道为什么它没有出现在objgraph。