Краткий ответ

Для поиска источника роста живой памяти важнее суммарный размер выделенной памяти — показатель size или size_diff. Число аллокаций (count или count_diff) показывает интенсивность создания объектов, но множество мелких аллокаций может занимать меньше памяти, чем несколько крупных.

Исторический контекст

tracemalloc появился как стандартный инструмент Python для трассировки выделений памяти на уровне Python-объектов. Он решает практическую проблему, которую нельзя надёжно решить одним измерением RSS: помогает связать занятый объём с местом в исходном коде, где память была выделена.

Постановка проблемы

В отчёте могут одновременно присутствовать строка с огромным числом небольших аллокаций и строка с небольшим числом крупных аллокаций. Если ориентироваться только на count_diff, можно выбрать участок с высокой активностью, но не тот, который ответственен за рост потребления памяти.

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

Подробное решение

Для сравнения двух снимков нужно смотреть на size_diff: он показывает, насколько изменился суммарный объём памяти, связанный с конкретной группой трассировок. Положительное значение указывает на рост, отрицательное — на уменьшение. При анализе текущего состояния одного снимка используется size.

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

import tracemalloc

tracemalloc.start()
before = tracemalloc.take_snapshot()

# анализируемая операция
items = [str(i) for i in range(10000)]

after = tracemalloc.take_snapshot()
for stat in after.compare_to(before, 'lineno')[:3]:
    print(stat.size_diff, stat.count_diff, stat)

Группировка по lineno показывает вклад отдельных строк, но можно группировать и по файлу или полной трассировке. Следует помнить, что tracemalloc отслеживает трассируемые Python-выделения, а не всю память процесса: нативные буферы расширений, память некоторых библиотек и накладные расходы самого процесса могут отсутствовать в отчёте.

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

Ситуация из практики

В обработчике запросов одна строка создавала сотни тысяч коротких временных строк, а другая — несколько крупных списков результатов. Первая строка имела максимальный count_diff, поэтому первоначально оптимизировали её, но RSS и объём tracemalloc почти не изменились.

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

Выбрали сортировку отчёта по size_diff, после чего обнаружили, что список результатов сохранялся дольше необходимого. Его освобождение после завершения обработки уменьшило живой объём памяти. Оптимизация мелких временных строк была выполнена позднее как отдельная задача производительности.

Что кандидаты часто упускают

Всегда ли максимальный size_diff означает утечку памяти?

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

Что означает большой count_diff при малом size_diff?

Обычно это означает, что создано много небольших объектов или что объекты быстро освобождаются, поэтому их суммарный живой объём невелик. Такой результат может указывать на лишние временные объекты и влиять на CPU и работу сборщика мусора, но не обязательно является причиной высокого потребления памяти.

Можно ли по size_diff определить реальный пик памяти процесса?

Не напрямую. size_diff описывает разницу между выбранными снимками и только трассируемую память. Если крупный объект был создан и освобождён между снимками, его вклад может не попасть в итоговое сравнение. Для пика нужны более частые измерения или отдельный мониторинг процесса, а результаты tracemalloc следует сопоставлять с RSS и особенностями используемых нативных библиотек.