技術人生系列——追蹤圖數據庫中“突然隱身”的通信連接

日期:2021-02-23

圖數據庫作為新興的數據庫技術熱點,正在廣泛的被各大銀行客戶采用。作為NoSQL數據庫中最為突出的代表,圖數據庫對目前各種比較火熱的精準營銷業務場景、風控業務場景、客戶圖譜場景都能提供強大的底層支持。中亦大數據產品團隊作為國內銀行業接觸圖數據庫較早的技術團隊,為各大客戶持續提供平臺層面的技術支持能力。

 

最近,我們在客戶現場的圖數據庫生產集群中遇到了一個罕見的通訊故障:數據庫的導入組件和內部組件的通信通道會不定時丟失,且再也無法建立。經過現場反復協調排查和遠程持續分析排查,并聯合了中亦工程師和美國原廠的核心技術力量,終于分析出引發故障的系統原因并最終排除了故障,整個過程歷經不少波折,真相大白水落石出時,大家都恍然大悟,原來是這樣簡單的原因——雖然答案和解決方案很簡單,但是在分析過程中,由于大數據復雜的技術架構,需要抽絲剝繭,逐個分析可能因素,所以相對于最終的結果,這樣的分析過程更值得記錄,借本期技術人生系列文章,分享給大家。

 

 

 

一、故障描述

 

TG圖數據庫集群狀態gadmin status均為正常工作狀態,m1、m2、m3節點間連接狀態均為正常,且TG所使用端口無被占用情況。在跑生產批量日更腳本中加載數據部分時,發現加載任務有一定幾率卡住在讀取文件步驟,且卡住后未產生報錯日志和加載任務日志。經TG的Abort命令打斷當前加載任務后重新運行多次該加載任務,故障依舊;gadmin start命令重啟集群后,可成功運行該加載任務;重啟后仍有一定幾率重新發生此故障。

 

簡單來說,在無人干預的情況下,原來正常的數據導入進程會hang死。重啟后正常一段時間后,又會繼續hang死,且圖數據庫層面通訊的兩端組件都沒有收到報錯。

 

圖片

 

通過上圖,我們可以了解到,TigerGraph圖數據庫導入的基本原理:

 

1、每個節點admin組件會有一個線程定時輪詢集群中每個節點的8500端口,嘗試建立TCP連接。

 

2、當某個節點,如m1節點開啟導入任務時,會開啟restpp-loader進程,監聽本地的8500端口,這時自然會和admin的線程建立連接。

 

3、通過建立好的tcp連接進行數據通信,由本地的restpp-loader讀取文件,數據轉換,傳送至admin和其他組件,從而進行下游的導入任務。

 

 

二、排查過程

 

1.初步排查定位原因

我們首先針對TigerGraph版本,License,Schema腳本和loading腳本、數據源格式及生產機器內存硬盤資源進行了一一檢查,均無發現異常。基本可以確定原有的流程是沒有邏輯上的問題。

 

緊接著,我們對圖數據庫產品底層組件一一進行了故障排查。首先是對TigerGraph的Kafka、Nginx、GPE、GSE、GSQL、ZooKeeper、DICT、TS3、Restpp等組件的檢查,經檢查發現產品各組件均正常運行,日志文件均無報錯情況。

 

經采用小批量數據進行測試并進行后臺日志監控,我們發現一個特殊的現象:集群主節點m1不能接收到加載任務,而m2、m3可以接收到,那是否可以說明這其實是一個節點通訊的問題?但是我們緊接著分別對m1、m2、m3進行多次的測試,故障依然存在。這說明不光是 m1 主節點無法和其他節點通信,其他節點之間也會不定時無法建立連接。隨著對數據流的逐個環節的分析,發現是RESTPP_LOADER所在的節點無法接收到本節點所發的請求,如下圖所示,我們初步定位到了故障點:restpp-loader 嘗試去與8500端口建立連接的線程出現了異常。

圖片

 

 

2.嘗試排除環境中其他軟件的干擾

 

首先我們可以判斷TigerGraph本身是沒有問題的,因為在研發環境一直都是正常運行的。那么就需要判斷是生產環境中安裝的其他軟件對TigerGraph造成了干擾,還是linux系統環境的不同導致了故障的發生。

 

遂在生產環境裝有conductor、ctm等軟件的其他節點,以及未安裝上述軟件但系統環境大致相同的兩個節點,分別成功安裝了TigerGraph單節點企業版。經測試,發現安裝有conductor、ctm等軟件的節點上的TigerGraph復現了生產環境三節點集群的數據加載故障,而未安裝上述軟件的節點可正常運行所有任務,無故障產生。經行內老師協調,臨時關閉了生產節點的conductor和ctm服務,但故障依然存在,且故障依然為GSE與RESTPP組件通信受阻導致。

 

如下圖顯示,簡單來說,在有其他軟件的環境會出現故障,在“干凈”的環境中正常運行,關掉其他軟件依然有故障復現。那么真相直接指向唯一的一個方向:由于安裝其他軟件,修改了某項系統配置,引發了這個故障。

圖片

 

3.設置監控腳本進行監控

 

問題分析到這里,我們再次回過頭去分析哪些系統配置可能影響端口的情況。

 

