GaussDB(DWS)性能問題處理套路

對于性能問題，這邊習慣將其按照范圍和影響分為單點性能問題和系統(tǒng)級性能問題，單點性能問題大多直接轉變成單SQL調優(yōu)，而系統(tǒng)級性能問題因其復雜性往往處理起來比較費時費力，在此根據歷史性能問題的處理經驗總結一份套路，旨在指導大家在碰到DWS性能問題時有法可依，主要包含問卷和三階段排查兩個部分。

問卷

主要為和客戶快速確認性能慢的初步信息，用來快速排除低級的非數(shù)據庫服務側的問題，并大致明確問題范圍和影響：

在完成上面的問卷并明確問題范圍和影響后，如果確定是整體業(yè)務性能都比歷史慢且未識別出明顯的業(yè)務變化，則開始后續(xù)三階段排查。

階段一 集群健康度

1、集群狀態(tài)

集群狀態(tài)異常、不均衡均會影響業(yè)務的整體運行效率，所以確定集群狀態(tài)正常和均衡是整體性能穩(wěn)定的首要保證。

處理方式：集群修復、集群均衡（主備切換）

集群修復：https://bbs.huaweicloud.com/blogs/detail/198733

主備切換：https://bbs.huaweicloud.com/forum/thread-140502-1-1.html

2、可服務性

在檢查集群狀態(tài)正常的情況下，還存在服務對外不可提供服務的可能，從而影響整體業(yè)務進度，最常見為某CN hang，所以通過建連、建表來快速確認CN、DN的基礎可服務性。

處理方式：gstack保留hang實例進程棧后，重啟或隔離CN/DN進行快速恢復

單節(jié)點重啟或隔離： https://bbs.huaweicloud.com/forum/thread-147714-1-1.html

單實例重啟或隔離： https://bbs.huaweicloud.com/forum/thread-147713-1-1.html

多CN隔離：https://bbs.huaweicloud.com/forum/thread-147718-1-1.html

3、資源瓶頸

性能問題尤其是系統(tǒng)級性能問題大多伴隨著某類系統(tǒng)資源（CPU/IO/內存/網絡）的瓶頸，快速檢查集群的整體資源使用情況有利于快速縮小問題范圍。

1、線下集群的資源使用情況使用FI Manger管理界面查看：

2、公有云集群資源使用情況使用DWS-console管理界面查看：

3、混合云集群資源使用情況可隨機抽取CN/DN使用top/iostat/free初步排查資源使用情況。

處理方式：對整體的資源使用情況有大致的把握后繼續(xù)進行后續(xù)排查，并在后續(xù)每個排查措施實施后，觀察對應飆高資源是否回落。

階段二 業(yè)務狀態(tài)

1、爛SQL清理

處理方式：和客戶溝通對執(zhí)行時間長的sql進行查殺，觀察其他業(yè)務和資源恢復情況，若恢復則進入對被查殺SQL的調優(yōu)環(huán)節(jié)，否則繼續(xù)進行后續(xù)排查

業(yè)務SQL查殺：https://bbs.huaweicloud.com/forum/thread-147712-1-1.html

2、業(yè)務阻塞點

1）長時間wait某個節(jié)點

2）長時間wait某類資源

其中等待狀態(tài)含義參見：https://support.huaweicloud.com/devg2-dws/dws_0402_0863.html

部分狀態(tài)舉例說明：

wait node：等待其他CN/DN節(jié)點，可能為慢節(jié)點

wait io：等待讀寫，可能為IO問題

wait pooler：等待內部建連，可能為網絡問題

acquire lock：等鎖，對相同表并發(fā)操作導致

acquire lwlock：等輕量級鎖，并發(fā)高導致內部

問題1：針對IO、網絡等資源方面的問題參考階段三 系統(tǒng)狀態(tài)中處理

問題2：針對LOCK的問題參考：

鎖等待場景：https://bbs.huaweicloud.com/blogs/233114

死鎖的場景：https://bbs.huaweicloud.com/blogs/228840

3、業(yè)務并發(fā)

1）并發(fā)數(shù)長期維持高位

2）各CN上業(yè)務分布不均

執(zhí)行多次，check整體負載及CN負載均衡

問題1：并發(fā)高（在前面明顯的爛SQL已經清理的情況下）如伴隨著cpu、內存等整體資源瓶頸，則需降低業(yè)務并發(fā)度并繼續(xù)觀察（并發(fā)值根據實際業(yè)務情況實測、壓測最終明確）：

CN級并發(fā)調整(max_active_statements)：https://bbs.huaweicloud.com/blogs/179009

用戶級并發(fā)調整：https://bbs.huaweicloud.com/forum/thread-74904-1-1.html

問題2：CN上分布不均（部分CN排隊嚴重）

