2014-04-29 10 views
17

Pracuję nad jakąś usługą systemową (w rzeczywistości to tylko analizator dziennika) napisaną w języku Python. Ten program powinien działać nieprzerwanie przez długi czas (mam nadzieję, że mam na myśli dni i tygodnie bez awarii i potrzeby ponownego uruchomienia). Właśnie dlatego martwię się o zużycie pamięci.Zużycie pamięci Pythona w systemie Linux: pamięć fizyczna i wirtualna rośnie, podczas gdy rozmiar sterty pozostaje ten sam

ułożyła różne informacje na temat użycia pamięci proces z różnych stron na jednej prostej funkcji:

#!/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])) 

Funkcja ta została wykorzystana do badania dynamiki konsumpcji pamięci mojego procesu długo-playing, a ja wciąż nie potrafi wyjaśnić swojego zachowania. Możesz zobaczyć, że rozmiar sterty i całkowita ilość obiektów nie uległy zmianie, podczas gdy pamięć fizyczna i wirtualna wzrosły o 11% i 1% podczas tych dwudziestu minut.

UPD: Proces ten trwa od prawie 15 godzin. Sterty nadal są takie same, ale pamięć fizyczna wzrosła sześciokrotnie, a pamięć wirtualna wzrosła o 50%. Krzywa jest wydaje się być liniowy wyjątkiem dziwne odstających o 3:00 AM:

Czas Obj Heap phm VM

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

Zastanawiam się, co się dzieje z przestrzenią adresową mojego procesu. Stała wielkość sterty sugeruje, że wszystkie dynamiczne obiekty są poprawnie przydzielone. Ale nie mam wątpliwości, że rosnące zużycie pamięci wpłynie na trwałość tego krytycznego dla życia procesu na dłuższą metę.

enter image description here

Czy ktoś może wyjaśnić ten problem proszę? Dziękuję Ci.

(używam RHEL 6.4, jądro 2.6.32-358 z Python 2.6.6)

+4

Jak wygląda wykres po uruchomieniu przez kilka godzin zamiast 20 minut – 2rs2ts

+0

Och, prawdopodobnie związane:. http://stackoverflow.com/q/1194416/691859 – 2rs2ts

+0

@ 2rs2ts, dzięki za odpowiedź ja Zaktualizuję wykres jutro, kiedy przyjdę do pracy :) –

Odpowiedz

5

nie wiedząc, co program robi, to może pomóc.

natknąłem się na ten artykuł podczas pracy nad projektem, natomiast tył: http://chase-seibert.github.io/blog/2013/08/03/diagnosing-memory-leaks-python.html który mówi: „Niech uruchomiony pracy Pythona, które zużywają dużo pamięci podczas pracy nie może powrócić tej pamięci do systemu operacyjnego dopóki proces faktycznie kończy się, nawet jeśli wszystko jest poprawnie zebrane."

skończyło się za pomocą modułu Multiprocessing mieć mój projekt widelec osobny proces i wrócić, kiedy potrzebne do pracy, a ja nie zauważyłem żadnych problemów z pamięcią, ponieważ.

To albo spróbować go w Pythonie 3,3 http://bugs.python.org/issue11849

+0

Niestety, biblioteka, z której korzystam (auparse - idzie z auditd w systemie Linux) nadal nie jest przeniesiona do trzeciej gałęzi. –

+0

@ user3588162: To zadziałało dla mnie. Dzięki za tonę. – Prateek

Powiązane problemy