del、ガベージコレクションしても開放されない

Question

前提・実現したいこと

メモリを開放したい。

発生している問題

import gc
import pandas as pd

scores = []
for num in range(13):#通貨別にデータを作りそれを通貨別でリストにDFを格納
    
    train = conv_data(train_list[num])
    
    y_train = train['Target']
    X_train = train.drop('Target', axis=1)
    
    del train
    gc.collect()
    #ここでも下と同様、開放してもメモリ使用率が減らない

    cv_score = KFold_learn(categorical_features, X_train, y_train, 'xgboost')
    scores.append(cv_score)

    #ここまでy_trainとX_trainがメモリを多く消費しているのでここでそれを開放する
    del y_train, X_train, cv_score
    gc.collect()
    #この後開放して確かにオブジェクトは消えたがメモリ使用率は変化しない。これを直してしっかり開放させたい。
    """
    import sys
    print("{}{: >25}{}{: >10}{}".format('|','Variable Name','|','Memory','|'))
    print(" ------------------------------------ ")
    for var_name in dir():
        if not var_name.startswith("_"):
            print("{}{: >25}{}{: >10}{}".format('|',var_name,'|',sys.getsizeof(eval(var_name)),'|'))

    で確認すると確かにy_train, X_trainは消せているが、tracemallocを使って確認すると、pandasがメモリを消費しているのがわかる。
    """

補足情報（FW/ツールのバージョンなど）

Jupyter notebook(kaggle notebook), Python3を利用

Comments

[quickquip]

ct の定義がないようです。動いているコードですか?

[NN99]

動いているコードではなく、簡略化したコードです
ctは消すの忘れてました。直します。ありがとうございます。

Answer 1

こういうご質問は時々ありますが、多くの場合OSの動きとメモリ使用量について測定方法に関して理解していない場合が多いです。

• OSの動き(メモリ管理)
  OSが管理するプロセス空間は、execなどを使って全く新しく書き換えない限り割り当てた仮想メモリが減ることはありません。
  ガーベジコレクションは、OSに依頼して割り当てられたメモリを再利用できるようにするだけです。

• メモリ使用量
  メモリ使用量を測定するツールは、プロセスに割り当てられた仮想メモリの量を測定するものと、プロセスの仮想メモリのうち実メモリが割り当てられている量を測定するものがあります。前者はexecなどを行わない限り減少しません。後者は他のプロセスの仮想メモりが多くなると減少することがありますが、それは自身の使うメモリが減ったのとは関係ない場合があります。

なお、CPythonは、参照されなくなったオブジェクトのメモリを自動的に開放していますので、gc.collect()で解放されるのは循環参照されているオブジェクトのメモリだけです。循環参照がなければ、gc.collect()を実行する意味はありません。

Comments

[NN99]

なるほど。勉強不足でした。メモリ管理についてある程度調べましたが、質問内容についてそこで新たな疑問が生まれました。
for文で1回目のループが終わった段階と、2回目のループが段階での確保されているメモリの割合を比較すると2回目のほうが5%程度増えてしまいます。同様に3回目でまた増えてしまいます。
なぜGCされて、再利用することが可能になったメモリにデータを格納せず、新たな領域を確保してしまうのでしょうか？
ついでに、ループが増える毎y_train, X_trainのようなオブジェクトの大きさの増大は計測上ありませんでした。
なにか理解しまちがえていたら申し訳ありません。

[ppaul]

フラグメンテーションのためです。
つまり、freeされてプールに戻ったメモリが、mallocでもっと大きなメモリの要求があったときに利用できないためです。細分化されたメモリをつなぎ合わせる処理は非常に重くなるのでfreeのアルゴリズムでは採用されていないのです。コピー型ガベージコレクションを実装すればそういうメモリをつなぎ合わせることができるのですが、LISP処理系以外で見たことがありません。

[NN99]

なるほど、、となると解決策は一度最初に大きなダミー配列を作りそれでメモリを確保した後GCしていけばいいのでしょうか？て思いやってみましたが、今度はGCした瞬間にメモリの確保されている割合が何故か減ってしまいました...なにが原因かやはりよくわかりませんし、解決策も見いだせません...
ついでにメモリ使用率はpsutil.virtual_memory().percentで計測しています。

[NN99]

原因がわかりました。
listにdfのオブジェクトを格納していたのですが、変数のメモリ消費量を表示するプログラムに表示されないのが原因でコピーでなく、代入になっていることに気づけませんでした。
ついでにいろいろな勉強になりました！ありがとうございます！