Hologres：Hologres管控台的監控指標

執行個體CPU使用率（%）

執行個體CPU指執行個體整體的CPU使用率，代表執行個體的計算負載情況。

• 在沒有查詢的時候，後台常駐進程或者非同步執行的Compaction都可能佔用CPU，因此執行個體無查詢負載時，有少量CPU使用率是正常現象。

• Hologres因其設計原理可以充分發揮多核並行計算的能力，通常來說單個查詢可以迅速將CPU使用率提高到100%，這說明計算資源得到了充分利用。

• 當執行個體CPU使用率長期接近100%時（例如CPU使用率連續3小時滿載100%，或者連續12小時達到90%以上等），說明執行個體負載非常高，這通常意味著CPU資源成為了系統的瓶頸，需要分析具體的業務情境和查詢，以判斷原因。可以從以下幾方面判斷：

  • 是否有比較大的離線資料匯入（INSERT），且資料規模還在日漸增長。

  • 是否有高QPS的查詢或寫入，共同佔用了CPU的全部資源。

  • 是否有上述或上述情境以外的混合負載。

• 如果確定是業務情境需要，將資源用滿，可以對執行個體進行擴容，以適應更複雜的查詢或更大的資料量。

Worker節點CPU使用率（%）

Worker節點CPU指執行個體內每個Worker的CPU使用率，代表每個Worker的計算負載情況。Hologres根據執行個體規格，提供不同的Worker節點數，詳情見執行個體規格概述。

• 當前指標只有Hologres V1.1及以上版本支援顯示。

• 當執行個體內所有Worker節點CPU使用率都長期接近100%時，說明執行個體的負載非常高，需要根據業務情況合理地最佳化資源使用或者擴容。

• 當執行個體只有部分Worker節點的CPU水位比較高，部分Worker節點的CPU水位較低時，說明Worker資源有傾斜，常見傾斜原因以及排查方法請參見監控指標常見問題。

執行個體記憶體使用量率（%）

執行個體記憶體使用量率代表執行個體整體的記憶體綜合使用率。

• Hologres的記憶體資源採用預留模式，在沒有查詢的時候，也會有資料表的中繼資料、索引、資料緩衝等載入到記憶體中，以便加快檢索和計算，此時記憶體使用量率不為零是正常情況。理論上，在無查詢的情況，記憶體使用量率達到30%~40%左右都屬於正常情況。

• 當記憶體使用量率穩定增長，長期接近80%時，通常意味著記憶體資源可能成為了系統的瓶頸，可能會影響執行個體的穩定性或效能。

• 可以根據執行個體記憶體分布使用率，並結合業務的QPS等指標綜合判斷誰佔用了較高的記憶體，從而做相應的最佳化。詳情可以參見OOM常見問題排查指南。

Worker節點記憶體使用量率（%）

Worker節點記憶體使用量率指執行個體內每個Worker的記憶體使用量率，代表每個記憶體的計算負載情況。Hologres根據執行個體規格，提供不同的Worker節點數，詳情見執行個體規格概述。

• 當前指標僅Hologres V1.1及以上版本支援顯示。

• 當執行個體內所有Worker節點的記憶體水位都長期接近80%時，說明執行個體的負載非常高，需要根據業務情況合理地最佳化資源或者擴容。

• 當執行個體只有部分Worker節點記憶體水位比較高，部分Worker節點記憶體水位較低時，說明Worker資源有傾斜，常見傾斜原因以及排查方法請參見監控指標常見問題。

執行個體中記憶體的詳細使用率（%）

在Hologres中，記憶體會分為系統（system）、中繼資料（meta）、緩衝（cache）、計算（query）、後端進程（background）等幾個部分。從V2.0.15版本開始，支援執行個體記憶體分布使用率的監控指標，可以通過該指標查看記憶體的分布情況，從而進行針對性最佳化。主要包括以下指標：

• System：系統記憶體，指系統組件運行時佔用的記憶體，組件包括Holohub、Gateway、FE（Frontend）等，其中FE會包括FE Master和FE Query，因此System記憶體也會隨著Query的運行而波動。