首先是看系統資源限制,發現配置都比較正常:

圖片

 

接下來分成兩個方向進行排查:

 

◆ 通過gdb在產品層面打斷點去分析

這個方向的考慮是希望在美國原廠的支持下,對TigerGraph圖數據庫進行調試,在導入組件內部通過打斷點的方式,發現組件層面的報錯。之前已經分析過了,在產品提供的通用日志中并沒有提供報錯信息,那么我們本質上是去提取debug級別的日志。

 

令我們困惑的一點是,在debug日志中只能看到某一次程序從線程池中取得線程,并去建立連接,并且建立了連接!但是這個連接從此就消失了,并且從系統的nestat無法找到?!這是讓我們百思不得其解的一點。

 

程序認為連接已經建立,系統中卻找不到建立的連接,那么這個連接去哪里了?

 

 

◆ 通過shell腳本在系統層去監控進程和網絡情況

既然從產品層面無法獲得更多信息,我們把思路轉向系統層面,通過監控系統的進程情況和網絡情況,來定位到故障發生的瞬間,到底發生了什么。

圖片

圖片

 

4.分析監控日志最終發現原因 

 

如果您能有耐心看到這里,想必也能或多或少體會到這個問題的詭異程度。已經可以確認就是端口之間通訊的問題,但是又找不到這個“隱身”的連接到底去哪了?

 

在系統運行一晚后,我們分析了監控日志,我們發現在某一個時刻連接自己8500端口的線程突然消失了。

圖片

 

我突然聯想到之前查到的一個資料:因為TigerGraph底層用了zmq進行通信,我在社區中看到一個人在2013年提交了一個issue,說他發現在大并發的情況下,他寫的單機程序會時不時的hang住,建議zmq修復這個bug。他遇到的問題和我們很像,但是這個issue沒有被fix,而是被關閉了,說明zmq的社區管理判斷他提的并不是一個真實的bug。

圖片

 

但是在他的描述中出現了self connection ,這個詞就像一道閃電,照亮了整個黑暗。我再次聯系美國開發,他也立馬反應過來,去查看關鍵的系統配置項,果然真相大白,我們苦苦追尋的配置項就是下圖中的:

正常的配置應該是如下:

圖片

 

該配置項是linux為了區分服務端程序可用端口和客戶端可用隨機端口而設置的,就是為了防止端口沖突。在這個故障中,TigerGraph所在集群的默認系統配置中

/proc/sys/net/ipv4/ip_local_port_range

的32768  60999被修改為1025  65535。在這個配置修改后,客戶端在申請隨機端口連接服務端的時候,有一定概率申請到8500端口,從8500端口去與8500端口建立自連接,從而導致TigerGraph組件認為連接建立,而系統卻認為服務未建立,進而導致整個導入功能的異常。而重啟過后能正常一段時間的原因就是在圖數據庫進程關閉后,在8500端口隱身的線程連接也會被系統回收。

 

為了保險起見,根據這個原因,我們在多個安裝且正常運行TigerGraph的環境中修改了系統配置,并都復現了生產環境的故障。

 

到此為止,我們完全確定了故障的發生原因。

 

 

三、故障修復方案制定與執行

1.修復方案

故障由/proc/sys/net/ipv4/ip_local_port_range的默認配置被修改導致,行內老師協調,將該設置還原系統默認設置,以解決TigerGraph加載故障。

具體步驟如下:

圖片

 

2.修復故障

經由行內老師內部自檢及評估后,暫未發現該系統設置被修改原因,遂將該設置修改回系統默認設置,TigerGraph再也沒有出現該加載故障。

 

 

四、故障總結

1.控制變量快速定位故障根源

在本次故障排除的過程中,我們面對的是一個復雜的分布式系統環境,系統環境本身與其他環境不同,而且在這個環境中還有多個軟件的潛在干擾。這個時候需要我們冷靜的采用枚舉法列出所有可能的故障原因,再通過控制變量法和排除法逐一去除干擾因素。排除一切不可能的因素后,剩下的肯定是正確的答案。

 

2.關鍵系統配置檢查

在定位到系統級別的問題時,應該第一時間檢查相關關鍵配置項。首先,我們需要定時監控維護這些配置項。在這次排除后,我們也無從得知到底是什么原因這個配置項被修改了。這警示我們可能在平時的工作需要關注這個方面。第二是需要了解這些系統參數的含義和配置方法,這就需要我們不斷對自己的技術進行提高。

 

3.廣泛積累夯實技術基礎、深入鉆研挖掘技術深度

這次排查問題,我們從圖數據庫產品本身技術架構,組件功能原理,到linux系統運行機制,考慮了很多技術問題和可能原因,這對我們提出了很大的挑戰。所幸這次有美國原廠技術力量并肩作戰,最終取得勝利,但是這次問題也鞭策我們平時需要廣泛的去學習技術知識,并在自己的技術領域持續深耕,正所謂博觀而約取,厚積而薄發。只有這樣,在考驗來臨時,我們才能舉重若輕的解決,為客戶創造價值。

 

 


鍛造凝煉IT服務 助推用戶事業發展
地址:北京市西城區百萬莊大街11號糧科大廈3層
電話:(010)58523737
傳真:(010)58523739
五彩堂