Windows環境におけるPythonのメモリリークについて

Question

ソースコード

全文は長いので該当行のみ。
import漏れは補完いただけると幸いです。

import cv2
import gc
class Region:
	def __init__(self, x, y, width, height):
		self.X = x
		self.Y = y
		self.Width = width
		self.Height = height

	def size(self):
		return (self.Width, self.Height)
	def width(self):
		return self.Width
	def height(self):
		return self.Height

	def left(self):
		return self.X
	def right(self):
		return self.X + self.Width
	def top(self):
		return self.Y
	def bottom(self):
		return self.Y + self.Height

class SubImage:
	_image_cache = ('', None)
	def __init__(self, ID, image_prefix, region):
		self.ID = ID
		self.image_filename = image_prefix + '.jpg'
		self.region = region

	def get_image(self):
		image = None
		if self.image_filename == Target._image_cache[0]:
			image = SubImage._image_cache[1]
		else:
			image = cv2.imread(self.image_filename))
			#del Target._image_cache
			#gc.collect()
			SubImage._image_cache = (self.image_filename, image)
		return image[self.region.top():self.region.bottom(), self.region.left():self.region.right(), :]

	@staticmethod
	def deleteCache():
		#del Target._image_cache
		#gc.collect()
		SubImage._image_cache = ('', None)
    

疑問点

Pythonで大量の部分画像を生成しようとすると異常にメモリを消費してしまう。
コメントアウトしている以下の2文を追加するとこのメモリ消費が収まるが、どうして手動による解放が必要なのか理解できない。
ガーベジコレクションで自動解法されないのでしょうか？

メモリの消費についてより具体的に述べると、8000枚ほどの画像から5万枚の部分画像が必要な場合手動によるメモリ解放を行わない場合35.2GBのメモリを消費するのに対して、手動によるメモリ解放を行った場合16GBしか消費しない。

#コードについての補足
以下のようなデータベースから画像と部分画像を生成しようとしています。

画像のID	画像ファイル名（拡張子なし）	部分画像のx座標	部分画像のy座標	部分画像の幅	部分画像の高さ
ID1	ファイル名1	x11	y11	w11	h13
ID2	ファイル名1	x12	y12	w12	h13
ID3	ファイル名1	x13	y13	w13	h13
ID4	ファイル名2	x21	y21	w21	h21
ID5	ファイル名2	x22	y22	w22	h22

実際にこれを読み込んで

img = SubImage(ID1, ファイル名1, Region(x11, y11, w11, h11))
sub_image = img.get_image()

みたいにして使います。

#補足情報(言語/FW/ツール等のバージョンなど)
Windows環境

• Windows 8.1/10
• Python 3.6.2
• OpenCV 3.2
• numpy 1.11

よろしくお願いします。

Answer 1

この問題は少し厄介ですね。説明が伝わるかわからないのですが、
OpenCVはPythonのライブラリではなく、C++で書かれたライブラリをラップしたライブラリです。ラッパーライブラリはうまくGCが働かなかったり、GCが効き過ぎたりとメモリで苦労することが多いです。

解決策としては、

1. OpenCVを使わない
2. 明示的にGC,あるいはdel

だと思います。

OpenCV以外のPythonで直接画像を扱うライブラリとしては、scikit-image などがあります。
sckit-imageの画像は numpy形式ですから、部分画像（質問のRegionの部分）はスライスで取り出してください。

Comments

[elda]

ご回答ありがとうございます。
Python版のOpenCVでは画像のインタフェースとしてcv::Matではなくnumpy.ndarrayを用いています。
また、numpyは内部でC言語のライブラリを用いているため、貴方の仰るとおりであるならば、scikit-imageやnumpyを用いることは解決策にはなりませんね。

[MasashiKimura]

あら、どうやらswigの問題と勘違いしました。

[MasashiKimura]

では、単純にここに載っていないコードから参照があったり、循環参照していたりするのではないでしょうか？

[MasashiKimura]

はたまた、あるいは、
https://github.com/opencv/opencv/issues?utf8=✓&q=is%3Aissue is%3Aopen memory leak
これらのどれかを踏んでいるのかもですね。

[elda]

ご回答ありがとうございます。
ここに載っていないコードからSubImage._image_cacheにアクセスすることはありません。
また、githubのissueを確認しましたが、該当するメソッドは使用していませんでした。

Answer 2

そちらの環境を完全に再現することができないので、推測が入ります。
（提示されたコードがすべてではありませんよね？）

GCが行われない理由として考えられる事は以下の点です。

• Target._image_cacheがどこかで参照されている
• 循環参照を起こしている
• C拡張部分のメモリリーク

gc.get_referrersで、他のオブジェクトから参照が取れます。
手動でGC解放を行っている部分でTarget._image_cacheが他から参照されていないか確認してください。
どうしても、他から参照する必要があるのであればweakrefモジュールで弱参照してください。

自分の記事で申し訳ありませんが、weakrefモジュールの使い方は以下の記事を参考にしてください。

http://qiita.com/pashango2/items/fb1e5e79589279c5a861

また、循環参照を起こしている場合ですが、PythonのGCでは循環参照オブジェクトでも解放可能です。

http://atsuoishimoto.hatenablog.com/entry/2013/12/06/000000

しかし、循環参照されたオブジェクトに__del__が設定されている場合は、リークする場合があります。
循環参照を起こしている場合、_image_cacheが__del__が定義されていないかを確認してください。

C拡張のメモリリークについては、ちょっと分かりかねます。
そこはOpenCVのバグの領域になりますので・・・

しかし、コードから推測するに、上記の２つなのではないかと思います。

Comments

[elda]

ご回答ありがとうございます。
メモリ解放の前後でget_referrersを用いて参照しているオブジェクトのリストを取得しようとしたので取得したオブジェクトは全てdict型のオブジェクトでした。（つまりgc.collectとdelを使ってもリファレンスは変わっていない）
具体的な中身としてはSubImageクラスのメソッドとクラス変数とその値がペアになったディクショナリでした。

[pashango2]

つまり、他に強参照はなかったという事でしょうか？

気になるのは、解放に2行のコードがありますよね？

#del Target._image_cache
#gc.collect()

gc.collect()のみだとメモリ使用量は変わるのでしょうか？
変わらない場合は、どこかで強参照されている可能性が高いです。

[elda]

gc.collect()のみでメモリが開放されているようです。
これは、どこでも強参照されていないという認識で正しいのでしょうか？

[pashango2]

gc.collect()のみでリーク？が改善された場合は、リークではなくGCの解放タイミングの違いということになります。

[elda]

gcの開放タイミングの違いですか
ということは今回のケースでは手動で開放するべきということでよろしいのでしょうか？

[pashango2]

いえ、GC的には余裕があるから解放していないだけです。
宿題は夏休み最後にやるタイプです、GCが高負荷になるタイミングを手動で調整したいなら手動で解放するべきです。