Как найти утечку памяти python

Время на прочтение
7 мин

Количество просмотров 19K

Практика показывает, что в современном мире Docker-контейнеров и оркестраторов (Kubernetes, Nomad, etc) проблема с утечкой памяти может быть обнаружена не при локальной разработке, а в ходе нагрузочного тестирования, или даже в production-среде. В этой статье рассмотрим:

• Причины появления утечек в Python-приложениях.

• Доступные инструменты для отладки и мониторинга работающего приложения.

• Общую методику поиска утечек памяти.

У нас есть много фреймворков и технологий, которые уже «из коробки» работают замечательно, что усыпляет бдительность. В итоге иногда тревога поднимается спустя некоторое время после проблемного релиза, когда на мониторинге появляется примерно такая картина:

Утечки плохи не только тем, что приложение начинает потреблять больше памяти. С большой вероятностью также будет наблюдаться снижение работоспособности, потому что GC придется обрабатывать всё больше и больше объектов, а аллокатору Python — чаще выделять память для новых объектов.

Заранее предупрежу, что рассмотренные методы отладки приложения крайне не рекомендованы для использования в production-среде. Область их применения сводится к ситуациям:

• Есть подозрение на утечку памяти. Причина абсолютно непонятна и проявляется при production-сценариях/нагрузках.

• Мы разворачиваем приложение в тестовой среде и даем тестовый трафик, аналогичный тому, при котором появляется утечка.

• Смотрим, какие объекты создаются, и почему память не отдается операционной системе.

Глобально утечка может произойти в следующих местах:

• Код на Python. Здесь всё просто: создаются объекты в куче, которые не могут быть удалены из-за наличия ссылок.

• Подключаемые библиотеки на других языках (C/C++, Rust, etc). Утечку в сторонних библиотеках искать гораздо сложнее, чем в коде на Python. Но методика есть, и мы ее рассмотрим.

• Интерпретатор Python. Эти случаи редки, но возможны. Их стоит рассматривать, если остальные методы диагностики не дали результата.

Подключение к работающему приложению

1. PDB — старый добрый Python Debugger, о котором стали забывать из-за красивого интерфейса для отладки в современных IDE. На мой взгляд, для поиска утечек памяти крайне неудобен.

2. aiomonitor. Отличное решение для асинхронных приложений. Запускается в отдельной корутине и позволяет подключиться к работающему приложению с помощью NetCat. Предоставляет доступ к полноценному интерпретатору без блокировки основного приложения.

3. pyrasite. Запускается в отдельном процессе, и также как aiomonitor не блокирует и не останавливает основной поток, — можно смотреть текущее состояние переменных и памяти. Для работы pyrasite требуется установленный gdb. Это накладывает ограничения на использование, например, в Docker — требуется запуск контейнера с привилегированными правами и включение ptrace.

Утечки памяти: большие объекты

Это самые простые утечки памяти, потому что большие объекты очень легко отфильтровать. Для поиска будем использовать pympler и отладку через aiomonitor. 

Запустим в первом окне терминала main.py:

import tracemalloc

tracemalloc.start()

from aiohttp import web
import asyncio
import random
import logging
import sys
import aiomonitor


logger = logging.getLogger(__name__)


async def leaking(app):
    """
    Стартап утекающей корутины
    """

    stop = asyncio.Event()

    async def leaking_coro():
        """
        Утекающая корутина
        """
        data = []
        i = 0

        logger.info('Leaking: start')

        while not stop.is_set():
            i += 1
            try:
                return await asyncio.wait_for(stop.wait(), timeout=1)
            except asyncio.TimeoutError:
                pass
            # ЗДЕСЬ БУДЕМ УТЕКАТЬ!
            data.append('hi' * random.randint(10_000, 20_000))
            if i % 2 == 0:
                logger.info('Current size = %s', sys.getsizeof(data))

    leaking_future = asyncio.ensure_future(asyncio.shield(leaking_coro()))
    yield
    stop.set()

if __name__ == '__main__':
    logging.basicConfig(level=logging.INFO)
    loop = asyncio.get_event_loop()

    with aiomonitor.start_monitor(loop=loop):
        app = web.Application()
        app.cleanup_ctx.append(leaking)
        web.run_app(app, port=8000)

И подключимся к нему во втором:

nc 127.0.0.1 50101                                                                                                         

