精品人妻码一区二区三区_无码人妻久久一区二区三区免费丨_久久见久久久国产精品蜜桃_人嘼皇bestialitysex欧美

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

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

一、故障描述

TG圖數據(ju)(ju)庫集群狀(zhuang)態gadmin status均為(wei)(wei)正常(chang)工作(zuo)狀(zhuang)態，m1、m2、m3節(jie)點間連接狀(zhuang)態均為(wei)(wei)正常(chang)，且TG所使用端口(kou)無被占(zhan)用情況(kuang)。在(zai)跑生產(chan)批(pi)量日(ri)更腳本中加(jia)載(zai)數據(ju)(ju)部分時，發現加(jia)載(zai)任(ren)(ren)務(wu)(wu)有一定(ding)幾率(lv)卡住在(zai)讀取文件(jian)步驟，且卡住后(hou)(hou)未產(chan)生報錯日(ri)志和加(jia)載(zai)任(ren)(ren)務(wu)(wu)日(ri)志。經TG的(de)Abort命(ming)令(ling)打(da)斷當(dang)前加(jia)載(zai)任(ren)(ren)務(wu)(wu)后(hou)(hou)重新(xin)(xin)運(yun)行(xing)多(duo)次該加(jia)載(zai)任(ren)(ren)務(wu)(wu)，故障依舊；gadmin start命(ming)令(ling)重啟集群后(hou)(hou)，可成功(gong)運(yun)行(xing)該加(jia)載(zai)任(ren)(ren)務(wu)(wu)；重啟后(hou)(hou)仍有一定(ding)幾率(lv)重新(xin)(xin)發生此故障。

簡單來(lai)說，在無人干預的(de)情況下，原(yuan)來(lai)正(zheng)常(chang)的(de)數據(ju)導入進程(cheng)會(hui)hang死。重啟(qi)后正(zheng)常(chang)一段時(shi)間后，又會(hui)繼續hang死，且圖數據(ju)庫層面通訊的(de)兩(liang)端組(zu)件都沒有(you)收到報錯。

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

二、排查過程

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

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

經(jing)采(cai)用小批量數(shu)據(ju)進(jin)行(xing)測(ce)試并(bing)進(jin)行(xing)后臺日志監控，我們發現(xian)(xian)一(yi)個特殊的(de)(de)現(xian)(xian)象：集群(qun)主節(jie)點(dian)(dian)m1不能(neng)接(jie)(jie)(jie)收(shou)到加載任務，而m2、m3可以接(jie)(jie)(jie)收(shou)到，那是否可以說明(ming)(ming)這其實(shi)是一(yi)個節(jie)點(dian)(dian)通訊(xun)的(de)(de)問題？但是我們緊接(jie)(jie)(jie)著分別(bie)對m1、m2、m3進(jin)行(xing)多次的(de)(de)測(ce)試，故(gu)障依然存在(zai)。這說明(ming)(ming)不光是 m1 主節(jie)點(dian)(dian)無(wu)法和其他(ta)節(jie)點(dian)(dian)通信，其他(ta)節(jie)點(dian)(dian)之間(jian)也會不定時(shi)無(wu)法建(jian)立連接(jie)(jie)(jie)。隨著對數(shu)據(ju)流的(de)(de)逐(zhu)個環節(jie)的(de)(de)分析，發現(xian)(xian)是RESTPP_LOADER所在(zai)的(de)(de)節(jie)點(dian)(dian)無(wu)法接(jie)(jie)(jie)收(shou)到本節(jie)點(dian)(dian)所發的(de)(de)請求，如下(xia)圖所示，我們初步定位到了故(gu)障點(dian)(dian)：restpp-loader 嘗試去與8500端口建(jian)立連接(jie)(jie)(jie)的(de)(de)線程出現(xian)(xian)了異常。

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

