使い終わったメモリは、いつOSに戻る？処理後にメモリが減らないとき、何を調べればよいのか

Pythonで小さなデータを80,000個作り、そのうち98%以上の参照を捨てたところ、メモリ使用量がほとんど下がらないケースがありました。

「参照を捨てる」は、変数やリストからデータへのつながりを切る操作です。一方、ガベージコレクション（GC）は、プログラムから使えなくなったデータを回収する仕組みです。ほかの変数やリストからまだ使えるデータは、GCを動かしても回収されません。

残していた参照は、64個に1個だけです。GCを手動で動かしても、使用量はほとんど変わりませんでした。ところが、最後に残した参照も捨てると、使用量は大きく減りました。

大部分のデータを捨てても、GCを呼んでも減らなかったのに、最後の少量を手放すと減る。この結果は、「データを使い終えたこと」と「OSから見えるメモリ使用量が減ること」を分けて考える手がかりになります。

この記事では、このとき何が残っていたのかを4条件の比較から読み解き、処理後にメモリが下がらないとき、何を調べればよいのかにつなげます。

測った指標はRSS（Resident Set Size）です。RSSは、実行中のプログラム（プロセス）に対応するメモリのうち、今、物理メモリ（RAM）に載っている量を表します。Pythonのデータだけでなく、実行コードや共有ライブラリなども含むため、RSSと「まだ生きているPythonのデータ量」は同じものではありません。LinuxのRSSの説明

実験では、参照を捨てるとすぐにRSSも減る場合と、GCで回収するまで残る場合、少量の参照を残したためGCでも減らない場合に分かれました。この違いを、処理後のメモリを調べる順序につなげます。

4条件で、参照を捨てた後のメモリを比べる

使用したのはCPython 3.11.2、Linux 6.12、aarch64、glibc 2.36です。小さな割り当てを管理するPython標準のpymallocを有効にし、次の4条件を比べました。

ここでの256は、bytearrayの中身のバイト数です。オブジェクトの管理領域やリストの分は別に必要なので、80,000×256バイトがRSSの増分になるわけではありません。

各条件を新しいプロセスで3回測り、それぞれの中で2周期繰り返しました。参照を捨てた直後、1秒後、3秒後を記録し、その後にgc.collect()を実行します。少量保持の条件では、最後に残した参照も解放します。

実験で分かったこと：同じ「捨てる」でも戻り方は違う

単位はMiB、各周期の生成前からのRSS増分の中央値です。1 MiBは1,048,576バイト。3プロセス×2周期の6観測をまとめていますが、同じプロセス内の2周期を独立した反復とは扱っていません。

表から分かったのは、データを「捨てた」後に必要な操作が、参照の状態によって違うことです。

• 32 MiBの大きなバッファは、参照を捨てた直後にRSSの増分もほぼ0へ戻りました。小さなバッファも、すべての参照を捨てた条件では大部分が直後に減っています。
• 循環参照では、3秒待っても約30.02 MiBの増分が残り、手動GC後に約0.90 MiBへ減りました。
• 小さなバッファを64個に1個、約1.6%だけ保持すると、GC後も約25.61 MiBの増分が残りました。最後の参照を捨てると約0.45 MiBへ減りました。

「時間がたてば減る」「GCを呼べば減る」と一つの原因で説明することはできませんでした。 とくに、データの98%以上を捨てても、RSSが同じ割合で減るわけではない点が重要です。なぜこうなるのかを、メモリを管理する仕組みから見ていきます。

なぜ違うのか：参照・回収・OSへの返却を分ける

Pythonでオブジェクトが回収されると、そのオブジェクトのために使っていた領域を再利用できるようになります。しかし、割り当てを管理する仕組み（allocator）がその領域を手元に持っていれば、OSから見た常駐メモリはすぐには減りません。Pythonのメモリ管理では、Python内部に複数の割り当て・キャッシュの仕組みがあることが説明されています。

循環参照は、3秒待つだけでは回収されなかった