Asyncio Monitor: 2 tasks running
Type help for available commands

monitor >>> console

Нас интересует отсортированный дамп объектов GC:

>>> from pympler import muppy
>>> all_objects = muppy.get_objects()
>>> top_10 = muppy.sort(all_objects)[-10:]
>>> top1 = top_10[0]

Мы можем убедиться, что самым большим объектом является наша добавляемая строка:

>>> type(top1)
<class 'str'>

Забавный факт: вызов pprint выводит информацию не в терминальную сессию aiomonitor, а в исходный скрипт. В то время как обычный print ведет себя наоборот.

Теперь возникает вопрос: как же понять, где этот объект был создан? Вы наверняка заметили запуск tracemalloc в самом начале файла, — он нам и поможет:

>>> import  tracemalloc
>>> tb = tracemalloc.get_object_traceback(top1)
>>> tb.format()
['  File "main.py", line 41', "    data.append('hi' * random.randint(10_000, 20_000))"]

Просто и изящно! Для корректной работы tracemalloc должен быть запущен перед любыми другими импортами и командами. Также его можно запустить с помощью флага -X tracemalloc или установки переменной окружения PYTHONTRACEMALLOC=1 (подробнее: https://docs.python.org/3/library/tracemalloc.html). Чуть ниже мы рассмотрим другие полезные функции tracemalloc.

Утечки памяти: много маленьких объектов

Представим, что в нашей программе начал утекать бесконечный связный список: много однотипных маленьких объектов. Попробуем отыскать утечку такого рода.

import tracemalloc

tracemalloc.start()

import asyncio

root = {
    'prev': None,
    'next': None,
    'id': 0
}


async def leaking_func():
    current = root
    n = 0

    while True:

        n += 1

        _next = {
            'prev': current,
            'next': None,
            'id': n
        }
        current['next'] = _next
        current = _next

        await asyncio.sleep(0.1)

if __name__ == '__main__':
    loop = asyncio.get_event_loop()
    with aiomonitor.start_monitor(loop=loop):
        loop.run_until_complete(leaking_func())

Как и в прошлом примере, подключимся к работающему приложению, но для поиска маленьких объектов будем использовать objgraph:

>>> import objgraph
>>> objgraph.show_growth()

function                       6790     +6790
dict                           3559     +3559
tuple                          2676     +2676
list                           2246     +2246
weakref                        1635     +1635
wrapper_descriptor             1283     +1283
getset_descriptor              1150     +1150
method_descriptor              1128     +1128
builtin_function_or_method     1103     +1103
type                            949      +949

Во время первого запуск objgraph посчитает все объекты в куче. Дальнейшие вызовы будут показывать только новые объекты. Попробуем вызвать еще раз:

>>> objgraph.show_growth()
dict     3642       +30

Итак, у нас создается и не удаляется много новых маленьких объектов. Ситуацию усложняет то, что эти объекты имеют очень распространенный тип dict. Вызовем несколько раз функцию get_new_ids с небольшим интервалом:

>>> items = objgraph.get_new_ids()['dict']
>>> # Ждем некоторое время
>>> items = objgraph.get_new_ids()['dict']
>>> items
{4381574400, 4381574720, 4380522368, … }

Посмотрим на созданные объекты более пристально:

>>> from pprint import pprint
>>> # Получим объекты по их id
>>> objects = objgraph.at_addrs(items)
>>> pprint(objects, depth=2)

[{'id': 1077, 'next': {...}, 'prev': {...}},
 {'id': 864, 'next': {...}, 'prev': {...}},
 {'id': 865, 'next': {...}, 'prev': {...}},
 {'id': 866, 'next': {...}, 'prev': {...}},
…]

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

def take_snapshot(prev=None, limit=10):

    res = tracemalloc.take_snapshot()
    res = res.filter_traces([
        tracemalloc.Filter(False, tracemalloc.__file__),
    ])

    if prev is None:
        return res

    st = res.compare_to(prev, 'lineno')
    for stat in st[:limit]:
        print(stat)

    return res

>>> sn = take_snapshot()
>>> # Немного подождем перед вторым вызовом
>>> sn = take_snapshot(sn):

/Users/saborisov/Work/debug_memory_leak/main.py:25 size=27.8 KiB (+27.8 KiB), count=230 (+230), average=124 B
...

Мы явно видим подозрительное место, на которое следует взглянуть более пристально.

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

Сторонние C-Extensions

Это наиболее тяжелый в расследовании тип утечек памяти, потому что GC работает только с PyObject. Если утекает код на C, отследить это с помощью кода на Python невозможно. Искать утечки в сторонних библиотеках следует, если:

• Основная куча объектов Python не растет (с помощью objgraph и pympler не удается найти утечки памяти).

• Общая память приложения на Python продолжает бесконтрольно расти.

Для тестирования создадим небольшой модуль на Cython (cython_leak.pyx):

from libc.stdlib cimport malloc

cdef class PySquareArray:
    cdef int *_thisptr
    cdef int _size

    def __cinit__(self, int n):
        # Класс, который создает массив квадратов заданного размера
        cdef int i
        self._size = n

        self._thisptr = <int*>malloc(n * sizeof(int))
        for i in range(n):
            self._thisptr[i] = i * i

    def __iter__(self):
        cdef int i
        for i in range(self._size):
            yield self._thisptr[i]

И установочный файл (setup.py):

from setuptools import setup
from Cython.Build import cythonize

setup(
    name='Hello world app',
    ext_modules=cythonize("cython_leak.pyx"),
    zip_safe=False,
)

Запустим сборку: python setup.py build_ext --inplace

И сделаем скрипт для тестирования утечки (test_cython_leak.py):

from cython_leak import PySquareArray
import random

while True:
    a = PySquareArray(random.randint(10000, 20000))
    for v in a:
        pass

Кажется, все объекты должны корректно создаваться и удаляться. На практике график работы скрипта выглядит примерно так:

Попробуем разобраться в причине с помощью Valgrind. Для этого нам понадобится suppression-файл и отключение Python-аллокатора:

PYTHONMALLOC=malloc valgrind --tool=memcheck --leak-check=full python3 test_cython_leak.py

После некоторого времени работы можно посмотреть отчет (нас интересуют блоки definitely lost):

==4765== 79,440 bytes in 1 blocks are definitely lost in loss record 3,351 of 3,352
==4765==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==4765==    by 0x544D13C: __pyx_pf_11cython_leak_13PySquareArray___cinit__ (cython_leak.c:1420)
==4765==    by 0x544D13C: __pyx_pw_11cython_leak_13PySquareArray_1__cinit__ (cython_leak.c:1388)
==4765==    by 0x544D13C: __pyx_tp_new_11cython_leak_PySquareArray (cython_leak.c:1724)

Здесь указан наш класс PySquareArray и утекающая функция cinit. Детали можно изучить в скомпилированном файле cython_leak.c. 

В чем же причина утечки? Конечно, в отсутствии деструктора:

   from libc.stdlib cimport malloc, free
   
   ...
   
   def __dealloc__(self):
        free(self._thisptr)

После повторной компиляции и запуска можно увидеть абсолютно корректную работу приложения:

Заключение

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

Memory leaks in Python can occur when objects that are no longer being used are not correctly deallocated by the garbage collector. This can result in the application using more and more memory over time, potentially leading to degraded performance and even crashing. In this article, we will explore how to diagnose and fix memory leaks in Python.

How to Diagnose Memory Leaks in Python

There are several tools that can be used to diagnose memory leaks in Python. Here are a few options:

Tracemalloc module

The tracemalloc module is a built-in Python module that can be used to track the allocation of memory blocks in Python. It can be used to track the source code location where the memory was allocated, as well as the size of the allocated memory block.

To use tracemalloc, you will first need to enable it by calling tracemalloc.start(). Then, you can take a snapshot of the current memory allocation by calling tracemalloc.take_snapshot(). This will return a Snapshot object, which contains information about the memory blocks that are currently allocated.

You can then use the Snapshot.statistics() method to get a list of Statistic objects, which represent the memory blocks that are currently allocated, sorted by the size of the memory blocks. You can use this information to identify the source code locations where the largest memory blocks are being allocated, which may be indicative of a memory leak.

Here’s an example of how to use tracemalloc to take a snapshot and print the statistics:

Output:

6a0aa145-b72e-42a5-a8b2-b92294e6e4d9.py:6: size=7813 KiB, count=2, average=3907 KiB

Objgraph module

The objgraph module is a third-party Python module that can be used to visualize the relationships between objects in Python. It can be used to create a graph of the objects that are currently in memory, which can be helpful in identifying objects that are being retained unnecessarily, potentially leading to a memory leak.

To use objgraph, you will first need to install it using pip install objgraph. Then, you can use the objgraph.show_most_common_types() function to print a list of the most common object types that are currently in memory. You can also use the objgraph.show_backrefs() function to show the references to a specific object, which can be helpful in identifying objects that are being retained unnecessarily.

Output:

This will print a list of the most common object types, along with the number of instances of each type that are currently in memory.

function                   31059
dict                       17893
tuple                      13173
list                       9031
weakref                    6813
cell                       5321
builtin_function_or_method 4139
getset_descriptor          3808
type                       3598
method                     3467

Memory_profiler module

The memory_profiler module is a third-party Python module that can be used to measure the memory usage of Python code. It works by decorating functions or methods with the @profile decorator, which will cause the memory usage to be recorded at each point in the code where the decorated function is called.

To use memory_profiler, you will first need to install it using pip install memory_profiler. Then, you can decorate the functions or methods that you want to profile with the @profile decorator. When you run the code, the memory usage will be recorded at each point where the decorated function is called.

Output:

When you run this code, the memory usage will be recorded at each point where my_function is called. You can then use the recorded memory usage to identify any areas of the code where the memory usage is significantly increasing, which may be indicative of a memory leak.

Filename: c:Userssiddheshdemo.py

Line #    Mem usage    Increment  Occurrences   Line Contents
=============================================================
     3     21.9 MiB     21.9 MiB           1   @profile
     4                                         def my_function():
     5     29.6 MiB      7.6 MiB           1      a = [1] * (10 ** 6)
     6     37.2 MiB      7.6 MiB           1      b = [2] * (10 ** 6)
     7     29.6 MiB     -7.6 MiB           1      del a
     8     21.9 MiB     -7.6 MiB           1      del b

How to Fix Memory Leaks in Python

Once you have identified the source of a memory leak in your Python code, there are a few strategies that you can use to fix it.

Deallocate Unused Objects

One of the most common causes of memory leaks in Python is the retention of objects that are no longer being used. This can occur when an object is referenced by another object, but the reference is never removed. As a result, the garbage collector is unable to deallocate the unused object, leading to a memory leak.

To fix this type of memory leak, you will need to ensure that all references to the unused object are removed when it is no longer needed. This can be done by setting the reference to None or by deleting the reference altogether.

In this example, the MyClass object is no longer needed after the process_data method is called. By setting the reference to obj to None, we allow the garbage collector to deallocate the object and avoid a memory leak.

Use Generators or Iterators

Another common cause of memory leaks in Python is the creation of large lists or arrays that are not needed all at once. For example, consider the following code:

Output:

499999500000

In this example, the data list is created by generating all the integers from 0 to 1 million. This can be very memory intensive, especially if the list is not needed all at once. To avoid this type of memory leak, you can use a generator or iterator instead of creating a large list.

A generator is a special type of function that generates values one at a time, rather than generating a whole list of values at once. To create a generator in Python, you can use the yield keyword instead of return.

Output:

499999500000

In this example, the data_generator function generates the integers one at a time, allowing us to process them without having to store a large list in memory.

Alternatively, you can use an iterator, which is an object that generates values one at a time when iterated over. To create an iterator in Python, you can implement the __iter__ and __next__ methods in a class. Here’s an example of how to rewrite the above code using an iterator:

Output:

In this example, the DataIterator class generates the integers one at a time when iterated over, allowing us to process them without having to store a large list in memory.

500000500000

Use Weak References

Another strategy for avoiding memory leaks in Python is to use weak references. A weak reference is a reference to an object that does not prevent the object from being deallocated by the garbage collector. This can be useful in situations where you want to hold a reference to an object, but don’t want to prevent the object from being deallocated when it is no longer needed.

In this example, the weak reference obj_ref can be used to access the MyClass object, but it does not prevent the object from being deallocated by the garbage collector when it is no longer needed.

By using weak references, you can avoid memory leaks caused by the retention of objects that are no longer being used. However, it is important to be aware that weak references can become stale if the object they reference has been deallocated, so you will need to handle these cases appropriately in your code.

To create a weak reference in Python, you can use the weakref module. Here’s an example of how to use a weak reference:

Output:

The object has been deallocated