• Cache：緩衝佔用的記憶體，緩衝的記憶體主要包括：

  • SQL相關的緩衝：例如result cache、block cache等，與SQL有關，根據Query運行狀態動態變化。如果SQL有命中緩衝（例如通過explain analyze查看Physical read bytes欄位，資料越小說明快取命中率越高），將會提升查詢效能。但SQL的緩衝也有一定的上限。

  • Meta緩衝：包括表的Schema Meta、檔案Meta等，為了Query的高效執行，Hologres的儲存引擎會預先將Meta相關的資料載入進緩衝中，從而減少Meta的冷訪問，提升查詢效能。

  • 緩衝有固定大小，一般佔用執行個體總記憶體的30%左右。當執行個體沒有查詢負載時，也會存在一定的緩衝佔用，主要是Meta佔用的緩衝。

• Meta：中繼資料、檔案等佔用的記憶體，中繼資料的記憶體使用量採用Lazy Open模式，即頻繁被訪問的中繼資料會常駐記憶體中，未被訪問的中繼資料則不會放在記憶體中，以此來減少中繼資料對記憶體的佔用。一般建議Meta佔用的記憶體維持在總記憶體的30%以內。如果Meta佔用的記憶體較高，說明執行個體中訪問的檔案數較多，或者分區表較多，可以通過表統計資訊查看與分析對執行個體中的表做相關治理。

• Query：代表執行SQL時消耗的記憶體，與Query的複雜度、並發度等正相關。主要包括Fixed Plan、HQE、SQE等執行SQL消耗的記憶體。

  • Query計算的記憶體會採用彈性機制，即單個Worker最低使用20 GB，最高使用根據執行個體的總空閑記憶體浮動，其他分類中記憶體佔用越多，會導致計算部分彈性的記憶體越少。

  • 如果Query佔用的記憶體較多，甚至出現了OOM的現象，說明Query較複雜或者並發度較高，建議對Query調優或者對執行個體擴容，以避免執行個體高水位運行，詳情請參見最佳化查詢效能。

• Background：背景工作佔用的記憶體，包括Compaction、Flush等任務，一般Background消耗的記憶體較少，約在5%以內。但如果對錶修改了索引、執行了大量的寫入或更新等操作，Background的記憶體佔用將會上升，並隨任務的結束而下降。

• Memtable：記憶體表佔用的記憶體，在Hologres中Memtable（記憶體表）主要用於儲存有即時寫入、更新、刪除等操作完成之後的表資料。一般Memtable的記憶體佔用在5%以內。

QE Query記憶體使用量量（byte）

指執行個體中使用了HQE、SQE等Hologres自研引擎XQE的Query，在運行過程中的記憶體使用量量。

• 該指標僅Hologres V2.0.44及以上版本、V2.1.22及以上版本支援顯示。

• 在記憶體細分類中，Query的記憶體使用量量大於QE Query記憶體使用量量。

通過QE Query記憶體使用量量可知該執行個體中啟動並執行Query複雜度，如果記憶體使用量量較多，說明Query比較複雜，使用的記憶體較多。

QE Query記憶體使用量率（%）

QE Query記憶體使用量率可以判斷當前執行個體的負載情況，如果QE記憶體使用量率較高，可能因記憶體不足而導致OOM，需要治理Query或者擴容。

該指標僅Hologres V2.0.44及以上版本、V2.1.22及以上版本支援顯示。

Query QPS（countS）

Query QPS代表執行個體中平均每秒SQL語句的執行次數，為執行個體內總的QPS。包括SELECT、INSERT、UPDATE和DELETE、UTILITY、UNKNOWN等SQL語句。Query QPS >= QE Query + FixedQE Query QPS。

QE Query QPS（countS）

指執行個體內使用QE引擎的Query每秒執行的次數。包括SELECT、INSERT、UPDATE和DELETE四種類型的SQL語句。

該指標僅Hologres V2.2及以上版本支援顯示。

FixedQE Query QPS（countS）