遂在(zai)生(sheng)產(chan)環境裝(zhuang)(zhuang)有conductor、ctm等(deng)(deng)軟(ruan)(ruan)件(jian)的(de)(de)(de)其他節(jie)(jie)點(dian)，以及未(wei)安(an)(an)(an)裝(zhuang)(zhuang)上(shang)述(shu)軟(ruan)(ruan)件(jian)但系統環境大致相同的(de)(de)(de)兩(liang)個節(jie)(jie)點(dian)，分別成(cheng)功安(an)(an)(an)裝(zhuang)(zhuang)了TigerGraph單節(jie)(jie)點(dian)企業版。經測試，發現(xian)安(an)(an)(an)裝(zhuang)(zhuang)有conductor、ctm等(deng)(deng)軟(ruan)(ruan)件(jian)的(de)(de)(de)節(jie)(jie)點(dian)上(shang)的(de)(de)(de)TigerGraph復現(xian)了生(sheng)產(chan)環境三節(jie)(jie)點(dian)集群的(de)(de)(de)數據加載(zai)故障(zhang)，而未(wei)安(an)(an)(an)裝(zhuang)(zhuang)上(shang)述(shu)軟(ruan)(ruan)件(jian)的(de)(de)(de)節(jie)(jie)點(dian)可正常運行(xing)所有任務(wu)，無故障(zhang)產(chan)生(sheng)。經行(xing)內老(lao)師協調，臨(lin)時(shi)關閉(bi)了生(sheng)產(chan)節(jie)(jie)點(dian)的(de)(de)(de)conductor和ctm服務(wu)，但故障(zhang)依然(ran)存在(zai)，且故障(zhang)依然(ran)為GSE與RESTPP組件(jian)通信受阻(zu)導(dao)致。

如下圖顯示，簡單來說(shuo)，在有(you)其(qi)他軟件的環(huan)境(jing)會出現(xian)故障(zhang)，在“干凈”的環(huan)境(jing)中(zhong)正(zheng)常運行(xing)，關掉其(qi)他軟件依然有(you)故障(zhang)復(fu)現(xian)。那(nei)么(me)真相直接指向唯一的一個方向：由于安(an)裝其(qi)他軟件，修改了某項系(xi)統配置，引發了這個故障(zhang)。

問題分析到這里，我(wo)們再次回過頭去分析哪些系(xi)統配(pei)置可能影響端口的(de)情況。

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

接下(xia)來分成兩(liang)個方向進行排查：

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

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

令我(wo)們困(kun)惑的(de)一點是，在(zai)debug日志中只能看到某一次程(cheng)序從(cong)(cong)線程(cheng)池中取得線程(cheng)，并(bing)去建(jian)立連(lian)接，并(bing)且(qie)(qie)建(jian)立了連(lian)接！但是這(zhe)個連(lian)接從(cong)(cong)此就消失了，并(bing)且(qie)(qie)從(cong)(cong)系統的(de)nestat無(wu)法(fa)找到？！這(zhe)是讓我(wo)們百思不得其解的(de)一點。

程(cheng)序認為(wei)連接(jie)已(yi)經建立(li)(li)，系統中卻找不(bu)到建立(li)(li)的連接(jie)，那么這個連接(jie)去哪(na)里了？

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

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

如果您能有(you)耐心看到(dao)這里，想必也(ye)能或(huo)多或(huo)少體會(hui)到(dao)這個(ge)(ge)問題的詭(gui)異(yi)程(cheng)度(du)。已經(jing)可以(yi)確(que)認就(jiu)是端口之間(jian)通訊的問題，但(dan)是又找不到(dao)這個(ge)(ge)“隱身”的連接到(dao)底去哪了？

在系統(tong)運行(xing)一(yi)晚后，我們分析了監控日志，我們發現(xian)在某一(yi)個時刻連接自己(ji)8500端口(kou)的(de)線程(cheng)突然(ran)消失了。

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

但是(shi)在他(ta)的描述(shu)中(zhong)出現了self connection ，這個詞就(jiu)像一道閃電(dian)，照亮了整個黑(hei)暗(an)。我(wo)再(zai)次聯系(xi)美國(guo)開發，他(ta)也立(li)馬反(fan)應過來，去查(cha)看關鍵的系(xi)統配置(zhi)項，果然真相大白，我(wo)們苦(ku)苦(ku)追尋的配置(zhi)項就(jiu)是(shi)下圖(tu)中(zhong)的：

正(zheng)常的(de)配置應該是如下：

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

/proc/sys/net/ipv4/ip_local_port_range

的32768  60999被修(xiu)改(gai)為1025  65535。在這(zhe)個配(pei)置修(xiu)改(gai)后(hou)(hou)，客(ke)戶(hu)端(duan)(duan)在申(shen)請隨機端(duan)(duan)口(kou)連(lian)接(jie)服務(wu)端(duan)(duan)的時候，有一定概率申(shen)請到8500端(duan)(duan)口(kou)，從8500端(duan)(duan)口(kou)去與(yu)8500端(duan)(duan)口(kou)建立(li)自連(lian)接(jie)，從而(er)導致(zhi)TigerGraph組件認為連(lian)接(jie)建立(li)，而(er)系(xi)統卻認為服務(wu)未建立(li)，進而(er)導致(zhi)整(zheng)個導入(ru)功能的異常(chang)。而(er)重啟過后(hou)(hou)能正常(chang)一段時間的原因就(jiu)是在圖數據庫進程關閉后(hou)(hou)，在8500端(duan)(duan)口(kou)隱身的線程連(lian)接(jie)也會(hui)被系(xi)統回收。

