GaussDB for DWS Hang問題定位指南

1?Hang問題基礎(chǔ)知識

GaussDB for DWS 為分布式數(shù)據(jù)庫，通常由于單節(jié)點亞健康、系統(tǒng)資源緊張或查詢本身的計劃等問題，造成系統(tǒng)疑似發(fā)生Hang。Hang問題的產(chǎn)生原因由很多種，比如，死鎖等待、日志同步等待、事務(wù)超時、通信故障、數(shù)據(jù)溢出發(fā)生死循環(huán)等等，更為常見的是由于執(zhí)行慢、中間結(jié)果集傾斜而導(dǎo)致的疑似Hang。掌握Hang問題的基本定位方法對于大集群環(huán)境下快速找準(zhǔn)疑似阻塞點，修復(fù)故障環(huán)境或優(yōu)化執(zhí)行性能是至關(guān)重要的。

1.1?常用視圖

目前，GaussDB for DWS對外提供諸多系統(tǒng)視圖，可以用來輔助Hang問題的分析定位，

常用視圖及用法說明如下表所示。（☆代表常用程度）

pgxc_stat_activity ☆☆☆

查詢當(dāng)前集群所有DN實例上各個session的信息，重點關(guān)注正在執(zhí)行(state狀態(tài)為active)的SQL。我們一般首先分析pgxc_stat_activity中的內(nèi)容，初步根據(jù)執(zhí)行時間篩選出疑似query，然后使用此query的query_id和視圖pgxc_thread_wait_status結(jié)合，獲取此query集群級別的線程狀態(tài)進行hang問題分析。

注：此視圖需要以超級用戶的身份來運行

在問題分析時，我們首先需要客戶反饋的疑似hang的作業(yè)的信息，根據(jù)作業(yè)所在的databse、運行作業(yè)的用戶身份、運行作業(yè)客戶端以及運行作業(yè)所連接的實例CN名稱初步篩選出問題SQL的運行信息，具體運行信息見附件中字段含義解釋。比如疑似hang作業(yè)是以omm用戶運行在postgres數(shù)據(jù)庫連接到cn_5001實例上運行的，我們使用如下SQL進行作業(yè)狀態(tài)查詢

我們可以根據(jù)上述返回的結(jié)果，結(jié)合作業(yè)運行的客戶端名稱、客戶端ip、作業(yè)query運行開始時間query_start進一步篩選出疑似hang作業(yè)。

【附：視圖各字段含義】

pgxc_thread_wait_status ?☆☆☆☆☆

查詢集群全局所有線程的層次調(diào)用關(guān)系及阻塞等待情況，通常在視圖查詢語句增加其他過濾條件（比如根據(jù)pgxc_stat_activity篩選出來的疑似hang的SQL的query_id），縮小關(guān)注排查范圍。

【附：視圖各字段含義】

pg_thread_wait_status ?☆☆☆☆

單個實例上所有作業(yè)線程的層次調(diào)用關(guān)系及阻塞等待情況，在大集群復(fù)雜query問題定位時，視圖pgxc_thread_wait_status返回的信息過多，會對問題定位形成一定干擾，這時可以在CN上通過execute direct on語法獲取指定dn實例的作業(yè)線程信息。比如要獲取dn_6001_dn_6002節(jié)點的作業(yè)線程調(diào)用信息

pgxc_comm_recv_stream ?☆☆☆

查詢集群所有DN的通信庫接收流狀態(tài)，輔助通信層發(fā)生收發(fā)Hang的排查定位。

pgxc_comm_send_stream ?☆☆☆

查詢集群所有DN的通信庫發(fā)送流狀態(tài)，與pgxc_comm_recv_stream視圖結(jié)合使用，來定位通信層的收發(fā)Hang問題。

pgxc_prepared_xacts ?☆☆

查詢集群中所有節(jié)點的啟動事務(wù)信息，輔助事務(wù)超時場景下的Hang問題定位，通過查詢該視圖獲取gxid，然后結(jié)合pgxc_xacts_iscommitted(gxid)可以獲知事務(wù)是否提交。

pgxc_running_xacts ?☆☆

查詢集群中所有節(jié)點的運行事務(wù)信息。

pg_locks ?☆☆

查詢當(dāng)前實例的鎖狀態(tài)，輔助死鎖等待的Hang問題定位。

pgxc_node ?☆☆

查詢集群中所有實例節(jié)點信息，重點關(guān)注節(jié)點的node_name, node_port, node_id。

除過上述常用視圖，Hang問題定位過程需要根據(jù)實際場景，結(jié)合執(zhí)行計劃、gstack工具、系統(tǒng)日志等共同分析定位。

1.2?簡單示例

