問題描述

今天bithumb發(fā)公告上ENJ和PST這兩個幣種。我在外面準(zhǔn)備陪我媽去中山，收到這個公告消息的時候停高興的，以為我的自動交易系統(tǒng)會買入這兩個幣，還興沖沖的讓親愛的去幫我去gate上面賣出以為存在的PST。結(jié)果卻發(fā)現(xiàn)我并沒有買入PST，回到家中后檢查發(fā)現(xiàn)是我的服務(wù)器掛了。

初步原因分析

因為我對異常的處理是特別的完善了，而且log里面也沒有有異常導(dǎo)致服務(wù)器掛掉的字樣，所以初步判斷是由于服務(wù)器資源消耗太多，使得服務(wù)器將我的程序殺掉了，這點(diǎn)從vultr的服務(wù)器數(shù)據(jù)圖表也可以看得出來。

vultr服務(wù)器圖表

從日志中，我知道服務(wù)器掛掉的時候約為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ù)

那么可能的原因是什么

這個問題比較難解決，復(fù)現(xiàn)一下可能更好點(diǎn)
現(xiàn)在我有一個新的思路，就是模擬不斷讀取配置文件或者讀取數(shù)據(jù)庫中數(shù)據(jù)的過程，來復(fù)現(xiàn)這個過程，看它們表現(xiàn)十分一致。
當(dāng)我準(zhǔn)備驗證這兩個的時候，我發(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)象。

驗證猜想

我將程序拆分為兩個部分，獲取數(shù)據(jù)和獲取公告，將兩個部分單獨(dú)運(yùn)行，發(fā)現(xiàn)獲取公告的部分占用內(nèi)存一直在增長，確認(rèn)內(nèi)存泄漏時在公告部分。
按照相同的思路，最后發(fā)現(xiàn)內(nèi)存增長的最快的事在bittrex公告這塊。
但是bittrex這塊并沒有發(fā)現(xiàn)內(nèi)存謝羅的可疑操作，目前懷疑是因為bittrex一次會獲取兩百多條數(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這個版本你的find_one接口會導(dǎo)致內(nèi)存泄漏，應(yīng)該我之前使用的pymongo3.5.1，所以沒有這個問題。在vps卸載重裝后，這個問題應(yīng)該基本解決。