SQL下盤導致磁盤IO高問題分析

背景及現象描述(Background and Symptom)*

1.??? ? 環境信息：

GaussDB A 8.0.0版本12節點集群

2.??? ? 問題現象：

客戶反映業務執行慢，原本幾分鐘的業務一個小時都跑不完，造成大量業務累計。

3.?????? 分析過程

1.?????? 初步分析為客戶連接數過高導致IO高，限制連接數后IO稍有回落，后續IO又升高至95%以上

且限制連接數后嚴重影響用戶使用

2.?????? 連到數據庫，查用線程的id，查pgxc_thread_wait_status，可以找到對應語句的query_id

可以看到該sql處理flush data狀態

3.?????? 檢查下盤文件，發現每個數據目錄下均有不等的下盤文件，且個別sql的下盤文件數達到3000+

下盤文件中間部分的id為query_id，根據query_id找到對應的sql

與業務側同事確認該sql不合理，需要整改

4.?????? 確認work_mem設置大小

當前集群work_mem設置為512MB，設置的過小導致下盤情況容易產生，目前調整為3GB

原因分析(Cause Analysis)*

當work_mem設置較小場景時，會產生大量的下盤，時時在數據盤上讀寫文件，導致數據盤讀寫IO繁忙，因此影響其他業務運行。

解決辦法(Solution)*

（1）?????? 調整work_mem,使其滿足大部分業務的使用場景

（2）?????? 整改不合理業務，使客戶系統運行更順暢。

數據倉庫服務 GaussDB(DWS) SQL EI企業智能 Gauss AP

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

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