我编写的脚本将任务添加到我的芹菜队列中正在泄漏内存(到20分钟后内核杀死该过程的地步)。在此脚本中,我只是反复执行相同的300个任务,每60秒(在while True:
内)。
传递给任务的参数makeGroupRequest()
是包含字符串的字典,根据HPY和OBJGRAPH,DICT和字符串也是无法控制的记忆中的。我在循环的连续迭代中包括了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)
这是Sucessive运行中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
事实证明这是芹菜中的一个错误。切换到memcache
后端完全可以解决内存泄漏。希望该问题将在后续版本中解决。