指執行個體內使用FixedQE引擎的Query每秒執行的次數（走Fixed Plan鏈路，原名SDK）。包括SELECT、INSERT、UPDATE和DELETE四種類型的SQL語句。

該指標僅Hologres V2.2及以上版本支援顯示。

DML RPS（countS）

DML RPS代表執行個體內Query每秒匯入或者更新的資料記錄條數，包括INSERT、UPDATE和DELETE三種類型的SQL語句，因此DML RPS = QE DML RPS + FixedQE DML RPS。

QE DML RPS（countS）

指執行個體內使用QE引擎的Query每秒匯入或者更新的資料記錄條數，包括INSERT、UPDATE和DELETE三種類型的SQL語句。

• 該指標僅Hologres V2.2及以上版本支援顯示。

• 使用QE引擎匯入或更新資料的常見情境如下：

  • MaxCompute或OSS外部表格的大量匯入或更新。

  • Copy批量寫入或更新。

  • Hologres表之間的大量匯入。

FixedQE DML RPS（countS）

指執行個體內使用FixedQE引擎的Query每秒匯入或者更新的資料記錄條數（原指標名為SDK），包括INSERT、UPDATE和DELETE三種類型的SQL語句。其中：

• 該指標僅Hologres V2.2及以上版本支援顯示。

• 常見的FixedQE情境包括：

  • 通過Flink即時寫入。

  • 通過Holo-Client寫入。

  • 使用Spark匯入。

  • 即時同步MySQL Binlog的資料至Hologres。

  • 從DataHub匯入。

  • 通過Data IntegrationDataX離線寫入。

  • SQL或JDBC通過INSERT INTO VALUES()語句寫入。

Query延遲（milliseconds）

執行個體內啟動並執行所有Query的平均延遲，包括SELECT、INSERT、UPDATE和DELETE、UTILITY、UNKNOWN等SQL語句。Query延遲 >= MAX（QE Query延遲，FixedQE Query延遲）。

QE Query延遲（milliseconds）

執行個體內使用QE引擎的Query的平均延遲，包括SELECT、INSERT、UPDATE和DELETE四種類型的Query。

• 該指標僅Hologres V2.2及以上版本支援顯示。

• 對於QE Query的延遲增加排查，可以結合Optimization耗時、Start Query耗時、Get next耗時、QE QPS等指標一起排查。

FixedQE Query延遲（milliseconds）

執行個體內使用FixedQE引擎的Query的平均延遲，包括SELECT、INSERT、UPDATE和DELETE四種類型的Query。

• 該指標僅Hologres V2.2及以上版本支援顯示。

• FixedQE Query延遲高可能是如下原因：

  • 偶發變高：可能是因為存在HQE鎖，可以查看FixedQE的後端拿鎖耗時是否增加，若增加說明有鎖，可以通過Query洞察排查具體的拿鎖Query。

  • 一直延遲高：可能是因為建表不合理，或著受其他複雜Query的影響等，可以參考Blink和Flink常見問題及診斷進行排查。

Optimization階段的耗時（milliseconds）

執行個體內Query在Optimization階段的耗時，該階段主要用於最佳化器QO解析SQL，並產生對應的物理Plan以便執行引擎跟進Plan去執行。

• 該指標僅Hologres V2.0.44及以上版本、V2.1.22及以上版本支援顯示。

• 如果Optimization階段耗時較長，說明執行個體中Query較複雜，導致解析Query耗費較多時間。如果執行個體中的Query只是傳入的參數不同，建議使用Prepared Statement模式降低QO耗時，詳情請參見JDBC。

Start Query階段的耗時（milliseconds）

執行個體內Query在Start Query階段的耗時，該階段為真正開始執行Query前的初始化階段，包括了加鎖，對齊Schema版本等過程。

• 該指標僅Hologres V2.0.44及以上版本、V2.1.22及以上版本支援顯示。

• 如果Start Query階段耗時較長，通常是由於等待鎖或者高CPU佔用導致資源等待，可以結合執行計畫等細緻分析。

