缓慢增加Dask调度程序的内存使用

我正在运行一个测试：

client = Client('127.0.0.1:8786')

def x(i):
    return {}

while True:
    start = time.time()
    a = client.submit(randint(0,1000000))
    res = a.result()
    del a
    end = time.time()
    print("Ran on %s with res %s" % (end-start, res))

client.shutdown()
del client

我使用它（与更多代码一起）来估计我的查询性能。但对于这个例子，我已经删除了所有我能想到的东西

上面的代码每秒泄漏大约0.1MB，我估计每1000次调用泄漏大约0.3MB

---

我的代码有什么地方做错了吗？

我的python调试技能有点生疏（有点生疏，我的意思是我上次在Orbited（websockets的前身）上使用objgraph是在2009年），但从我看到的情况来看，检查前后的引用数量：

在使用

objgraph前后，在计划程序中计算对象。显示\u最常见的\u类型（）

在任何情况下，RAM的数量都不是很大，但深入挖掘后，我发现t scheduler._transition_计数器是11453，scheduler.transition_日志中填充了：

 ('x-25ca747a80f8057c081bf1bca6ddd481', 'released', 'waiting', 
      OrderedDict([('x-25ca747a80f8057c081bf1bca6ddd481', 'processing')]), 4121), 
 ('x-25ca747a80f8057c081bf1bca6ddd481', 'waiting', 'processing', {}, 4122), 
 ('x-25cb592650bd793a4123f2df39a54e29', 'memory', 'released', OrderedDict(), 4123), 
('x-25cb592650bd793a4123f2df39a54e29', 'released', 'forgotten', {}, 4124), 
 ('x-25ca747a80f8057c081bf1bca6ddd481', 'processing', 'memory', OrderedDict(), 4125), 
 ('x-b6621de1a823857d2f206fbe8afbeb46', 'released', 'waiting', OrderedDict([('x-b6621de1a823857d2f206fbe8afbeb46', 'processing')]), 4126)

我的第一个错误
这当然让我意识到我的第一个错误是没有配置转换日志长度

将配置

转换日志长度设置为10后：

| What           | Before   | After  |  Diff   | 
| ---------------+----------+--------+---------|
| function       | 33323    | 33336  |  13     |
| dict           | 17987    | 18120  |  133    | 
| tuple          | 16530    | 16342  |  -188   |
| list           | 10928    | 11136  |  208    |
| _lru_list_elem | N/A      | 5609   |  5609   |

一个快速的google发现
\u lru\u list\u elem
是由
@functools.lru\u cache
生成的，而这反过来又在中被调用（在
分布式/utils.py
）

这是LRU缓存，最多包含100000项

第二次尝试

根据代码，Dask应该上升到大约10k
\u lru\u list\u elem

在再次运行我的脚本并观察内存后，它会快速上升，直到我接近100k\u lru\u list\u元素，之后它几乎完全停止上升

这似乎是事实，因为它在100k之后几乎是扁平线


因此，没有泄漏，但在Dask源代码和Python内存分析器上动手很有趣
出于诊断、日志记录和性能原因，Dask调度程序在固定大小的DEQUE中记录其与工作人员和客户端的许多交互。这些记录确实在积累，但只在有限的范围内

我们还努力确保我们不会保留太大的东西

看到记忆使用上升，直到一个很好的整数，就像你所看到的，然后保持稳定，这似乎是一致的

| What           | Before   | After  |  Diff   | 
| ---------------+----------+--------+---------|
| function       | 33323    | 33336  |  13     |
| dict           | 17987    | 18120  |  133    | 
| tuple          | 16530    | 16342  |  -188   |
| list           | 10928    | 11136  |  208    |
| _lru_list_elem | N/A      | 5609   |  5609   |