Python - работа с утечками памяти

Ответ 1

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

>>> from collections import defaultdict
>>> from gc import get_objects
>>> before = defaultdict(int)
>>> after = defaultdict(int)
>>> for i in get_objects():
...     before[type(i)] += 1 
... 

теперь предположим, что тесты утечки некоторой памяти

>>> leaked_things = [[x] for x in range(10)]
>>> for i in get_objects():
...     after[type(i)] += 1
... 
>>> print [(k, after[k] - before[k]) for k in after if after[k] - before[k]]
[(<type 'list'>, 11)]

11, потому что мы пропустили один список, содержащий еще 10 списков

Ответ 2

Темы не помогли бы. Если вы должны отказаться от обнаружения утечки, то единственным решением, которое будет содержать его эффект, будет время от времени запускать новый процесс (например, когда тест оставил общее потребление памяти слишком высоким по своему вкусу - вы можете определить размер виртуальной машины легко, прочитав /proc/self/status в Linux и другие подобные подходы к другим ОС).

Убедитесь, что общий script принимает необязательный параметр, чтобы сообщить ему, какой номер теста (или другой идентификатор теста) должен начаться, так что, когда один экземпляр script решает, что он занимает слишком много памяти, он может сообщите своему преемнику, откуда следует перезапустить.

Или, более прочно, убедитесь, что по мере завершения каждого теста его идентификация добавляется к некоторому файлу с известным именем. Когда программа запускается, она начинается с чтения этого файла и, таким образом, знает, какие тесты уже выполнены. Эта архитектура более надежна, поскольку она также охватывает случай, когда программа вылетает во время теста; конечно, чтобы полностью автоматизировать восстановление после таких сбоев, вы захотите, чтобы отдельная программа сторожевого таймера и процесс отвечали за запуск нового экземпляра тестовой программы, когда она определяет предыдущую, разбилась (она могла использовать subprocess для цель - ему также нужно указать, когда последовательность будет закончена, например, нормальный выход из тестовой программы может означать, что, хотя любой сбой или выход со статусом!= 0 означают необходимость запуска нового нового экземпляра).

Если эти архитектуры понравятся, но вам нужна дальнейшая помощь в их реализации, просто прокомментируйте этот ответ, и я буду рад предоставить пример кода - я не хочу делать это "превентивно", если есть еще -небыстрые проблемы, которые делают архитектуры непригодными для вас. (Это также может помочь узнать, на каких платформах вам нужно работать).

Ответ 3

Я бы просто реорганизовал эксперименты на отдельные функции (если не так, как это уже), тогда примите номер эксперимента из командной строки, который вызывает функцию одного эксперимента.

Просто перетащить оболочку script следующим образом:

#!/bin/bash

for expnum in 1 2 3 4 5 6 7 8 9 10 11 ; do
    python youProgram ${expnum} otherParams
done

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

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

Хотя трудно представить себе утечку памяти в Python, я возьму ваше слово на этом - вы можете хотя бы рассмотреть возможность того, что вы ошибаетесь там. Подумайте, поднимая это в отдельном вопросе, с чем мы можем работать с низким приоритетом (в отличие от этой быстрой версии).

Обновление: создание сообщества wiki, поскольку вопрос несколько изменился с оригинала. Я бы удалил ответ, но по-прежнему считаю, что это полезно - вы могли бы сделать то же самое с вашим экспериментатором, как я предложил bash script, вам просто нужно убедиться, что эксперименты являются отдельными процессами, так что утечки памяти не происходят (если утечки памяти находятся в бегуне, вам придется выполнять анализ основных причин и исправлять ошибку).

Ответ 4

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

Здесь общее решение (если вы когда-либо находите утечку, единственное изменение, которое вам нужно сделать, это изменить run() для вызова run_single_process() вместо run_forked(), и вы сделаете это):

import os,sys
batchSize = 20

class Runner(object):
    def __init__(self,dataFeedGenerator,dataProcessor):
        self._dataFeed = dataFeedGenerator
        self._caller = dataProcessor

    def run(self):
        self.run_forked()

    def run_forked(self):
        dataFeed = self._dataFeed
        dataSubFeed = []
        for i,dataMorsel in enumerate(dataFeed,1):
            if i % batchSize > 0:
                dataSubFeed.append(dataMorsel)
            else:
                self._dataFeed = dataSubFeed
                self.fork()
                dataSubFeed = []
                if self._child_pid is 0:
                    self.run_single_process()
                self.endBatch()

    def run_single_process(self)
        for dataMorsel in self._dataFeed:
            self._caller(dataMorsel)

    def fork(self):
        self._child_pid = os.fork()

    def endBatch(self):
        if self._child_pid is not 0:
            os.waitpid(self._child_pid, 0)
        else:
            sys.exit() # exit from the child when done

Это изолирует утечку памяти дочернему процессу. И он никогда не будет течь больше раз, чем значение переменной batchSize.