Get next階段的耗時（milliseconds）

Get next是指從Start Query階段結束開始計算，到所有結果均返回所花費的時間，包括計算、返回結果等步驟的耗時。

• 該指標僅Hologres V2.0.44及以上版本、V2.1.22及以上版本支援顯示。

• 如果Get next階段耗時較長，通常是由於計算複雜導致，可以結合QE記憶體使用量、QE QPS等指標一起排查。如無明顯異常，也可能是用戶端在等待返回資料。

Query P99延遲（milliseconds）

執行個體內啟動並執行所有Query的P99延遲，包括SELECT、INSERT、UPDATE和UTILITY、以及系統Query等。

本執行個體正在運行中Query最長的時間長度（milliseconds）

指執行個體中正在啟動並執行Query持續時間長度，預設彙報當前時刻已耗用時間最長的Query時間長度，包括SELECT、INSERT、UPDATE和DELETE、UTILITY、UNKNOWN等SQL語句。

• 該指標僅Hologres V1.1及以上版本支援顯示。

• Hologres是分布式系統，根據執行個體的規格會有不同的Worker節點。Query運行時會在不同的Worker節點隨機分發。正在啟動並執行Query持續時間長度會根據每個Worker節點上Query運行時間長度，彙報當前時刻已耗用時間最長的Query，例如當前時刻不同的Worker節點分別在運行持續時間長度為10分鐘、5分鐘和30秒的Query，此時正在啟動並執行Query持續時間長度將會顯示為10分鐘。

• 可以根據Query的運行時間長度，並結合活躍Query或者慢Query日誌判斷Query運行時間長度是否合理，排查並解決Query已耗用時間較長的問題，及早處理死結、卡住等情況。

失敗Query QPS（milliseconds）

失敗Query數代表執行個體內平均每秒SQL語句失敗的次數，包括SELECT、INSERT、UPDATE和DELETE、UTILITY、UNKNOWN等SQL語句。失敗Query QPS >= QE 失敗Query QPS + FixedQE 失敗Query RPS。

可以根據失敗的Query類型和次數，在慢Query日誌中尋找失敗的Query並分析原因，以提高系統的可用性。

QE失敗Query QPS（milliseconds）

指執行個體內使用QE引擎的Query每秒失敗的次數。包括SELECT、INSERT、UPDATE和DELETE四種SQL語句。

該指標僅Hologres V2.2及以上版本支援顯示。

FixedQE失敗Query QPS（milliseconds）

指執行個體內使用FixedQE引擎的Query每秒失敗的次數。包括SELECT、INSERT、UPDATE和DELETE四種SQL語句。

該指標僅Hologres V2.2及以上版本支援顯示。

FE等鎖的最大耗時（milliseconds）

Hologres是分布式系統，會有多個FE節點負責SQL的解析、分發及路由。當不同的串連請求被路由到同一個FE節點，並對同一個表做DDL操作（如CREATE、DROP）時，會產生FE鎖。FE等鎖耗時反映了每個FE等待DDL鎖的耗時。

• 該指標僅Hologres V2.2及以上版本支援顯示。

• 一般來說，只要執行DDL操作就可能會產生鎖耗時，FE鎖耗時超過5分鐘，同時“FE replay延遲”指標也出現較高的延遲，可能是因為有DDL執行卡住了，通過Query管理排查已耗用時間較長的Query並及時終止該進程。

FixedQE的後端拿鎖耗時（milliseconds）

對於INSERT、DELETE或UPDATE等類型，走HQE鏈路的Query會使用表鎖，走FixedPlan鏈路的Query會使用行鎖。FixedQE的後端拿鎖表示走FixedPlan鏈路的Query涉及到的表被加了行鎖，同時走HQE鏈路的Query對該表加了表鎖，導致FixedPlan的Query需要等鎖，進而導致FixedQE拿鎖耗時增加。

• 該指標僅Hologres V2.2及以上版本支援顯示。

• 如果FixedQE的拿鎖耗時較長，可以通過慢Query日誌定位到比較慢的FixedQE Query，然後通過Query洞察排查拿鎖的HQE Query。

