問題描述
今天bithumb發(fā)公告上ENJ和PST這兩個(gè)幣種。我在外面準(zhǔn)備陪我媽去中山则拷，收到這個(gè)公告消息的時(shí)候停高興的孕索，以為我的自動交易系統(tǒng)會買入這兩個(gè)幣，還興沖沖的讓親愛的去幫我去gate上面賣出以為存在的PST薪棒。結(jié)果卻發(fā)現(xiàn)我并沒有買入PST手蝎，回到家中后檢查發(fā)現(xiàn)是我的服務(wù)器掛了。
初步原因分析
因?yàn)槲覍Ξ惓５奶幚硎翘貏e的完善了俐芯，而且log里面也沒有有異常導(dǎo)致服務(wù)器掛掉的字樣棵介，所以初步判斷是由于服務(wù)器資源消耗太多，使得服務(wù)器將我的程序殺掉了吧史，這點(diǎn)從vultr的服務(wù)器數(shù)據(jù)圖表也可以看得出來邮辽。
從日志中，我知道服務(wù)器掛掉的時(shí)候約為26號22點(diǎn)贸营，這點(diǎn)跟圖表上面的數(shù)據(jù)高度吻合吨述。
從圖表上面看，最有可能的原因是程序在往硬盤上面瘋狂的讀數(shù)據(jù)钞脂，導(dǎo)致被服務(wù)器殺死锐极，這點(diǎn)特別的詭異。
我的代碼當(dāng)中涉及到讀數(shù)據(jù)相關(guān)的操作有如下幾種
1芳肌、讀取配置文件
2灵再、讀取數(shù)據(jù)庫中的數(shù)據(jù)
那么可能的原因是什么
這個(gè)問題比較難解決，復(fù)現(xiàn)一下可能更好點(diǎn)
現(xiàn)在我有一個(gè)新的思路亿笤，就是模擬不斷讀取配置文件或者讀取數(shù)據(jù)庫中數(shù)據(jù)的過程翎迁，來復(fù)現(xiàn)這個(gè)過程，看它們表現(xiàn)十分一致净薛。
當(dāng)我準(zhǔn)備驗(yàn)證這兩個(gè)的時(shí)候汪榔，我發(fā)現(xiàn)了另外一種可能性，通過對var/log/message日志的查看肃拜，我發(fā)現(xiàn)上面說的是內(nèi)存不足痴腌，所以殺死了我的程序。
通過觀察燃领，我發(fā)現(xiàn)list pump運(yùn)行后占用的內(nèi)存比例一直在上升士聪。
那么從目前來看，內(nèi)些泄漏的可能性更大了猛蔽，內(nèi)存泄漏使得內(nèi)存的全都被占用剥悟，然后觸發(fā)了系統(tǒng)回收操作。在系統(tǒng)回收操作的過程中曼库，會讀取硬盤区岗，所以出現(xiàn)了硬盤讀取量特別大的現(xiàn)象。
驗(yàn)證猜想
我將程序拆分為兩個(gè)部分毁枯，獲取數(shù)據(jù)和獲取公告慈缔，將兩個(gè)部分單獨(dú)運(yùn)行，發(fā)現(xiàn)獲取公告的部分占用內(nèi)存一直在增長种玛，確認(rèn)內(nèi)存泄漏時(shí)在公告部分藐鹤。
按照相同的思路颅拦，最后發(fā)現(xiàn)內(nèi)存增長的最快的事在bittrex公告這塊。
但是bittrex這塊并沒有發(fā)現(xiàn)內(nèi)存謝羅的可疑操作教藻，目前懷疑是因?yàn)閎ittrex一次會獲取兩百多條數(shù)據(jù)，而這兩百多條數(shù)據(jù)都會一次執(zhí)行一系列mongodb操作右锨，我認(rèn)為內(nèi)存泄漏存在mongodb操作當(dāng)中括堤，它們分別是
find_one
count: 如果find_one未找到相同數(shù)據(jù)才會執(zhí)行count
update
insert
經(jīng)過測試，發(fā)現(xiàn)是pymongo 3.7.1這個(gè)版本你的find_one接口會導(dǎo)致內(nèi)存泄漏绍移，應(yīng)該我之前使用的pymongo3.5.1悄窃，所以沒有這個(gè)問題。在vps卸載重裝后蹂窖，這個(gè)問題應(yīng)該基本解決轧抗。
