У меня была похожая проблема с отслеживанием серьезной утечки памяти в тяжелом коде, где ни один из обычных инструментов и средств диагностики памяти Python не обнаружил утечку или не намекнул на ее источник.
В моем случае источником утечки был код интерфейса scipy для пакета решателя UMFPACK, который вызывал процедуру инициализации языка C при каждом вызове конструктора объекта интерфейса, но никогда не вызывал процедуру деинициализациикогда объект интерфейса был разрушен, что привело к утечке памяти и внутренним выделениям со скоростью около 15 Мб на вызов.В приложении с вызовами 10-20 тыс. Влияние было серьезным.Поскольку выделение памяти не было выполнено с помощью диспетчера памяти Python, такие вещи, как heapy, не могли обнаружить утечку.
Я столкнулся с необходимостью использовать отладку в стиле valgrind + "printf", чтобы отследить преступника.Возможно, вам придется взглянуть на анализаторы памяти, отличные от Python, и инструменты, чтобы выяснить, откуда происходит утечка.Я не работаю в среде Windows и не знаком со стандартными цепочками инструментов, поэтому не могу предложить, что именно использовать.Возможно, кто-то еще мог бы внести некоторые предложения.