精品国产乱码久久久久久_精品人妻人人做人人爽夜夜爽_再深点灬舒服灬太大了少妇_偷偷色噜狠狠狠狠的777米奇

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

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

一、故障描述

TG圖(tu)數(shu)據(ju)庫(ku)集(ji)群狀(zhuang)態gadmin status均為正常(chang)工(gong)作(zuo)狀(zhuang)態，m1、m2、m3節點(dian)間(jian)連接狀(zhuang)態均為正常(chang)，且TG所使用端口無被(bei)占用情況。在(zai)(zai)跑生產批量日(ri)更腳本中加(jia)(jia)載(zai)(zai)數(shu)據(ju)部分時(shi)，發(fa)現(xian)加(jia)(jia)載(zai)(zai)任務(wu)有一定(ding)幾率卡(ka)(ka)住在(zai)(zai)讀(du)取文件步驟，且卡(ka)(ka)住后(hou)未產生報錯日(ri)志和加(jia)(jia)載(zai)(zai)任務(wu)日(ri)志。經TG的Abort命(ming)(ming)令打斷當前(qian)加(jia)(jia)載(zai)(zai)任務(wu)后(hou)重(zhong)新運行(xing)多次該加(jia)(jia)載(zai)(zai)任務(wu)，故(gu)障依舊；gadmin start命(ming)(ming)令重(zhong)啟集(ji)群后(hou)，可成功運行(xing)該加(jia)(jia)載(zai)(zai)任務(wu)；重(zhong)啟后(hou)仍(reng)有一定(ding)幾率重(zhong)新發(fa)生此故(gu)障。

簡單來說，在無(wu)人干預(yu)的(de)情況下，原來正(zheng)常的(de)數據(ju)導入(ru)進程會hang死(si)。重啟后(hou)正(zheng)常一(yi)段時間后(hou)，又會繼(ji)續(xu)hang死(si)，且圖數據(ju)庫(ku)層面通訊的(de)兩端組(zu)件都沒有(you)收到報錯(cuo)。

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

二、排查過程

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

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

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

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

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

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

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

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

接下來分(fen)成兩個方(fang)向(xiang)進行排查：

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

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

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

程序認為連接已經建(jian)立，系統中卻找不到建(jian)立的連接，那么這個(ge)連接去(qu)哪里了？

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

既然從(cong)產(chan)品層(ceng)面無法獲得(de)更多(duo)信(xin)息，我們把思(si)路轉向(xiang)系統(tong)層(ceng)面，通(tong)過監控系統(tong)的進程情(qing)況(kuang)(kuang)和網絡情(qing)況(kuang)(kuang)，來定(ding)位到(dao)故障發生的瞬間，到(dao)底(di)發生了什么。

如果您能(neng)有耐心看(kan)到(dao)(dao)這里(li)，想必(bi)也能(neng)或(huo)多或(huo)少體會到(dao)(dao)這個問題(ti)(ti)的詭(gui)異程度。已(yi)經可以確認就是(shi)端口之間通訊(xun)的問題(ti)(ti)，但(dan)是(shi)又找不到(dao)(dao)這個“隱身(shen)”的連接到(dao)(dao)底去哪了(le)？

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

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

但是在(zai)他的(de)(de)描述中出現(xian)了self connection ，這個詞就像一(yi)道閃電，照亮了整個黑暗。我再次聯系(xi)美國開(kai)發(fa)，他也立馬反應過來，去查看關(guan)鍵的(de)(de)系(xi)統配置(zhi)項(xiang)，果然真相(xiang)大(da)白，我們苦(ku)苦(ku)追尋的(de)(de)配置(zhi)項(xiang)就是下圖(tu)中的(de)(de)：

正常的配置(zhi)應該是(shi)如下：

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

/proc/sys/net/ipv4/ip_local_port_range

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

為(wei)了保險起見，根據這(zhe)個原因，我(wo)們在多個安裝且正(zheng)常(chang)運行TigerGraph的(de)環(huan)(huan)境中修改(gai)了系統配置，并都復現了生產環(huan)(huan)境的(de)故(gu)障。

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

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

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

具體步驟(zou)如下(xia)：

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

四、故障總結

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

在(zai)定(ding)位到系(xi)統(tong)級別的問題(ti)時(shi)，應該第一時(shi)間檢查相關(guan)關(guan)鍵配(pei)置項(xiang)。首先，我(wo)們(men)需(xu)(xu)要定(ding)時(shi)監(jian)控(kong)維護這些(xie)配(pei)置項(xiang)。在(zai)這次(ci)排(pai)除后，我(wo)們(men)也(ye)無從得知到底是什么原因這個配(pei)置項(xiang)被修(xiu)改(gai)了。這警示我(wo)們(men)可能在(zai)平時(shi)的工(gong)作(zuo)需(xu)(xu)要關(guan)注這個方面。第二是需(xu)(xu)要了解這些(xie)系(xi)統(tong)參數的含義(yi)和(he)配(pei)置方法，這就(jiu)需(xu)(xu)要我(wo)們(men)不斷對(dui)自己的技術進行提高。

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