Почему я теряю память с этим циклом Python?

Question

Я пишу специальный сканер файловой системы, который передается миллионам глобусов для обработки через sys.stdin. Я обнаружил, что при запуске скрипта его использование памяти со временем значительно увеличивается, и все это практически останавливается. Я написал минимальный случай ниже, который показывает проблему. Я делаю что-то не так, или я нашел ошибку в Python / модуле glob? (Я использую Python 2.5.2).

#!/usr/bin/env python
import glob
import sys
import gc

previous_num_objects = 0

for count, line in enumerate(sys.stdin):
   glob_result = glob.glob(line.rstrip('\n'))
   current_num_objects = len(gc.get_objects())
   new_objects = current_num_objects - previous_num_objects

   print "(%d) This: %d, New: %d, Garbage: %d, Collection Counts: %s"\
 % (count, current_num_objects, new_objects, len(gc.garbage), gc.get_count())
   previous_num_objects = current_num_objects

Вывод выглядит так:

(0) This: 4042, New: 4042, Python Garbage: 0, Python Collection Counts: (660, 5, 0)
(1) This: 4061, New: 19, Python Garbage: 0, Python Collection Counts: (90, 6, 0)
(2) This: 4064, New: 3, Python Garbage: 0, Python Collection Counts: (127, 6, 0)
(3) This: 4067, New: 3, Python Garbage: 0, Python Collection Counts: (130, 6, 0)
(4) This: 4070, New: 3, Python Garbage: 0, Python Collection Counts: (133, 6, 0)
(5) This: 4073, New: 3, Python Garbage: 0, Python Collection Counts: (136, 6, 0)
(6) This: 4076, New: 3, Python Garbage: 0, Python Collection Counts: (139, 6, 0)
(7) This: 4079, New: 3, Python Garbage: 0, Python Collection Counts: (142, 6, 0)
(8) This: 4082, New: 3, Python Garbage: 0, Python Collection Counts: (145, 6, 0)
(9) This: 4085, New: 3, Python Garbage: 0, Python Collection Counts: (148, 6, 0)

Каждая сотая итерация освобождает 100 объектов, поэтому len(gc.get_objects() увеличивается на 200 каждые 100 итераций. len(gc.garbage) никогда не меняется с 0. Количество коллекций 2-го поколения медленно увеличивается, в то время как счетчики 0-го и 1-го увеличиваются и уменьшаются.

Answer 1

Я отследил это до модуля fnmatch. glob.glob вызывает fnmatch, чтобы фактически выполнить глобализацию, а fnmatch имеет кеш регулярных выражений, который никогда не очищается. Таким образом, при таком использовании кэш непрерывно рос и не контролировался. Я подал ошибку в библиотеку fnmatch [1].

[1]: http://bugs.python.org/issue7846 Python Bug

Answer 2

Я не могу воспроизвести какую-либо фактическую утечку в моей системе, но я думаю, что ваша «каждая сотая итерация, 100 объектов освобождаются» - это вы попадаете в кэш для скомпилированных регулярных выражений (через модуль glob).Если вы посмотрите на re.py, вы увидите, что _MAXCACHE по умолчанию равно 100, и по умолчанию весь кэш сдувается, когда вы его нажмете (в _compile).Если вы позвоните re.purge() до ваших gc звонков, вы, вероятно, увидите, что этот эффект исчезнет.

(обратите внимание, я предлагаю только re.purge() здесь, чтобы проверить, что кеш влияет на ваши результаты gc.не обязательно иметь это в своем фактическом коде.)

Я сомневаюсь, что это решает проблему вашего большого увеличения памяти.