2014-04-29 2 views
17

Я работаю над каким-то системным сервисом (на самом деле это всего лишь анализатор журнала), написанным на Python. Эта программа должна работать непрерывно в течение длительного времени (надеюсь, я имею в виду дни и недели без сбоев и необходимости перезапуска). Вот почему меня беспокоит потребление памяти.Потребление памяти Python в Linux: физическая и виртуальная память растут, а размер кучи остается неизменным

я собрал различную информацию об использовании памяти процесса с различных сайтов в одну простую функцию:

#!/usr/bin/env python 
from pprint import pprint 
from guppy import hpy 
from datetime import datetime 
import sys 
import os 
import resource 
import re 

def debug_memory_leak(): 
    #Getting virtual memory size 
    pid = os.getpid() 
    with open(os.path.join("/proc", str(pid), "status")) as f: 
     lines = f.readlines() 
    _vmsize = [l for l in lines if l.startswith("VmSize")][0] 
    vmsize = int(_vmsize.split()[1]) 

    #Getting physical memory size 
    pmsize = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss 

    #Analyzing the dynamical memory segment - total number of objects in memory and heap size 
    h = hpy().heap() 
    if __debug__: 
     print str(h) 
    m = re.match(
     "Partition of a set of ([0-9]+) objects. Total size = ([0-9]+) bytes(.*)", str(h)) 
    objects = m.group(1) 
    heap = int(m.group(2))/1024 #to Kb 

    current_time = datetime.now().strftime("%H:%M:%S") 
    data = (current_time, objects, heap, pmsize, vmsize) 
    print("\t".join([str(d) for d in data])) 

Эта функция была использована для изучения динамики потребления памяти моего процесса долгоиграющего, и я все еще не может объяснить свое поведение. Вы можете видеть, что размер кучи и общее количество объектов не изменились, в то время как физическая и виртуальная память увеличились на 11% и 1% за эти двадцать минут.

UPD: Этот процесс работает уже почти 15 часов. Куча все тот же, но физическая память увеличилась в шесть раз, а виртуальная память увеличилась на 50%. Кривая, кажется, быть линейным за исключением странные выбросы в 3:00 AM:

Время Obj Heap PhM В.М.

19:04:19 31424 3928 5460 143732

19:04:29 30582 3704 10276 158240

19:04:39 30582 3704 10372 157772

19:04:50 30582 3709 10372 157772

19:05:00 30582 3704 10372 157772

(...)

19:25:00 30583 3704 11524 159900

09:53:23 30581 3704 62380 210756

Интересно, что происходит с адресным пространством моего процесса. Постоянный размер кучи предполагает, что все динамические объекты освобождены правильно. Но я не сомневаюсь, что растущее потребление памяти повлияет на устойчивость этого жизненно важного процесса в долгосрочной перспективе.

enter image description here

Может кто-нибудь прояснить этот вопрос, пожалуйста? Спасибо.

(я использую RHEL 6.4, ядро ​​2.6.32-358 с Python 2.6.6)

+4

Как картографический вид при запуске в течение нескольких часов, а не 20 минут – 2rs2ts

+0

о, возможно, связанно:. http://stackoverflow.com/q/1194416/691859 – 2rs2ts

+0

@ 2rs2ts, спасибо за ваш ответ я завтра я буду обновлять график, когда приеду на работу :) –

ответ

5

Не зная, что делает ваша программа, это может помочь.

Я наткнулся на эту статью при работе над проектом некоторого время назад: http://chase-seibert.github.io/blog/2013/08/03/diagnosing-memory-leaks-python.html Который говорит: «Да выполнение заданий Python, которые потребляют много памяти во время бега не может вернуть эту память для операционной системы до процесса на самом деле заканчивается, даже если все правильно собрано мусором."

Я закончил с использованием модуля многопроцессорной, чтобы мой проект вилы отдельный процесс и вернуться, когда это необходимо, чтобы сделать работу, и я не заметил каких-либо проблем с памятью, так как.

Это или попробовать его в Python 3,3 http://bugs.python.org/issue11849

+0

К сожалению, библиотека, которую я использую (auparse - идет с аудитом в Linux) по-прежнему не переносится в 3-й ветвь. –

+0

@ user3588162: Это сработало для меня. Спасибо тонны. – Prateek