Hologres診斷與優化實踐總結我的介紹將分為五個部分：首先，在事前階段，講解如何利用監控指標實現實時監控和預防措施。其次，事中探討團隊如何通過活躍日誌發現運行中的問題，並及時採取措施止損，以避免業務問題的惡化。接下來，在事後階段介紹如何通過深入分析和結合可視化工具來診斷當前的性能瓶頸。此外展示如何通過表管理工具實現成本治理，以及如何利用特定的診斷工具來提升系統的穩定性。 內容大綱如下：Hologres 診斷與優化的實踐事前：通過監控指標實時監控實例異常事中：通過活躍 SQL 日誌快速定位長 SQL事後：通過慢 Query 日誌+Query 洞察診斷慢 Query事後：通過慢 Query 日誌+Query 洞察治理錯 Query穩定治理：SQL 診斷報告長期治理 SQL穩定性治理：表 Meta 診斷報告治理 Meta 問題成本治理

事前：實例實時監控瞭解監控指標首先事前團隊需要預先審視業務，目的是提前發現並解決潛在問題，以防止問題在生產環境中惡化。建議採用監控指標並設置相應的告警機制來執行這一操作。Hologres 提供豐富的監控指標來幫助業務及時發現實例異常。訪問管控台，選擇相應的實例，進入監控信息頁面，您將看到 Hologres 提供的大約五類監控指標，每一類都對應不同的業務屬性。關於監控指標的詳細使用見<u>文檔</u>。資源和Query類監控資源與 Query 運行狀況監控指標主要用於監控團隊在實際操作中資源的利用率以及運行狀況。包含CPU使用率、內存使用率等，可以實時監測到實例資源的使用。CPU監控：以實例的CPU使用率為例，它反映了實例中 CPU 的整體使用情況。如果 CPU 使用率隨着 Query 波動，這通常意味着 CPU 運行狀況良好。然而，如果 CPU 使用率持續處於滿載狀態，這表明資源可能已經不足，此時需要團隊及時優化實例中的 SQL 或對資源進行擴容。接下來是 Worker 節點的 CPU 使用率監控，它旨在報告每個 Worker 節點的 CPU 使用情況。從圖表中可以看到，如果每個 Worker 的 CPU 使用率相對均勻，這通常表明運行狀況是健康的。但是，如果某個 Worker 的 CPU 使用率達到 100%，而其他 Worker 的使用率很低，或者大部分 Worker 的 CPU 使用率都很高，唯獨某個 Worker 的使用率偏低，這説明資源利用並不均衡。在這種情況下，團隊需要檢查是否存在數據傾斜問題，或者 Worker 節點的分佈是否均勻。內存監控：在內存相關的監控指標上，可以看到實例整體的內存使用情況，也能看到不同模塊的內存使用，例如Query使用內存、meta內存等，方便業務對內存水位持續性監控和治理。QPS和RPS指標：可以綜合的反映實例的讀寫情況，但需要注意的是，實例能支撐的QPS和RPS與實例規格、Query複雜度等因素有關，建議根據實際情況進行壓測Query延遲：包括Query在每個階段的延遲（Optimization 階段、Start Query 階段、Get next 階段）可以根據階段的耗時來評估Query的運行情況，並針對性優化。同時也提供Query的整體延遲和P99延遲，以綜合反映實例中所有Query運行的延遲。但需要重點關注“本實例正在運行中 Query 最長的時長”，可以反映實例中是否出現運行時間較長的Query，及時結合holoweb-活躍Query找到該Query，並做治理，防止實例中資源長期打滿，影響其他的任務運行。失敗Query：它主要監控實例在過去一段時間或實時中是否有失敗的 Query。如果在某段時間內失敗的 Query 數量增加，這可能表明實例出現異常，團隊需要及時介入處理I/O和存儲類監控IO：反映Query在運行過程中與底層存儲的IO交互情況，不涉及網絡的I/O，通過IO的吞吐情況，判斷數據的處理。存儲：反映實例中真實的數據存儲流量和Framework流量和Framework主要會反映Query運行過程中與網絡等的交互情況。Endpoint 流量：反映了不同網絡的流量情況情況，包括公網、VBC 網以及經典網等，它記錄了數據流入和流出的狀況，流量的使用可以反饋帶寬是否到達極限，從而影響數據寫入或讀取的速度。Framework：反映shard多副本、以及實例副本的延遲，一般來説延遲在毫秒級都是正常，如果延遲較高，説明實例異常需要及時處理。請重點關注“FE replay 延遲(milliseconds)”指標，延遲已經累積到小時級別，表示實例中worker有卡住的情況，需要及時處理Gateway：Gateway，作為計算組中的一個特殊組件，其主要職責是進行 SQL 分發和路由控制。因此，監控 Gateway 的 CPU、內存以及網絡流量的使用情況，可以反映 Query 處理速度和規模，團隊應定期檢查這些資源的使用情況，以判斷是否需要擴容。Serverless和資源彈性Serverless Computing：實時觀測在serverless中運行的Query延遲、排隊情況等，及時治理Computing Resource：監控分時彈性的使用情況Binlog和AnalyzeAuto Analyze：反映實例中每個DB內表的統計信息缺失情況，以判斷auto analyze的準確率，及時手動更新表的統計信息Binlog：主要是監控Binlog的使用情況，包括吞吐和wal sender連接數，從而判斷消費Binlog是否出現瓶頸監控告警最佳實踐如果要對監控指標告警，可以點擊報警-報警設置，根據業務情況設置閾值告警。Holo推薦常用的監控指標告警如下：監控CPU使用率：監控實例的CPU使用率和Worker節點CPU使用率，如果 CPU 使用率長時間保持在 100%，則表明資源嚴重不足，此時需要考慮擴容或優化團隊運行的業務。其次，關注 Worker 節點的 CPU 使用率，這有助於觀察資源是否被均勻利用。監控Query延遲：通過監控Query延遲，可以實時監控是否有延遲上漲，以此判斷實例負載情況監控失敗Query：通過失敗Query可以監控到當前實例中任務運行情況，如果連續失敗，可能存在實例異常，需要及時處理監控“本實例/Serverless最長的Query運行時長”：可以瞭解當前是否有運行時間較長的Query，如果長時間運行，會導致資源佔用，影響其他Query

