【发布时间】：2012-08-01 18:53:02
【问题描述】：
我正在从事一个项目，该项目涉及使用 python 来读取、处理和写入有时高达几百兆字节的文件。当我尝试处理一些特别大的文件时，程序偶尔会失败。它没有说“内存错误”，但我怀疑这是问题所在（实际上它根本没有给出失败的理由）。
我一直在测试较小文件上的代码并观看“顶部”以了解内存使用情况，通常会达到 60%。 top 说我有 4050352k 总内存，所以 3.8Gb。
同时，我正在尝试使用以下代码来跟踪 python 本身的内存使用情况（请参阅我来自 yesterday 的问题）：
mem = 0
for variable in dir():
variable_ = vars()[variable]
try:
if str(type(variable_))[7:12] == 'numpy':
numpy_ = True
else:
numpy_ = False
except:
numpy_ = False
if numpy_:
mem_ = variable_.nbytes
else:
mem_ = sys.getsizeof(variable)
mem += mem_
print variable+ type: '+str(type(variable_))+' size: '+str(mem_)
print 'Total: '+str(mem)
在运行该块之前，我将所有不需要的变量设置为无，关闭所有文件和图形等。在该块之后，我使用 subprocess.call() 运行所需的 fortran 程序下一阶段的处理。在 fortran 程序运行时查看顶部显示，fortran 程序正在使用 ~100% 的 cpu 和 ~5% 的内存，而 python 正在使用 0% 的 cpu 和 53% 的内存。然而我的小sn-p代码告诉我python中的所有变量加起来只有23Mb，应该是~0.5%。
那么发生了什么？我不希望那个小 sn-p 给我一个关于内存使用情况的位置，但它应该准确到几 Mb 以内吗？还是只是 top 没有注意到内存已被放弃，但如果有必要，其他需要它的程序可以使用它？
根据要求，这是代码的简化部分，它耗尽了所有内存（file_name.cub 是一个 ISIS3 立方体，它是一个包含同一地图的 5 层（波段）的文件，第一层是光谱辐射，接下来的 4 个与纬度、经度和其他细节有关。这是我正在尝试处理的来自火星的图像。StartByte 是我之前从 .cub 文件的 ascii 标头中读取的值，告诉我data、Samples 和 Lines 是地图的维度，也是从表头读取的。）：
latitude_array = 'cheese' # It'll make sense in a moment
f_to = open('To_file.dat','w')
f_rad = open('file_name.cub', 'rb')
f_rad.seek(0)
header=struct.unpack('%dc' % (StartByte-1), f_rad.read(StartByte-1))
header = None
#
f_lat = open('file_name.cub', 'rb')
f_lat.seek(0)
header=struct.unpack('%dc' % (StartByte-1), f_lat.read(StartByte-1))
header = None
pre=struct.unpack('%df' % (Samples*Lines), f_lat.read(Samples*Lines*4))
pre = None
#
f_lon = open('file_name.cub', 'rb')
f_lon.seek(0)
header=struct.unpack('%dc' % (StartByte-1), f_lon.read(StartByte-1))
header = None
pre=struct.unpack('%df' % (Samples*Lines*2), f_lon.read(Samples*Lines*2*4))
pre = None
# (And something similar for the other two bands)
# So header and pre are just to get to the right part of the file, and are
# then set to None. I did try using seek(), but it didn't work for some
# reason, and I ended up with this technique.
for line in range(Lines):
sample_rad = struct.unpack('%df' % (Samples), f_rad.read(Samples*4))
sample_rad = np.array(sample_rad)
sample_rad[sample_rad<-3.40282265e+38] = np.nan
# And Similar lines for all bands
# Then some arithmetic operations on some of the arrays
i = 0
for value in sample_rad:
nextline = sample_lat[i]+', '+sample_lon[i]+', '+value # And other stuff
f_to.write(nextline)
i += 1
if radiance_array == 'cheese': # I'd love to know a better way to do this!
radiance_array = sample_rad.reshape(len(sample_rad),1)
else:
radiance_array = np.append(radiance_array, sample_rad.reshape(len(sample_rad),1), axis=1)
# And again, similar operations on all arrays. I end up with 5 output arrays
# with dimensions ~830*4000. For the large files they can reach ~830x20000
f_rad.close()
f_lat.close()
f_to.close() # etc etc
sample_lat = None # etc etc
sample_rad = None # etc etc
#
plt.figure()
plt.imshow(radiance_array)
# I plot all the arrays, for diagnostic reasons
plt.show()
plt.close()
radiance_array = None # etc etc
# I set all arrays apart from one (which I need to identify the
# locations of nan in future) to None
# LOCATION OF MEMORY USAGE MONITOR SNIPPET FROM ABOVE
所以我在 cmets 中谎称要打开多个文件，这是同一个文件的多个实例。我只继续使用一个未设置为 None 的数组，它的大小约为 830x4000，尽管这以某种方式构成了我可用内存的 50%。我也尝试过 gc.collect，但没有任何变化。我很高兴听到有关如何改进任何代码（与此问题或其他相关）的任何建议。
也许我应该提一下：最初我是完整打开文件（即不是像上面那样逐行打开），逐行打开是为了节省内存。
【问题讨论】：
-
我在长时间运行的进程中使用 numpy 时遇到过类似的问题——它要么像筛子一样泄漏，要么像其他人一样使堆碎片化。您是否创建了很多 numpy 数组并销毁它们？
-
Python 在破坏一些对象实例后不会立即将内存释放回系统。它有一些对象池，称为 arenas，需要一段时间才能释放它们。在某些情况下，您可能会遇到内存碎片，这也会导致进程的内存使用量增加。
-
sys.getsizeof()不是测试内存使用情况的可靠方法。首先，它只跟踪给定 Python 对象的内存，而不是它对内存中其他项目的引用。其次，根据文档，不能保证第 3 方扩展正常工作。另外，@C2H5OH 所说的。 -
@YannRamin：是的，我一次从多个文件中读取一行，将它们转换为 numpy 数组，然后我对数组进行一些算术运算，然后将结果发送到另一个文件.然后使用原始文件中的下一行再次执行此操作。
-
看看你正在运行的实际代码会占用内存会很有帮助。也许这可以改进。
标签： python optimization memory numpy