CPythonには参照カウントによる回収があり、循環参照を見つけるGCがそれを補います。たとえば次のNodeは、自分自身への参照を持っています。

class Node:
    def __init__(self):
        self.link = self
        self.payload = bytearray(256)

nodes = [Node() for _ in range(80_000)]
del nodes  # 外側のリストを消しても、Nodeの自己参照は残る

これは関係を示す簡略例です。測定コードでは、属性用の追加dictを作らない__slots__なども固定しています。

循環参照の条件では、全Nodeを外側のリストで保持したまま一度フルGCを実行し、回収数が0であることを確認しました。この事前GCはオブジェクトの世代も変えます。 その後に外側の参照を捨てると、3秒後もRSSはほぼ変わらず、標本として追った32個も全て生存していました。

手動GCでは毎回80,000個のNodeが回収され、標本は全て消滅しました。RSS増分の中央値も約30.02 MiBから約0.90 MiBへ下がりました。回収数はNodeの個数であり、付随するbytearrayの個数を表しているわけではありません。

自動GCは有効でしたが、参照を捨ててから3秒後までGCイベントは増えませんでした。CPython 3.11の自動GCは割り当てと解放のカウンターを使うので、何秒待ったかだけで回収時刻が決まるわけではありません。この実験も、事前GC後に新しい処理をほぼ行わず待つ条件です。GCの仕様

手動GCにかかった実時間の中央値は146.9 ms、プロセスCPU時間は38.8 msでした。CPUを0.25コアに制限しており、実時間にはCPUを使えず待つ時間も含まれます。この実時間を、本番アプリのGC停止時間として使うことはできません。

約1.6%を残しただけで、なぜ大きな領域が残るのか

少量保持では、80,000個中1,250個をリストに残しました。手動GCは、生きている参照があるオブジェクトを勝手に捨てることはできません。ただし、残したデータ量は全体の約1.6%です。RSSもその程度まで減るように思えますが、今回の観測はそうなりませんでした。

pymallocは512バイト以下の小さな割り当て向けの仕組みで、64ビット環境では1 MiBのアリーナという領域を使います。アリーナの中に、さらに小さな割り当てが入ります。空いたブロックを再利用できることと、アリーナを丸ごと返せることは別です。pymallocの仕様

今回、残りの参照を解放するとRSSも大きく減ったことは、このような領域の残り方と整合します。ただし、全アリーナの配置や別allocatorとの比較は測っていないので、残存RSSの全量を特定の内部構造だけで説明できたわけではありません。

次にメモリが下がらなかったら、この順で確認する

まずは、普段使っているメモリの監視画面と、Pythonのprint()で調べられるところから始めます。開発環境で、処理後のメモリ使用量と、コードが残しているデータの件数を一緒に見ます。

1. 同じ処理を繰り返して、メモリの数字をメモする

OSのプロセス一覧や、普段使うアプリの監視画面で、調べたいPythonのメモリ使用量を開きます。どのプロセスか分からなければ、調べたいPythonコードで次を実行すると、そのプロセスの番号（PID）が分かります。os.getpidの説明

import os
print("このPythonのPID:", os.getpid())

そのPythonを起動したまま、同じ入力・同じ処理量で数回実行し、毎回、処理が終わった直後のメモリ使用量をメモします。「最初に増えた後はほぼ同じ値なのか」「処理のたびに増えるのか」を見ます。毎回Pythonを終了して起動し直すと、それまでにたまったものも消えるため、この比較には混ぜません。数回横ばいだったことだけで、メモリリークがないと確定するわけではありません。

比較には、同じ画面の同じ項目を使います。監視画面の「メモリ」が必ずRSSを意味するとは限らないため、この記事のRSSと絶対値を比べる必要はありません。また、「最大使用量」は過去の最大値なので、処理後に下がるかの確認には使いません。LinuxでRSSを直接読む方法は、後の補足に載せています。

2. 結果をためているリストや辞書の件数を出す

例えば、処理結果をresultsというリストへ追加しているなら、その処理の前後に次を入れます。resultsは自分のコードのリスト名に、run_job()は調べたい処理に置き換えてください。新しく空のリストを作るのではなく、実際に結果をためているものを調べます。