線下建議部署LVS：https://bbs.huaweicloud.com/forum/thread-145807-1-1.html

無法部署LVS和ELB的場景建議客戶將應用業(yè)務分散到不同CN執(zhí)行（應用指定）

4、業(yè)務排隊

說明：pgxc_session_wlmstat需手動創(chuàng)建，請參考https://bbs.huaweicloud.com/blogs/278874

問題1：Global狀態(tài)的排隊多：觸發(fā)全局max_active_statements閾值

問題2：Respool狀態(tài)的排隊多：觸發(fā)資源池內存、并發(fā)限額，評估該用戶使用資源合理性

觸發(fā)資源池內存限額

觸發(fā)資源池max_active_statements限額

觸發(fā)資源池max_dop限額(僅針對簡單語句)

問題3：CentralQueue狀態(tài)的排隊多：觸發(fā)全局內存max_dynamic_memory限制，評估內存參數(shù)設置及業(yè)務使用內存情況

其中針對Global狀態(tài)排隊多問題：根據資源余量情況決策是否調大max_active_statements

其中針對Respool及CentralQueue類問題參考https://bbs.huaweicloud.com/blogs/222017

階段三 系統(tǒng)狀態(tài)

這里所說系統(tǒng)狀態(tài)主要指系統(tǒng)CPU、IO、內存、網絡等系統(tǒng)資源使用情況，導致這些系統(tǒng)資源不足的場景非常之多，且之間互相影響。

1、資源高（cpu/io/mem）

1）單節(jié)點資源瓶頸

分針對DWS分布式場景，單節(jié)點資源瓶頸大多為硬件、OS故障、業(yè)務傾斜導致，主要進行以下排查：

硬件、OS側排查重點：

排查bmc日志（常見IO問題如磁盤告警、磁盤讀寫策略、CPU節(jié)能模式）

排查messages日志（例歷史上出現(xiàn)過的主板故障導致CPU高）

業(yè)務側排查重點：

排查存儲傾斜：https://bbs.huaweicloud.com/blogs/183585

排查計算傾斜：https://bbs.huaweicloud.com/blogs/254845

排查Sharding業(yè)務（分布列作為過濾條件的點查）

泰山服務器有已知的網卡、內存等方面問題，需排查是否做過加固：

https://support.huawei.com/enterprise/zh/bulletins-product/ENEWS2000007743

使用top/iotop等工具明確消耗資源的進程為gaussdb進程，歷史上出現(xiàn)過殺毒軟件、ssh進程、getClientInfo進程導致CPU飆高的情況。

https://bbs.huaweicloud.com/forum/thread-74914-1-1.html

4）抓top資源業(yè)務

Top CPU消耗的業(yè)務抓取方法：

https://bbs.huaweicloud.com/forum/thread-70939-1-1.html

Top IO消耗的業(yè)務抓取方法：

https://bbs.huaweicloud.com/forum/thread-149502-1-1.html

Top內存消耗的業(yè)務抓取方法：

https://bbs.huaweicloud.com/forum/thread-110215-1-1.html

查殺方法：

https://bbs.huaweicloud.com/forum/thread-147712-1-1.html

針對單個業(yè)務導致的資源高，處理方法主要為SQL調優(yōu)。

針對批量業(yè)務導致的資源高，處理方法主要為SQL調優(yōu)或限并發(fā)（前提SQL已最優(yōu)）。

2、網絡慢

通信是分布式場景下的基礎建設，承擔著各節(jié)點數(shù)據交互的使命，通信效率的高低會極大影響著查詢等各類業(yè)務性能的好壞。

網絡慢大多體現(xiàn)在以下兩點：

1.客戶端連接滿、連接慢

處理案例：https://bbs.huaweicloud.com/blogs/239471

2.集群內節(jié)點建連慢、數(shù)據交互慢

計劃中Gather、Redistribute、Broadcast等通信算子耗時高

等待視圖中create conn、wait pooler等狀態(tài)持續(xù)時間長

通信性能問題處理方法及案例：https://bbs.huaweicloud.com/blogs/248843

小結

觸發(fā)數(shù)據庫性能問題的因素本就種類繁多，而在分布式場景更是這樣，任何一個節(jié)點、環(huán)節(jié)、鏈路出現(xiàn)問題和瓶頸，都會因短板效應影響整個集群的性能，因此快速識別短板（阻塞點）、瓶頸點（系統(tǒng)資源）就成為關鍵，而前面說的三個階段也是圍繞這兩個點進行。當然，也并不是所有場景都需要嚴格按照一二三的順序來排查，可以根據實際情況調整排查順序并且可能需要來回校驗來互相印證，希望大家能靈活運用。

EI企業(yè)智能 Gauss AP 應用性能調優(yōu) 數(shù)據倉庫服務 GaussDB(DWS)

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

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