執行個體總的後端拿鎖耗時（milliseconds）

表示INSERT、DELETE或UPDATE類型的Query在執行個體中總的拿鎖耗時，包括FixedQE的拿鎖耗時和HQE Query之間的拿鎖耗時。

• 該指標僅Hologres V2.2及以上版本支援顯示。

• 如果拿鎖耗時較長，可以通過慢Query日誌定位到比較慢的INSERT、DELETE或UPDATE類型的Query，再通過Query洞察排查拿鎖的HQE Query。

總串連數（個）

Hologres根據執行個體的規格，設定不同的預設總串連數，詳情請參見執行個體規格概述。總串連數代表執行個體當前已經使用的串連總個數，包括active（活躍）、idle（空閑）、idle in transaction（已失敗事務中的空閑狀態）等串連狀態。可以通過Query管理查看當前的串連使用方式，當出現串連不足時，及時kill空閑串連。

串連數（按DB展開）（個）

按照DB匯總的串連數使用個數，判斷每個DB的串連使用方式。其中：

• 每個DB的總串連數上限預設是128，詳情請參見執行個體規格概述。

• 當每個DB的串連數長期接近最大值時，說明執行個體的串連數使用較多，可以根據業務情況查看是空閑串連還是Business Connectivity，詳情請參見串連數管理，並根據業務情況及時清理空閑串連或者擴容擷取更多的串連。

• 當部分Worker節點串連數較高，部分Worker節點的串連數較低時，說明執行個體的串連負載不均，通過串連數管理查看空閑串連並及時清理，以緩解串連負載不均的情況。

串連數（按FE展開）（個）

按照FE匯總的串連數使用個數，判斷每個FE的串連使用方式。其中：

• 每個FE節點的總串連數上限預設是128，詳情請參見執行個體規格概述。

• 當每個FE節點的串連數長期接近最大值時，說明執行個體的串連數使用較多，可以根據業務情況查看是空閑串連還是Business Connectivity，詳情請參見串連數管理，並根據業務情況及時清理空閑串連或者擴容擷取更多的串連。

• 當部分Worker節點串連數較高，部分Worker節點的串連數較低時，說明執行個體的串連負載不均，通過串連數管理查看空閑串連並及時清理，以緩解串連負載不均的情況。

串連數使用率最高的FE的串連數使用率（%）

代表使用率最高的FE（Frontend）節點的使用率，彙報每個FE節點的最大值，即Max(frontend_connection_used_rate)，可以更加方便的知道使用的串連數是否即將超過某個Frontend節點的最大串連數，造成無法串連的情況。多個FE節點之間採用輪訓策略（Round Robin），建立串連依次與不同Frontend節點建立物理串連。可以通過Query管理查看當前的串連使用方式，當出現串連不足時，及時kill空閑串連。

標準IO讀吞吐（byte/s）

代表Query讀取標準儲存資料時的I/O吞吐。

標準IO寫吞吐（byte/s）

代表Query寫入標準儲存資料時的I/O吞吐。

低頻IO讀吞吐（byte/s）

代表Query讀取低頻儲存資料時的I/O吞吐。

低頻IO寫吞吐（byte/s）

代表Query寫入低頻儲存資料時的I/O吞吐

標準儲存已用容量（byte）

標準儲存已經使用的儲存容量，若超過購買的儲存容量，可以適當擴容儲存。

標準儲存使用率（%）

標準儲存已經使用的儲存使用率，若超過購買的儲存容量，可以適當擴容儲存。

低頻儲存已用容量（byte）

低頻儲存已經使用的儲存容量，若超過購買的儲存容量，可以適當擴容儲存。

低頻儲存使用率（%）

低頻儲存已經使用的儲存使用率，若超過購買的儲存容量，可以適當擴容儲存。

FE replay延遲（milliseconds）

Hologres為分布式系統，在接入層有多個Frontend（FE）負責SQL的解析、分發、路由。對於DDL，Hologres的原理是先在一個FE執行，然後其餘FE節點replay。其中：