print("処理前の件数:", len(results))
run_job()  # 自分の処理に置き換える
print("処理後の件数:", len(results))

len()は、リストや辞書に入っている要素の数を返します。辞書のcacheへデータを保存しているなら、同じようにlen(cache)を出します。lenの説明

見るのは、使い終わったはずの結果が、処理のたびに追加されて残り続けていないかです。例えば、1回ごとの結果しか使わないのに、過去の結果もリストに追加し続けていたら、その保存が必要かを確認できます。ただし、必要な履歴やキャッシュが増えること自体は異常ではありません。また、件数が同じでも、1件あたりのデータが大きくなれば使用量は増えます。

3. 不要なデータを残していたら直して、同じ条件でもう一度見る

不要な過去の結果を追加し続けない、使い終わった項目をリストから外す、辞書のキャッシュに保持件数や有効期限を設ける、といった変更を検討します。必要なデータまで一括で消すのではなく、何のために残しているかを確認してから直します。

変更前・変更後それぞれで、起動後の初期化を済ませた状態から同じ入力の処理を繰り返します。各回の処理終了直後に、メモリ使用量とリスト・辞書の件数を記録し、「処理のたびに増えていた件数や使用量が、どう変わったか」を比べます。毎回再起動した値どうしで累積増加を判断しないようにします。

今回の実験では、少量でも参照を残している間はGCで変わらず、最後の参照を捨てるとRSSが大きく減りました。ここから持ち帰れるのは、GCを追加する前に、使い終わったデータを自分のリストや辞書が持ち続けていないか確認するという行動です。キャッシュの設計変更による効果まで今回測ったわけではなく、別のアプリでもすぐにRSSが下がると保証するものではありません。

件数に手がかりがない場合は、データ1件の大きさや、ほかの保存先も確認します。それでも増加する場所が分からなければ、次の補足にある詳しい調査へ進みます。件数だけで、すべてのメモリ使用量を説明できるわけではありません。

今回の実験は2周期だけで、途中にGCとtrimも入ります。長期のリーク検出、自然に放置したときの収束、手動GCやtrimを毎リクエスト呼ぶ対策の有効性は検証していません。

import tracemalloc

tracemalloc.start()
before = tracemalloc.take_snapshot()

run_same_job()  # 調べたい処理を実行する

after = tracemalloc.take_snapshot()
changes = after.compare_to(before, "lineno")
increases = [change for change in changes if change.size_diff > 0]
for change in increases[:10]:
    print(change)

pid=12345  # 調べるプロセスのPIDへ置き換える
cat "/proc/$pid/smaps_rollup"

結論：処理後もメモリが高いなら、まずデータをためていないか確認する

今回の実験では、データを98%以上捨てても、少量の参照が残っている間はGCを動かしてもRSSがほとんど減りませんでした。最後の参照も捨てると、大きく減りました。

Pythonのアプリで同じようにメモリが下がらないときは、まず次の3つを試します。

1. 同じPythonを起動したまま同じ処理を繰り返し、終了直後のメモリ使用量をメモする。 普段の監視画面の同じ項目で、毎回増えるかを見ます。
2. 結果をためるリストや辞書の件数を、処理の前後にprint(len(...))で出す。 使い終わったデータが、処理のたびに残り続けていないかを確かめます。
3. 不要な保存を見つけたら直し、同じ条件でもう一度比べる。 件数とメモリ使用量の増え方がどう変わったかを見ます。

最初の「メモリが減らないとき、何を調べればよいのか」への答えは、処理後の数字を繰り返し記録し、使い終わったデータを入れたままのリストや辞書がないか調べることです。すぐにメモリ使用量が下がらなくても、それだけで修正の失敗とは言えません。件数に手がかりがない場合や、修正後も増加が続く場合は、補足の詳しい調査へ進みます。

KamuiDashについて

KamuiDashは、GitHubからWebアプリをデプロイできる、日本リージョン対応のPaaSです。