Python быстро теряет память, когда Celery получает результаты - PullRequest
0 голосов
/ 17 февраля 2019

Скрипт, который я написал для добавления задач в мою очередь Celery, вызывает утечку памяти (до такой степени, что ядро ​​убивает процесс через 20 минут).В этом сценарии я просто выполняю те же 300 задач повторно, каждые 60 секунд (внутри while True:).

Параметры, передаваемые в задачу makeGroupRequest(), являются словарями, содержащими строки, и в соответствии сдля hpy и objgraph диктанты и строки - это также то, что неудержимо растет в памяти.Я включил выходные данные hpy ниже в последовательные итерации цикла.

Я потратил несколько дней на это, и я не могу понять, почему память может бесконтрольно расти, учитывая, что между циклами ничего не используется повторно,Если я пропущу извлечение задач, память, похоже, не просачивается (поэтому действительно вызов .get () вызывает утечку памяти).Как я могу определить, что происходит и как остановить рост?

Вот схема кода, который выполняется.Я использую rpc: // backend.

while True:

    # preparation is done here to set set up the arguments for the tasks (processedChains)

    chains = []

    for processedChain in processedChains:

        # shorthanding
        supportingData = processedChain["supportingDataAndCheckedGroups"]

        # init the first element, which includes the supportingData and the first group
        argsList = [(supportingData, processedChain["groups"][0])]

        # add in the rest of the groups
        argsList.extend([(groupInChain,) for groupInChain in processedChain["groups"][1:]])

        # actually create the chain
        chain = celery.chain(*[makeGroupRequest.signature(params, options={'queue':queue}) for params in argsList])

        # add this to the list of chains
        chains.append(chain)

    groupSignature = celery.group(*chains).apply_async()

    # this line appears to cause a large increase in memory each cycle
    results = groupSignature.get(timeout = 2 * acceptableLoopTime)

    time.sleep(60)

Вот вывод hpy при последующих запусках:

Цикл 2:

Partition of a set of 366560 objects. Total size = 57136824 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0  27065   7 17665112  31  17665112  31 dict (no owner)
     1 122390  33 11966720  21  29631832  52 unicode
     2  89133  24  8291952  15  37923784  66 str
     3  45448  12  3802968   7  41726752  73 tuple
     4    548   0  1631072   3  43357824  76 dict of module
     5  11195   3  1432960   3  44790784  78 types.CodeType
     6   9224   3  1343296   2  46134080  81 list
     7  11123   3  1334760   2  47468840  83 function
     8   1414   0  1274552   2  48743392  85 type
     9   1414   0  1240336   2  49983728  87 dict of type

Петля 3:

 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0  44754   9 29240496  37  29240496  37 dict (no owner)
     1 224883  44 20946280  26  50186776  63 unicode
     2  89104  18  8290248  10  58477024  74 str
     3  45455   9  3803288   5  62280312  79 tuple
     4  14955   3  2149784   3  64430096  81 list
     5    548   0  1631072   2  66061168  83 dict of module
     6  11195   2  1432960   2  67494128  85 types.CodeType
     7  11122   2  1334640   2  68828768  87 function
     8   1402   0  1263704   2  70092472  88 type
     9   1402   0  1236976   2  71329448  90 dict of type

1 Ответ

0 голосов
/ 22 марта 2019

Оказывается, это ошибка в сельдерее.Переключение на бэкэнд memcache полностью устраняет утечку памяти.Надеемся, что проблема будет решена в следующей версии.

...