我正在处理的大型文件每个都有几百万条记录(大约2GB解压缩,几百MB gzip).

我使用islice遍历记录,这使得我想测试代码时可以得到一小部分(用于调试和开发)或整个过程.我注意到我的代码的内存使用量过大,因此我试图在代码中查找内存泄漏.

以下是成对读取(我在其中打开两个文件并压缩记录)上的memory_profiler的输出,仅提供1​​0 ** 5个值(默认值被覆盖).

Line #    Mem usage    Increment   Line Contents
================================================
   137   27.488 MiB    0.000 MiB   @profile
   138                             def paired_read(read1, read2, nbrofitems = 10**8):
   139                              """ Procedure for reading both sequences and stitching them together """
   140   27.488 MiB    0.000 MiB    seqFreqs = Counter()
   141   27.488 MiB    0.000 MiB    linker_str = "~"
   142                              #for rec1, rec2 in izip(read1, read2):
   143 3013.402 MiB 2985.914 MiB    for rec1, rec2 in islice(izip(read1, read2), nbrofitems):
   144 3013.398 MiB   -0.004 MiB        rec1 = rec1[9:]                         # Trim the primer variable sequence
   145 3013.398 MiB    0.000 MiB        rec2 = rec2[:150].reverse_complement()  # Trim the low quality half of the 3' read AND take rev complement
   146                                  #aaSeq = Seq.translate(rec1 + rec2)
   147                             
   148                                  global nseqs 
   149 3013.398 MiB    0.000 MiB        nseqs += 1
   150                             
   151 3013.402 MiB    0.004 MiB        if filter_seq(rec1, direction=5) and filter_seq(rec2, direction=3):
   152 3013.395 MiB   -0.008 MiB            aakey = str(Seq.translate(rec1)) + linker_str + str(Seq.translate(rec2))
   153 3013.395 MiB    0.000 MiB            seqFreqs.update({ aakey : 1 })  
   154                                  
   155 3013.402 MiB    0.008 MiB    print "========================================"
   156 3013.402 MiB    0.000 MiB    print "# of total sequences: %d" % nseqs
   157 3013.402 MiB    0.000 MiB    print "# of filtered sequences: %d" % sum(seqFreqs.values())
   158 3013.461 MiB    0.059 MiB    print "# of repeated occurances: %d" % (sum(seqFreqs.values()) - len(list(seqFreqs)))
   159 3013.461 MiB    0.000 MiB    print "# of low-score sequences (<20): %d" % lowQSeq
   160 3013.461 MiB    0.000 MiB    print "# of sequences with stop codon: %d" % starSeqs
   161 3013.461 MiB    0.000 MiB    print "========================================"
   162 3013.504 MiB    0.043 MiB    pprint(seqFreqs.most_common(100), width = 240)

简而言之,该代码对记录进行了一些过滤,并跟踪了字符串在文件中出现的次数(在这种情况下为成对的压缩字符串).

计数器中带有整数的150个字符的100000字符串应该落在100 MB的顶部附近,我使用@AaronHall通过以下函数进行了检查.

给定memory_profiler的输出,我怀疑islice在迭代过程中不会放开先前的实体.谷歌搜索使我到达this bug report,但是它被标记为Python 2.7已解决,这是我当前正在运行的.

有什么意见吗？

编辑：我已经尝试按照下面的注释跳过islice并使用for循环,例如

for rec in list(next(read1) for _ in xrange(10**5)):

这没有什么大的不同.在单个文件的情况下,为了避免也来自itertools的izip.

我的第二个故障排除想法是检查gzip.open()是否读取文件并将文件扩展到内存,从而在这里引起问题.但是,在解压缩的文件上运行脚本没有什么区别.

解决方法:

请注意,memory_profiler仅报告每行的最大内存消耗.对于长循环,这可能会引起误解,因为循环的第一行似乎总是报告不成比例的内存量.

这是因为它将循环的第一行与之前的那一行的内存消耗进行了比较,而这在循环之外.这并不意味着循环的第一行消耗了2985Mb,而是循环中内存峰值之间的差异比循环外的内存高2985Mb.