Удаленные объекты все еще упоминаются в рассоле

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

Например, у Person может быть атрибут с именем address_list (список), который содержит объекты Address, представляющие все свойства, которые они пытаются продать. Другой объект, RealEstateAgent, может иметь атрибут с именем address_for_sale (тоже список), который содержит объекты Address того же типа, но только те, которые перечислены в их агентстве.

Если продавец снимает свою собственность с продажи или она продается, адрес удаляется из обоих списков.

И Persons, и RealEstateAgents являются членами списка центральных объектов (Masterlist) для травления. Моя проблема заключается в том, что по мере того, как я добавляю и удаляю свойства, а также периодически солючу объект Masterlist, размер файла соленья увеличивается, даже если я удалил (на самом деле удалил) больше свойств, чем добавил. Я понимаю, что при травлении Masterlist есть циклическая ссылка. В моем приложении много циклических ссылок.

Я изучил файл pickle с помощью pickletools.dis(), и, хотя его трудно читать человеку, я вижу ссылки на адреса, которые были удалены. Я уверен, что они удалены, потому что даже после распаковки их нет в соответствующих списках.

Хотя приложение работает правильно до и после травления/распаковывания, растущий размер файла является проблемой, поскольку процесс должен выполняться долго, и его повторная инициализация невозможна.

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

Большое спасибо


person domoarigato    schedule 03.09.2014    source источник
comment
В конечном итоге я использовал objgraph и heapy, чтобы найти источник утечки - большое спасибо. О, и ссылки на самом деле все еще находились в объекте после загрузки в память, просто не там, где я их ожидал. Это отличный инструмент для сложных объектных отношений!   -  person domoarigato    schedule 04.09.2014


Ответы (1)


Возможно, вы захотите попробовать objgraph… это может серьезно помочь вам в отслеживании утечек памяти, циклических ссылок и взаимосвязей указателей между объектами.

http://mg.pov.lt/objgraph/

Я использую его при отладке солений (в моем собственном пакете солений под названием dill).

Кроме того, некоторые маринованные объекты будут (внизу по цепочке маринования) мариновать глобальные объекты, что часто является причиной циклических ссылок внутри маринованных объектов.

У меня также есть набор инструментов для отладки рассола в dill. См. dill.detect на странице https://github.com/uqfoundation, где описано несколько методов, которые можно использовать для диагностики объектов. ты привязываешься к маринаду. Например, если вы установите dill.detect.trace(True), он распечатает все внутренние вызовы для обработки объектов, пока ваш объект сбрасывается.

person Mike McKerns    schedule 03.09.2014
comment
очень классный модуль. Потратил некоторое время на изучение спагетти-подобных графиков, которые создает мой код :) Однако я не могу найти ссылки в памяти на какие-либо объекты типа Address. Использование: objgraph.by_type('Address'), даже если они кажутся в файле рассола. Вы упомянули об использовании objgraph для непосредственного изучения рассола, какие-либо указатели на то, как это сделать? - person domoarigato; 04.09.2014
comment
Я не говорил, что он может исследовать рассол напрямую, но это хороший инструмент, который я использую при отладке рассола. См. мое редактирование выше. - person Mike McKerns; 04.09.2014