為了(le)保險起見，根(gen)據這個原(yuan)因，我們(men)在多(duo)個安(an)裝且正常運行TigerGraph的環(huan)境(jing)(jing)中修改了(le)系統配置，并(bing)都復現(xian)了(le)生產(chan)環(huan)境(jing)(jing)的故(gu)障(zhang)。

到此(ci)為止，我們完全確定了故障的(de)發生(sheng)原因。

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

故(gu)障由(you)/proc/sys/net/ipv4/ip_local_port_range的默(mo)認配置(zhi)被修改(gai)導致，行內老師(shi)協調，將該設(she)置(zhi)還(huan)原系統默(mo)認設(she)置(zhi)，以解決TigerGraph加載故(gu)障。

具體步驟如下：

經由行(xing)內老師內部自檢及(ji)評估后，暫(zan)未發現(xian)該(gai)系統設置被修(xiu)改原因，遂將該(gai)設置修(xiu)改回系統默認設置，TigerGraph再(zai)也沒有出現(xian)該(gai)加載故障。

四、故障總結

在(zai)本次故(gu)障排(pai)除的(de)過(guo)程中，我(wo)們(men)面對的(de)是(shi)一個(ge)復雜(za)的(de)分(fen)布式(shi)系(xi)統(tong)環(huan)境(jing)，系(xi)統(tong)環(huan)境(jing)本身與其他環(huan)境(jing)不同，而且在(zai)這(zhe)個(ge)環(huan)境(jing)中還有(you)多個(ge)軟(ruan)件的(de)潛(qian)在(zai)干擾。這(zhe)個(ge)時候需(xu)要我(wo)們(men)冷靜(jing)的(de)采(cai)用枚舉法列出所有(you)可(ke)能的(de)故(gu)障原因，再通(tong)過(guo)控制變量(liang)法和排(pai)除法逐一去除干擾因素。排(pai)除一切不可(ke)能的(de)因素后，剩下的(de)肯定(ding)是(shi)正確(que)的(de)答(da)案。

在定(ding)位到系統級別的(de)問(wen)題時，應該(gai)第一時間檢查相關(guan)(guan)(guan)關(guan)(guan)(guan)鍵(jian)配置項。首(shou)先，我(wo)們需要(yao)(yao)定(ding)時監控維護這(zhe)些配置項。在這(zhe)次排除后(hou)，我(wo)們也(ye)無從得知到底(di)是什么原因這(zhe)個(ge)配置項被(bei)修改(gai)了。這(zhe)警示我(wo)們可能在平時的(de)工作需要(yao)(yao)關(guan)(guan)(guan)注這(zhe)個(ge)方面(mian)。第二是需要(yao)(yao)了解(jie)這(zhe)些系統參(can)數(shu)的(de)含義和配置方法，這(zhe)就需要(yao)(yao)我(wo)們不斷對自己的(de)技術進行提高。

這(zhe)(zhe)(zhe)次(ci)排(pai)查問題，我(wo)們(men)從圖數(shu)據庫產品(pin)本身(shen)技(ji)(ji)(ji)術(shu)架構，組件(jian)功能原(yuan)理，到linux系統運行機制，考慮了很(hen)多技(ji)(ji)(ji)術(shu)問題和(he)可能原(yuan)因，這(zhe)(zhe)(zhe)對我(wo)們(men)提出了很(hen)大的(de)挑(tiao)戰(zhan)(zhan)。所(suo)幸(xing)這(zhe)(zhe)(zhe)次(ci)有美國原(yuan)廠技(ji)(ji)(ji)術(shu)力(li)量并肩(jian)作戰(zhan)(zhan)，最終取得勝利，但是這(zhe)(zhe)(zhe)次(ci)問題也鞭策(ce)我(wo)們(men)平時需(xu)要廣泛的(de)去(qu)學(xue)習技(ji)(ji)(ji)術(shu)知識，并在(zai)自己(ji)的(de)技(ji)(ji)(ji)術(shu)領(ling)域持(chi)續(xu)深耕(geng)，正所(suo)謂博觀而約取，厚(hou)積而薄發。只(zhi)有這(zhe)(zhe)(zhe)樣，在(zai)考驗來臨(lin)時，我(wo)們(men)才能舉重若(ruo)輕的(de)解決，為客戶創造價值。