2012-08-03 10 views
9

私は、時には数百メガバイトの大きさのファイルを読み込み、処理して書き込むためにpythonを使用するプロジェクトに取り組んでいます。特に大きいファイルを処理しようとすると、プログラムが失敗することがあります。それは 'メモリエラー'とは言いませんが、それが問題だと思っています(実際には失敗する理由は全くありません)。なぜ私のpythonプロセスは非常に多くのメモリを使い果たしますか?

私は小規模なファイルでコードをテストしていて、メモリの使用状況を確認するために「トップ」を見ており、通常は60%に達しています。私は4050352k総メモリを持っているので、3.8Gbです。

一方、私は次のコードを少しで(yesterdayから私の質問を参照)のpython自体内のメモリの使用状況を追跡しようとしている:

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) 

私は私が着るすべての変数を設定し、そのブロックを実行する前にNoneにする必要はありません。すべてのファイルと図形を閉じます。ブロックの後に、次の処理段階で必要となるfortranプログラムを実行するためにsubprocess.call()を使います。 Fortranプログラムが稼動している最中に、FortranプログラムがCPUの100%、メモリの5%を使用しており、そのPythonがCPUの0%とメモリの53%を使用していることがわかります。しかし私の少しのコードスニペットでは、Pythonのすべての変数は23Mbにしかならないことがわかりました。これは〜0.5%であるべきです。

何が起こっているのですか?私はその小さなスニペットが私にメモリ使用量のスポットを与えるとは思っていませんが、確かに数MB以内に正確であるべきですか?それとも、メモリが放棄されたことにトップが気づいていないのですが、必要であればそれを必要とする他のプログラムで利用できるのでしょうか?

ここでは、すべてのメモリを使用しているコードの簡単な部分を示します(file_name.cubはISIS3キューブです。同じマップの5つのレイヤ(バンド)を含むファイルです)。最初のレイヤはスペクトル輝き、次の4つは緯度、経度、その他の詳細と関係があります。これは、私が処理しようとしている火星の画像です。StartByteは、以前に.cubファイルのASCIIヘッダから読み込んだ値です。データ、サンプルおよびラインもヘッダから読み出した地図の大きさ、です):。

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 

だから私はそれが同じファイルの多くの事例ですが、いくつかのファイルを開くことについてのコメントで嘘をつきました。私はNoneに設定されていない配列を1つだけ続けます。サイズは〜830x4000ですが、これは何らかの形で利用可能なメモリの50%を占めます。私もgc.c​​ollectを試しましたが、変更はありません。私はどのようなコード(この問題に関連するかそうではないか)についてどのように改善できるかについてのアドバイスを聞いて非常にうれしいです。

おそらく言及する必要があります:もともと私は完全にファイルを開いていました(つまり、上記のように行単位ではなく)、行単位で行えば、メモリを節約するための初期の試みでした。

+0

長時間実行されているプロセスでnumpyを使用して同様の問題が発生しました。ふるい分けのようなリークや、他のようなヒープの断片化があります。たくさんの配列を作成してそれらを破壊していますか? –

+3

Pythonは、あるオブジェクトインスタンスが破棄された直後にメモリを解放しません。アリーナと呼ばれるいくつかのオブジェクトプールがあり、それらが解放されるまでに時間がかかります。場合によっては、メモリの断片化に悩まされている可能性もあり、プロセスのメモリ使用量が増加します。 – C2H5OH

+1

'sys.getsizeof()'はメモリ使用量をテストする信頼できる方法ではありません。まず、特定のPythonオブジェクトのメモリだけを追跡し、メモリ内の他のアイテムに対する参照は追跡しません。第二に、ドキュメントによると、サードパーティの拡張機能で正しく動作することは保証されていません。また、@ C2H5OHは言った。 –

答えて

9

変数を参照しただけでも、割り当てられたメモリがシステムに返されたということではありません。 How can I explicitly free memory in Python?を参照してください。

更新

gc.collectは()あなたのために動作しない場合は、フォークとを調査読み取り/ IPCを使用して子プロセスであなたのファイルを書き込みます。これらのプロセスは終了し、メモリをシステムに戻します。主プロセスは、メモリ使用量が少なくても実行されます。

+0

ありがとうございました。そのリンクは有益でした。 gc.collectは効果がありませんでした。フォークについてもう少し説明できますか? "os.waitpid(0,0)/ newpid = os.fork()/ if newpid == 0:"内部でコードを上に置くことはできますか? – EddyTheB

+0

明示的に分岐する代わりにサブプロセスモジュールを使用することができれば、それが通常より優れています。しかし基本的な考え方は、たとえ1GBのメモリが必要な4つのタスク(たとえ短くても必要な場合でも)、それぞれが1GBを使用する4つの独立した子プロセスと、 4GBとクラッシュは良いことです。 (これは64ビットOSでは必ずしも当てはまりません。特に、OSメモリ空間ではなく、システムRAM +スワップ領域またはページ領域外であるためクラッシュする場合がありますが、それはわかります) – abarnert

+0

@EddyTheB:それは正しい考えかもしれません。サブプロセスモジュールも適切な場合があります。しかし、どちらの場合でも、プロセス間でデータを共有する簡単な方法がないことを理解していることを前提としています。あなたが読んで、処理しているので、あなたが必要とするように聞こえます。 – bioneuralnet

関連する問題