事中：活躍 SQL 日誌快速定位長 SQL可以以通過活躍SQL日誌快速定位運行中的長SQL。通過Holoweb>診斷與優化>活躍Query，查看到當前實例中正在運行的SQL，詳細的信息包括運行時長、執行引擎等，如果CPU已經有長時間運行且不符合業務預期的，需要結合監控頁面，看CPU是否已經被打滿，然後在活躍Query界面點擊取消，將該Query取消，以避免長期佔用資源，同時CPU也會下降，説明問題止血成功。更多操作詳情見<u>文檔</u>

事後：慢Query日誌診斷Query優化慢Query如果要對Query持續性的治理和優化，可以使用<u>慢Query日誌</u>結合<u>Query洞察</u><u>功能</u>：第一步：前往holoweb>診斷優化>慢query日誌查詢當前實例的慢SQL列表，重點關注duration、engine type、cpu_time字段第二步：對於運行時間較長、資源消耗較多的SQL，單擊前往Query洞察分析，分析單個SQL性能，重點關注enginetype、readrows、readbytes第三步：查看Query執行計劃，重點關注算子：partitionselected、filter、time、rows，如下示例的plan，東從下往上看，Read Rows 已經處理了數億量級的數據，從 274 個分區中掃描了60 個分區，比較多，同時也是讀取的MC外表，因此建議優化方向是減少分區掃描或者將外表導入到內表，以提升性能

