DASK Sheduler

的緩慢增加內存使用情況我運行一個測試：DASK Sheduler

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.1 MB，我估計大約每1000次調用0.3MB。

我在做我的代碼錯了嗎？

來源

2017-10-04 Niklas B

我的python調試技能有點生疏（我的意思是我最後在2009年https://pypi.python.org/pypi/orbited上使用了Orbited（websockets的前身）的objgraph），但從我所看到的，檢查前後引用的數量：

計數目標的調度，前後用objgraph.show_most_common_types()

| What  | Before   | After | Diff | 
|-------------+------------------+--------|---------+ 
| function | 33318   | 33399 | 81 | 
| dict  | 17988   | 18277 | 289 | 
| tuple  | 16439   | 28062 | 11623 | 
| list  | 10926   | 11257 | 331 | 
| OrderedDict | N/A    | 7168 | 7168|

後這不是RAM在任何情況下數量龐大，但更深的挖掘，我發現是t scheduler._transition_counter是11453和scheduler.transition_log充滿了：

('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)

對我而言第一個錯誤
這當然使我意識到我的一部分的第一個錯誤是沒有配置過渡記錄長度。

設置配置transition-log-length至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 |

快速谷歌發現_lru_list_elem由@functools.lru_cache後者又在援引key_split製成（在distributed/utils.py）

哪個是LRU緩存，高達100 000個項目。

第二次嘗試
此基礎上出現DASK應該爬上大約10K _lru_list_elem

再次運行我的腳本，並看着它爬上相當快，直到我接近100K _lru_list_elem內存後，以後的代碼它幾乎完全停止攀登。

這似乎是這樣，它幾乎後100K

因此，沒有泄漏，因爲扁線，但有趣的拿到手就DASK源代碼和Python內存分析器髒

來源

2017-10-04 14:54:44

對於診斷，日誌記錄和性能方面的原因，Dask調度程序會記錄與固定大小deques中的工作人員和客戶的許多交互記錄。這些記錄確實有積累，但僅限於有限的範圍。

我們也努力確保我們不會在任何情況下保持太大。

看到記憶使用爬起來，直到一個不錯的圓形數字，像你所看到的，然後保持穩定似乎與此一致。

來源

2017-10-04 15:09:42 MRocklin

回答

相關問題