2016-04-18 14 views
2

私は私のマシン上で持っている驚くべきことに、それはすべて、16 GBを消費し、64ビットのXubuntu 14.04 LTSとPython 2.7.6のPython 2.7.6およびマルチプロセッシング「メモリをリーク」

import numpy 
import multiprocessing 

def f(i): 
    result = numpy.zeros((224, 244, 3), dtype='float32') 
    return result 

if __name__ == '__main__': 
    print 'Start...' 

    for i in xrange(100): 

     print 'Attempt:', i 

     args = [0] * 1000 
     pool = multiprocessing.Pool(8) 
     v = pool.map(f, args) 

     print 'Pool done.' 

     import gc 
     gc.collect() 
     del v 
     v = None 

     print 'Clean done.' 

に次のコードを実行していますよ繰り返しはほとんどありません。それはシステムを完全に凍らせた。私が理解する限りでは、 "v"はローカルリソースであり、割り当てを解除することができるため、これは起こりません。

なぜこの「メモリリーク」が実際に起こるのですか?

マルチプロセッシング・バージョンは、numpyの0.70a1である - クリーニング部でpool.close()を呼び出す1.10.4

答えて

0

は、明示的にガベージコレクタに頼る必要なしにメモリリークを修正するのに十分です。なぜ起こるのかは分かりませんが、確かにhow the pool is implementedに依存しています(ほとんどの場合、結果の参照をどこかに保持しています)

+0

Wow。 Pool.close()は実際に動作します!どうもありがとう! – tinnulion

+2

それに追加するには:それは問題ではなく、プール自体である 'v'のように見えます。 'Pool .__ init __()'は、バックグラウンドスレッドを含む非常に少数のサブオブジェクトに 'self'をプッシュします。したがって、 'プール'は参照カウントによって直接クリーンアップされません。このプールは、GCの観点から見ても奇妙なオブジェクトです。ローカルメモリのフットプリントは比較的小さいですが、付属のサブプロセスはシステム上重いです。しかし、メインプロセスのGCはほとんど実行されません。なぜなら、メインプロセスにはほとんどメモリがないからです。各ループに(ローカルに)わずかなオブジェクトしか作成していません。 – dhke

+0

@dhke明確化のためにありがとう! – BlackBear

関連する問題