Память и объекты: почему int стоит 28 байт и где на самом деле живёт утечка

Почему объекты Python толстые

Прежде чем искать утечку памяти, нужно понять, за что именно платишь. Когда знаешь стоимость заголовка каждого типа, цифры RSS перестают быть загадкой и становятся арифметикой.

Каждый Python-объект на 64-битной сборке начинается с 16-байтного заголовка: 8 байт счётчика ссылок и 8 байт указателя на тип. Payload — после. Бытовые числа:

import sys
sys.getsizeof(1)       # 28  — заголовок + размер + одна 30-битная цифра
sys.getsizeof(1.0)     # 24  — заголовок + один C double
sys.getsizeof("a")     # 50  — заголовок + флаги + длина + ASCII-буфер
sys.getsizeof({})      # 64  — пустой dict, растёт скачками степеней двойки
sys.getsizeof([])      # 56  — пустой list

Это попредметная цена динамизма: каждое значение в куче, типизировано в рантайме, пересчитывается по ссылкам на каждом связывании. C-шный double — 8 байт в регистре; Python-float — 24 байта в куче плюс 8-байтный указатель, который кто-то держит, чтобы до него добраться. Умножьте на десять миллионов — и счёт за динамизм приходит гигабайтами.

getsizeof лжёт поверхностно

sys.getsizeof сообщает собственную аллокацию одного объекта — для контейнеров это таблица указателей, не содержимое. Список из миллиона float: getsizeof(lst) говорит около 8 МБ (миллион 8-байтных слотов плюс заголовок), тогда как реальный след — эти 8 МБ плюс 24 МБ объектов-float: минимум 32 МБ, больше, когда голосует фрагментация аллокатора. Честный размер рекурсивен: обход gc.get_referents с множеством посещённых — или профилировщик кучи вместо арифметики.

Подсчёт ссылок — и когда отрабатывает циклический сборщик

CPython освобождает объект в момент, когда его refcount достигает нуля — детерминированно, немедленно; поэтому файловые дескрипторы в аккуратном коде закрываются вовремя. Чего refcount освободить не может — цикл: родитель и потомок, держащие ссылки друг на друга, нуля не достигнут никогда. Это работа циклического GC: три поколения, срабатывание по порогам (чистым аллокациям), выжившие повышаются. Циклы копятся в графах с обратными ссылками — деревья, чьи узлы указывают на родителя, ORM-строки, указывающие на сессию, и классический спящий агент: сохранённое исключение держит traceback, traceback держит каждый фрейм, а каждый фрейм — все свои локальные переменные.

gc.collect() — диагностика не меньше, чем лекарство: если принудительная полная сборка почти не сдвигает память — те два мегабайта из хука, — ваш рост достижим, и никакой сборщик мусора вас не спасёт. Утечка — это структура данных, делающая ровно то, что ей велели.

slots ещё раз: рычаг для числа объектов

Юнит о модели данных дал механизм; вот арифметика ёмкости. Пятиполевой обычный экземпляр стоит примерно 250+ байт, как только существует его __dict__; слотированный — около 104. На 1 млн объектов это ~250 МБ против ~104 МБ, а на 40 млн — разница между подом, который влезает, и подом, который OOM-ится. @dataclass(slots=True) сводит это к одному флагу. Слоты — правильный рычаг, когда проблема в числе объектов, а набор полей фиксирован.

Списки объектов против array против numpy: таблица порядков величины

Когда данные числовые и высококардинальные, выигрыш — перестать иметь объекты вообще:

Непрерывный типизированный буфер в 4-10 раз меньше и дружит с кэшем; список с погоней за указателями и толст, и медленен в обходе. Эта таблица — ещё и мост к следующему уроку: numpy — это C-расширение, которое кто-то уже написал.

tracemalloc: найти место аллокации, а не симптом

RSS говорит, что память выросла; tracemalloc — какая строка её выделила. Запускайте рано (глубина фреймов стоит памяти и CPU, так что включайте на время охоты, не навсегда), снимите два снапшота, продиффуйте:

import tracemalloc
tracemalloc.start(25)            # хранить 25 фреймов на место аллокации

s1 = tracemalloc.take_snapshot()
# ... 30 минут репрезентативного трафика ...
s2 = tracemalloc.take_snapshot()

for stat in s2.compare_to(s1, "lineno")[:10]:
    print(stat)                  # рост, ранжированный по выделяющей строке

py-spy этого не умеет — он сэмплирует CPU-стеки, не аллокации. Для нативного + Python-учёта аллокаций есть memray, более тяжёлый сторонний вариант; tracemalloc — инструмент stdlib, который есть везде.

Паттерны утечек, которые не утечки

Повторяющиеся злодеи — всё это достижимый рост: модульные кэши и реестры, которые только дописывают; lru_cache(maxsize=None) с высококардинальными ключами; замыкания и сохранённые исключения, пришпиливающие фреймы (и каждую локальную переменную в них); только-растущие списки на долгоживущих синглтонах. Настоящие C-уровневые утечки существуют, но в чистом Python редки. Когда RSS растёт, первый вопрос не «что утекло», а «какая структура данных слишком хорошо делает свою работу».