寫的dht協議搜尋的程式，這幾天最佳化了一下發現速度確實快了好多。但是出現了一個新的問題，記憶體直接飆升，我開了十個爬蟲佔用記憶體800m。開始我以為是節點太多了，找了幾個小問題修改一下，發現沒用。後來就到網上尋找python記憶體分析的工具，查了一點資料發現python有個meliae庫操作非常方便，就流量分析了一下，發現不是節點太多的原因0 0,是儲存發送的t_id，用來標示返回的訊息是那個發出的一個字典過大了。
從分析的結果非常容易的定位了某個對象的數量和大小，非常容易分析。我開始以為是因為好多發送查詢資訊以後，對面沒返回造成這個字典裡的元素沒有釋放造成的，我就用到期時間判斷了一下，進行到期刪除。發現是小了，但是不是非常顯著，好像少了幾十不到100M。後來又減少了尋找一個隨機hash的時間，以前是1分鐘查一次，我改成了就第一次查！，發現沒減少0 0.不知道是啥的原因。應該就是尋找hash，詢問節點，然後返回然後詢問裡邊的節點，最後數量越來越多，但是我不明白的是，怎麼會這麼多運行一分鐘就有60萬條。也就是說當時記憶體沒釋放的對象就有這麼多。達到這個記憶體佔用後，基本就不再變化，有很小很慢的提升，因為還開的其他程式，不確定是不是這些程式其他對象的增加造成的。等分階段dump測試一下。
安裝直接pip install meliae 就ok了，我看好久沒更新的項目了，不知道還有沒有好的替代品不過用著還不錯。
將記憶體dump到檔案
複製代碼 代碼如下:
from meliae import scanner
scanner.dump_all_objects('/tmp/dump%s.txt' % time.time())
分析檔案：
複製代碼 代碼如下:
from meliae import loader
#載入dump檔案
om = loader.load('/opt/log/dump.txt')
#計算各Objects的參考關聯性
om.compute_parents()
#去掉各對象Instance的_dict_屬性
om.collapse_instance_dicts()
#分析記憶體佔用情況
om.summarize()
欄位意義如下：
Index : 行索引號
Count : 該類型的對象總數
%(Count) : 該類型的對象總數 占 所有類型的對象總數 的百分比
Size : 該類型的對象總位元組數
%(Size) : 該類型的對象總位元組數 占 所有類型的對象總位元組數 的百分比
Cum : 累積行索引後的%(Size)
Max : 該類型的對象中，最大者的位元組數
Kind : 類型
分析某個對象，找出它的參考關聯性
複製代碼 代碼如下:
#得到所有的POP3ClientProtocol對象
p = om.get_all('POP3ClientProtocol')
#查看第一個對象
p[0]
#可以查看該對象的所有引用
p[0].c
#查看誰引用了這個對象
p[0].p