治理錯Query如果實例中監控到 Failed Query較多，可以通過慢Query日誌結合Query洞察治理。方法如下：第一步：監控指標觀察FailedQueryQPS，觀察到時間Query對應的時間段第二步：前往holoweb>診斷優化>慢Query日誌，圖維度選擇”失敗Query“，並選擇對應的時間段，查找錯誤的SQL第三步：點擊前往“query洞察分析”>錯誤信息，Query洞察會展示出詳細報錯，同時也會結合AI，給出詳細的報錯原因和解決方案，可以根據建議對SQL進行治理，提升實例的穩定性。

穩定性治理：SQL診斷長期治理Hologres 在Holoweb提供一個 SQL 診斷報告，可以查看昨天以及過去的詳細SQL運行，例如耗時佔比、錯誤佔比等，通過長期治理SQL，來提升實例穩定性。詳細使用見<u>文檔</u>。重點關注如下幾個治理項：錯SQL治理：關注失敗Query明細，可以查看某天的失敗次數，典型失敗Query，根據Query洞察中的錯誤信息和改進建議，治理錯SQL，提升實例的成功率長SQL治理：關注Query耗時佔比趨勢，可以分析出Query的耗時佔比，重點關注耗時較長（超過10min）的query耗時佔比，並通過Query洞察查看明細，治理慢SQL應用治理：關注Query應用來源佔比，可以分析出發起Query的應用來源，當出現異常時可以及時找到對應的應用。同時建議，儘量給每個應用都配置上應用來源application_name，不建議所有的Query都用統一的應用名，無法進一步排查問題執行引擎治理：關注執行引擎的Query趨勢，Hologres中有多個執行引擎（HQE、PQE、SQE等），其中HQE為自研引擎更高效，所以需要重點關注執行引擎為SQE、PQE的Query趨勢，儘量減少PQE的Query，以此提升Query性能

穩定性治理：表Meta診斷Meta問題meta診斷：當Hologres數據庫中的元數據管理器（Storage Master）和FE節點保存的表元數據不一致時，會導致DDL操作報錯或影響費用等。表Meta診斷功能，以檢測當前實例中表元數據的一致性，並每週更新一次診斷結果，可以根據對應元數據問題的解決方案進行修復，以提高實例的可用性和穩定性。Meta診斷是自動推送的異常問題，如果頁面顯示空白，則説明實例無meta問題，不需要治理。如果出現Meta異常，Hologres也提供一鍵修復的能力，單擊一鍵修復，在業務低峯期執行修復SQL，以便修復meta問題，提升實例問題性，詳細使用見<u>文檔</u>。

成本治理：表索引診斷報告長期治理表隨着業務的持續迭代，團隊實例中的表數量可能會迅速增加，導致管理困難，或者不清楚刪除哪些不必要的表，以及表的索引使用情況等，為此，我們提供了一個標準的表索引診斷報告，以評估當前實例中表的使用情況。表索引診斷報告的項目較多，詳細使用可以參考<u>文檔</u>，Hologres比較建議對如下幾項內容進行治理：存儲治理：分區子表數和存儲量：查看分區表的存儲量，治理存儲為0的表存儲為0的表：及時治理存儲為0的表，防止佔用meta內存行存表治理：沒有設置主鍵：無法用上索引的能力，需要重新建表並設置主鍵Distributionkey和clusteringkey不一致的行存表：不適用行存表點查場景，改成列存/行列共存表字段數治理：超過300列的列存表：列太多，性能開銷大超過300列的行列共存表：列太多，性能開銷大索引治理：超過3列的clustering/segment/distributionkey：索引設置超過3列，會導致使用場景受限，無法很好的利用索引的能力Binlog表治理：開啓Binlog的表：不建議列存表開啓binlog，性能開銷大BinlogTTL大於7天：Binlog太多會導致佔用過多的存儲，關注表存儲量，及時治理

通過表屬性診斷，有助於深入分析團隊實例中的表、索引以及字段數量，甚至包括表屬性等情況，以便進一步優化管理表，以實現長期的成本治理目標