按照guppy的说法，长时间运行的项目的奇怪的内存消耗

Question

我有一个长期运行的Python项目，它在内存使用上有一个缓慢但永久的增量。如果主脚本接收到大量要处理的工作，并且主进程和子进程都在无限运行(或直到目标作业被删除)，则它会设置新进程(使用多进程)。

为了尝试和了解内存泄漏的来源，我使用guppy模块来分析我的内存，然后让每个进程每两分钟将内存分析写入一个文件。

检查内存配置文件时，我发现只有一种类型的内存在增加- list。其余类型中的值基本上是静态的(有时高一点，有时低一点)。

例如，以下是其中一个进程的报告：

 Index  Count   %     Size   % Cumulative  % Referrers by Kind (class / dict of class)
     0   3707  43   491717  58    491717  58 list
     1   4200  48   239659  28    731376  87 dict of CustomClass
     2    600   7    96000  11    827376  98 CustomClass
     3      4   0     4646   1    832022  98 _io.TextIOWrapper
     4     40   0     3664   0    835686  99 dict (no owner)
     5     46   1     3358   0    839044  99 urllib.parse.SplitResult
     6     90   1     2160   0    841204 100 dict of OtherCustomClass
     7     18   0     2080   0    843284 100 tuple
     8      1   0      424   0    843708 100 <Nothing>
     9      4   0      384   0    844092 100 types.FrameType

如果有任何其他类型的内存数量或大小增加了，我可能会说出哪个列表是内存泄漏的罪魁祸首，但因为只有list的大小在增加，所以我不确定应该如何处理这个问题，并找出哪个列表是内存泄漏的根源。

此外，属于一个类实例的所有列表要么受大小限制，要么每隔一段时间就被清除(我确保调用了clear )。我在函数内部创建的其他列表，我希望一旦它们不再在作用域中，就会被删除。

我是不是遗漏了什么？非常感谢

Answer 1

考虑使用https://github.com/vmware/chap

在您的情况下，您可能需要执行以下操作：

启动您的进程(不以任何方式进行检测)。

获取该进程的活动核心，例如，通过使用gcore，距离足够远，以显示增长。

对于每个核心，在chap中打开核心，然后执行以下操作：

redirect on
describe used

因此，您将有两个文件(每个核心一个)，您可以进行比较，以查看哪些分配是新的或已经消失。你的列表应该反映在那里。找到一个列表的地址，并使用“解释”来找出它是如何被使用的。