記AELF區塊鏈網絡的一次內存持續增長問題排查

記AELF區塊鏈網絡的一次內存持續增長問題排查

背景：測試同學運行AElf單節點過程中，發現節點突然不再出塊，經查看日志發現 Worker（交易執行進程） 全部掉線，無法繼續執行交易，從而導致節點掛掉。

aelf的GitHub鏈接：https://github.com/AElfProject/AElf

初步定位問題：出現這個問題很奇怪，因為節點和所有 Worker 在同一臺服務器上，網絡通信應該不會有問題，再者發現，主節點、所有 Woker 和 Lighthouse 幾乎在同一時間全部掉線。然后繼續排查，通過 zabbix監控找到了問題，服務器在一個時間點內存幾乎被耗盡，通過觀察時間，發現與節點出現異常時間吻合。

復現問題：我們重點對內存使用進行測試。測試發現，隨著節點長時間運行，進程占用服務器內存在不斷增加，尤其在持續發了大量交易后，內存使用增長明顯，并且停止發交易后，內存也并不會下降。

下面是具體的復現步驟：
首先介紹服務環境，我們使用Ubuntu 16.04.5 LTS，dotnet core 版本為2.1.402

節點剛開始運行的情況：內存使用大約為90M

然后對節點持續發大量交易，我們可以通過監控看到節點交易池堆積大量交易并不斷在執行

持續一段時間后，內存占用已經達到1G

此時停止發交易，等待交易執行，我們通過監控看到交易池中的交易已都被執行。

等待一段時間后，此時我們繼續觀察內存占用，發現內存使用還是不會減少，一直保持1G 的水平

分析問題：

接下來我們使用lldb分析我們的節點。

首先在服務器上安裝 lldb

sudo apt-get install lldb

找到本機ibsosplugin.so位置

find /usr -name libsosplugin.so

啟動 lldb并附加到進程

sudo lldb –p 13067

加載libsosplugin.so

plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.4/libsosplugin.so

setclrpath /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.4/

首先分析下對象

dumpheap -stat

我們可以看到有大量的以下對象

AElf.Kernel.TransactionHolder

System.String

AElf.Common.Address

System.Collections.Concurrent.ConcurrentDictionary`2+Node[[AElf.Common.Hash,AElf.Common],[AElf.Kernel.TransactionHolder,AElf.Kernel.TxHub]]

AElf.Kernel.Transaction

AElf.Common.Hash

Google.Protobuf.ByteString

System.Byte[]

我們再看下大于1024字節對象

可以看有4個對象同類型的對象比較大

System.Collections.Concurrent.ConcurrentDictionary`2+Node[[AElf.Common.Hash, AElf.Common],[AElf.Kernel.TransactionHolder, AElf.Kernel.TxHub]][]

再進一步查看MethodTable對應的對象

可以看到有8個對象，其中4個較大，挑選其中一個查看對象信息，發現里面存儲了573437個值。

基于以上分析結果，排查對應源代碼，定位到類：AElf.Kernel.TxHub。該類主要作用是存儲交易池交易數據。該類包含8個ConcurrentDictionary<Hash, TransactionHolder>用于存儲交易數據，而TransactionHolder類中有存儲了Hash、Transaction 等類型，與上面內存分析的結果吻合。再繼續看內部邏輯，發現所有交易進入交易池后一直存儲在TxHub中，不再進行釋放。到此為止基本上定位問題所在。

待問題修復后重復上面步驟進行驗證，效果比較明顯，待交易池交易執行完畢后，內存占用有明顯下降，最終內存占用如下

繼續看下內存中對象的情況，可以看到對象總數也有了明顯的下降。

但是仍存在內存少量增長的現象，并且有大對象駐留內存的情況，此問題會進一步跟進分析。