Случаи использования gc.collect()

утечки памяти в python-коде

Щас вброшу, но… Там разве вообще об этом думают? Это ж не си, чтобы о памяти думать — пишешь абы как и все.

пишешь как все, и всё…

Кстати, да. На собеседованиях никогда про сборку мусора не спрашивали.

Часто ли вам приходится вызывать gc.collect() после del my_object

ни разу

утечки памяти в python-коде?

Ни gc.collect(), ни del не помогут тебе найти или устранить утечки. Отследить их наличие несложно, достаточно смотреть в top или ps, а вот найти причину довольно сложно. На моей практике, причина всегда находилась аналитически. Ну тип отключешь тот или иной кусок программы, смотришь не пропала ли утчечка. На моей практике причинами всегда были циклические ссылки или дырявые внешние либы. Со вторым редко можно сделать что-то самостоятельно, а вот первое решается использованием weakref

Хех. Тот самый Си, где нет автоматических деструкторов? Где пропустил один free и все утекло без варнингов?

Именно :) Зато там думать надо!

Там разве вообще об этом думают? Это ж не си, чтобы о памяти думать — пишешь абы как и все.

Таки думают. Открыл картинку в pillow, не закрыл - минус дофига памяти. Сделал read() не указав сколько собственно читать - высосал в память пару гиг и ООМнулся. Настругал «умных» кешей и они подрались с такими же «умными» из соседнего модуля - опять ООМ.

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

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

Вот я примерно об этом и говорил, что там нет нормальных средств для этого, и если ты захочешь сделать что-то серьезное — привет костыли сразу.

Часто ли вам приходится вызывать gc.collect() после del my_object?

Только при экспериментах или отладке утечек памяти. В нормальном коде - нет.

Может понадобиться в PyPy, т.к. в нём сборщик мусора не использует подсчёт ссылок, соотв-но, поведение сильно отличается (не работают предположения нерадивых разработчиков, типа open('somefile', 'w').write(some_text), что файловый объект будет сразу же собран сборщиком мусора после записи).

Но я не знаю ни одного проекта, использующего PyPy (все ссут его использовать, либо не получается завести какую-нибудь зависимость, и на этом этапе бросают).

Каким инструментарием обычно отслеживаете утечки памяти в python-коде?

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

Самую сложную утечку памяти в своей жизни, которая случалась только в проде, который нельзя останавливать, и на известном высоконагруженном сервисе, которым пользуются десятки миллионов пользователей, смог найти только при помощи meliae (которую ещё и пришлось пропатчивать для этого).

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

Проблема скорее что этот самый контроль можно игнорить. Например какого пня тот же read можно вызвать без аргумента? Такие вещи для обвязки как раз критичны, и ими вполне можно управлять. А то что нельзя «выделить ровно 100508 байт» на структуру и потом их аккуратно почистить по выходу из функции - слабо себе представляю питонячий проект где это нужно и где это не вынесено в сишку

Каким инструментарием обычно отслеживаете утечки памяти в python-коде?

Memray плюс интеграция/e2e/юниты на худой конец. Очень удобно

gc.collect это не про устранение утечек. Как он поможет, если на объекты остались забытые ссылки?

Эта команда нужна, когда ты занимался memory intensive работой и хочешь побыстрее отдать память ОС, а не ждать у моря погоды. То есть ты знаешь, что в куче сейчас должно быть много мёртвых объектов и они и сами собой освободились бы, но хочешь почему-то форсировать процесс.

Нет, не пользовался на практике.

никогда не использовал

утечки памяти в питоне не отслеживаю

утечки памяти в питоне не отслеживаю

А как мониторите объём оставшейся памяти?

free -h?

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

ALGOL и FORTRAN мне не понравились, когда читал первые книги по программированию. Какой-то слишком академический синтаксис. Нет того драйва, который был в Турбо Паскале или ассемблере. А на ZX у меня не было трансляторов FORTRAN на кассетах.

Была возможность писать программы на FORTRAN в НИИ, но отпугнули тонны легаси.

Да и какой у нас в СНГ был выбор? Импортозамещение началось ещё с 1970х.

Тот самый Си, где нет автоматических деструкторов?

__attribute__((__cleanup__))

Тот самый Си, где нет автоматических деструкторов?

открой для себя Boehm-Demers-Weiser Garbage Collector

Ого. Не зря набросил. Спасибо за ссылку

Для чего? примерно на глаз знаю сколько будет жрать, если не хватит то просто x2 на машине сделаю, но как-бы такое никогда не нужно

если не хватит то просто x2 на машине сделаю

Это хорошо, когда деньги - твои, и машина - локально.

А если коммерческий бэкенд 24x7 на VPS, там ещё и заказчику придётся объяснять, зачем увеличиваешь объём RAM.

Заказчик счет оплачивает и все, никто такие вопросы там не задает никогда. Тем более ответ простой.

Если есть утечка памяти, то не поможет ни x2, ни x4. Единственный вариант - перезапуск по таймеру, но это прямо костыль костыльный.

Если есть утечка памяти твой мониторинг тебе об этом скажет и тогда будешь что-то решать. Но мы пишем без утечек и никогда ничего не падает.

Но мы пишем без утечек и никогда ничего не падает.

То есть, UB сторонних библиотек сразу проверяются, по коду?

Зато там думать надо!

Между нами девочками, так себе «преимущество».

___________attribute______________((((((((((((((((((__________cleanup____________))))))))))))))

Это во-первых. А во-вторых, беглое гугленье показало, что этот атрибут надо вешать на переменную, но нельзя повесить на структуру. Т.е. аннотировать надо каждый экземпляр. (Читай – задавать деструктор для класса не в самом классе, а при каждом его инстанциировании. Где-то забудешь, где-то вообще другой впишешь. Такого идиотизма нарочно не придумаешь. «Happy debugging suckers.» (c))

Также нагуглилось будто есть либа, которая с помощью этого атрибута эмулирует плюсовые std::unique_ptr и std::shared_ptr. Как только не извращаются, лишь бы на плюсах не писать.

Как только не извращаются, лишь бы на плюсах не писать.

А могли бы просто обратную совместимость поддерживать при написании Си++. И не надо было бы два компилятора.

Обратная совместимость – зло. Обратная совместимость с кошмарно-убогим полу-недо-типизированным языком – зло в квадрате.

Обратная совместимость – зло. Обратная совместимость с кошмарно-убогим полу-недо-типизированным языком – зло в квадрате.

Я один тут свои «поделки» под valgrind гоняю?

Я один тут свои «поделки» под valgrind гоняю?

Нет. Я тоже пробовал запускать свои поделки под valgrind. Впечатление - «кошмар», начинается с загрузки стандартных модулей из дистрибутивного репозитория.