比如在執(zhí)行create table的時候疑似發(fā)生hang，那么我們可以執(zhí)行以下操作定位問題

1.?獲取疑似hang的SQL的query_id

select * from pgxc_stat_activity where state = ‘a(chǎn)ctive’ and lower(query) like ‘create table %’;

2.?獲取此作業(yè)的線程等待關(guān)系

select * from pgxc_thread_wait_status where query_id = xx;

xx：為上一步獲取的疑似hang的SQL的query_id值

分析此query_id相關(guān)的線程的狀態(tài)(字段wait_status)，查看是否有acquire lock狀態(tài)的線程，找到其node_name?和 tid字段

3.?到對應(yīng)的node_name上獲取鎖信息

execute direct on (xx) ‘select * from pg_locks where pid?=?xxx’;

--xx: 上一步獲取的node_name字段的值

--yy：上一步獲取的tid字段值。

獲取等待加鎖的表信息(字段relation)

4．到對應(yīng)的node_name上獲取此表的持鎖信息

execute direct on (xx) ‘select * from pg_locks where relation?=?yy?and granted = true’;

--xx: 第二步獲取的node_name字段的值

--yy: 第三步獲取的等待加鎖字段的值

獲取持鎖的線程(字段pid)

5．獲取持鎖的作業(yè)信息

select * from pgxc_stat_activity where pid=xx;

--xx: 第四步獲取持鎖線程信息

字段query的內(nèi)容即為持鎖線程信息，也是阻塞create table語句的作業(yè)信息

2?Hang問題分類

客戶側(cè)感知的hang分為三種

1.?真實hang

一般是輕量級鎖缺陷、執(zhí)行鏈路環(huán)狀或者死循環(huán)執(zhí)行。這種場景下作業(yè)永遠(yuǎn)無法執(zhí)行完

2.?執(zhí)行慢：

業(yè)務(wù)執(zhí)行慢，遠(yuǎn)遠(yuǎn)超出客戶的預(yù)期，客戶側(cè)產(chǎn)生hang的認(rèn)知效果。這種問題最終需要通過調(diào)優(yōu)解決

3.?鎖等待：

因搶占不到鎖資源，導(dǎo)致作業(yè)排隊等待加鎖。這種場景的表現(xiàn)是要么作業(yè)執(zhí)行時間邊長，要么等待一段時間(一般為20min)之后報鎖超時的失敗信息

根據(jù)以往的經(jīng)驗，局點常見的hang問題有以下幾種

3?Hang問題定位方法及解決措施

3.1?基本步驟

Step1. cm_ctl query查詢集群當(dāng)前狀態(tài)，確保集群狀態(tài)正常；

Step2. gsql連接數(shù)據(jù)庫，執(zhí)行select * from pgxc_stat_activity，查詢目標(biāo)查詢的query_id，有時候可以增加where state = ‘a(chǎn)ctive’篩選活躍SQL；

Step3. 執(zhí)行select * from pgxc_thread_wait_status?where query_id = xxx，查詢集群全局與之關(guān)聯(lián)的所有線程的層次調(diào)用關(guān)系及阻塞等待情況。自上而下，逐層分析，確定疑似阻塞節(jié)點及線程信息，甚至，可以繪制線程等待關(guān)系圖，更加直觀地分析當(dāng)前Hang問題的根因。除此，可結(jié)合執(zhí)行計劃或gstack查看線程堆棧，進一步佐證定位結(jié)論。

Step4. 如果Step3仍無定論，則針對其他常見Hang場景（目前以鎖等待和通信收發(fā)等待最為常見），結(jié)合2.1節(jié)相應(yīng)視圖，進一步分析定位：

a)?鎖等待：從Step3的查詢結(jié)果分析線程等待關(guān)系，如果阻塞線程狀態(tài)為acquire lock，則進一步執(zhí)行select * from pg_locks?where pid = xxx查詢阻塞線程的加鎖情況；

b)?通信層數(shù)據(jù)收發(fā)成環(huán)：從Step3的查詢結(jié)果分析線程等待關(guān)系，如果阻塞線程狀態(tài)一直為flush data: wait quota，則可能是通信層收發(fā)過程hang死，繼續(xù)執(zhí)行select * from pgxc_comm_send_stream和select * from pgxc_comm_recv_stream，可以根據(jù)Step3的查詢結(jié)果增加where條件限定node_name、remote_name、query_id、pn_id(即plevel)，進一步排查wait?quota的根因是否是發(fā)送端或接收端數(shù)據(jù)流異常或者通信問題等。

任務(wù)調(diào)度 數(shù)據(jù)倉庫服務(wù) GaussDB(DWS) SQL

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。