• FE replay需要一定的時間，一般來說，Relay延遲在毫秒級、秒級都為正常情況。

• 當某個FE replay的延遲超過分鐘級時，可能是由於DDL太多，replay不及時；若是延遲一直增加，可能是Query卡住了，可以通過hg_stat_activity排查耗時較高的Query，並及時Kill。

• 該指標僅Hologres V2.2及以上版本支援。

Shard多副本同步延遲（milliseconds）

Shard多副本延遲是指執行個體開了Replication後，主從Shard之間的副本資料同步延遲。

• 通常Shard多副本延遲為毫秒級。

• 當有大量資料寫入、更新或頻繁執行DDL操作時，可能會導致同步延遲。

主從同步延遲（milliseconds）

主從執行個體同步延遲表示從執行個體讀取主執行個體資料時的延遲（毫秒），其中：

• 僅從執行個體顯示該指標，主執行個體預設不顯示。

• 只有在從執行個體綁定了主執行個體之後，該指標才會顯示資料（0ms），當主執行個體有資料寫入時，從執行個體的同步延遲會出現資料波動。

• 通常情況下，主從執行個體的同步延遲為毫秒級，當執行個體偶爾出現延遲抖動時，可能原因為主執行個體在做DDL等中繼資料修改的操作，可忽略。若長期延遲較大（大於秒），可能原因為執行個體水位較高，資源不足，您可以結合CPU、記憶體等水位情況綜合評估，並適當擴容以減少延遲。

• 執行個體重啟或者升級期間，同步延遲可能增加到分鐘層級，並會自動回復。

執行個體間檔案同步延遲（milliseconds）

指異地容災執行個體間的檔案同步延遲，僅在Follower執行個體（唯讀從執行個體）上展示該指標。

每個DB統計資訊缺失的表個數（countS）

代表每個DB中，統計資訊缺失的表的個數。

• 該指標僅Hologres V2.2及以上版本支援顯示。

• 對於Hologres V2.0及以上版本的執行個體，會預設開啟新版本Auto Analyze機制，當表剛建立或者有大量資料寫入或更新時，Auto Analyze可能未及時更新統計資料，可以先暫時觀測一段時間。

• 如果某個DB長期（超過數小時或數天）有缺失統計資訊的表，可能是因為未到達Auto Analyze的閾值，可以通過HG_STATS_MISSING視圖查看哪些表缺失統計資訊，並對錶手動執行Analyze以更新統計資料。

• 如果某個DB長期（超過數小時或數天）有缺失統計資訊的表，可能是因為未達到Auto Analyze的閾值，可以查看錶的統計資訊，並手動對錶執行Analyze。詳情請參見ANALYZE和AUTO ANALYZE。

正在啟動並執行Serverless Computing的查詢中，最長的時間長度（milliseconds）

Hologres支援Serverless Computing，可以將指定的Query運行在Serverless Computing資源集區中，隔離本執行個體以及任務，確保Query快速運行。

• 該指標僅Hologres V2.1及以上版本支援顯示。

• 該指標反映了Query在Serverless Computing的運行時間長度，預設展示已耗用時間最長的Query的時間長度，同時結合hg_stat_activity定位Query在Serverless的運行情況。

每秒消費Binlog的條數或位元組數

Hologres支援訂閱Hologres Binlog功能，通過Binlog可以實現資料的即時分層，加速資料流轉。

wal sender的使用數和使用率

同普通串連類似，在使用JDBC進行Binlog的消費時，所消費的每張表的每個Shard都會使用1個Walsender串連，Walsender串連與普通串連獨立，互不影響。Walsenders數有預設上限。

結合上述兩個指標，可以判斷當前執行個體中Walsender的使用方式，若Walsender到達上限，可以通過JDBC消費Hologres Binlog排查並處理。

Warehouse_timed_elastic_cores(Count)

Hologres計算群組執行個體支援分時彈性功能，詳情請參見計算群組分時彈性（Beta）。該指標表示執行個體通過分時彈性彈出的Core數。