CPU平均使用率增高

CPU平均使用率展示的是在某個時間點，多個節點的CPU平均使用率。CPU平均使用率增高，會影響集群的穩定運行，導致查詢和寫入的速度變慢。如果CPU平均使用率持續增高，表示集群存在較大的風險，需要盡快優化。

CPU平均使用率增高的常見原因如下：

• 查詢

  查詢導致的CPU使用率增高，可能是由于Bad SQL，例如SQL中包含了復雜的計算邏輯、處理大量的數據，或者JOIN沒有JOIN條件，從而產生了笛卡爾積等。您可以通過一鍵診斷功能來定位存在問題的查詢：

  • Bad SQL檢測結果中，高耗時的SQL、數據讀取量大的SQL、Stage個數多的SQL、最耗CPU的SQL，都可能導致集群的CPU使用率增高，需要根據自診斷結果或者執行計劃進行進一步的分析。

  • 異常Pattern檢測會從SQL模板的角度，對異常提交的Pattern進行檢測，與Bad SQL類似，導致CPU增高的Pattern需要從數據讀取量異常、消耗CPU異常、查詢耗時異常等多個維度進行分析，這些異常Pattern的出現都可能導致CPU增高。

  • 如果是計算節點或存儲節點CPU使用率增高的問題，可以結合一鍵診斷結果中的計算層檢測和存儲層檢測中的異常算子檢測來分析，異常算子中的算子詳細信息和算子匯總信息中，都會從CPU消耗角度對異常算子進行了篩選和過濾。

• 寫入

  寫入過程也會消耗CPU資源（包括INSERT、UPDATE、DELETE、REPLACE、INSERT OVERWRITE、INSERT INTO SELECT），同樣也會導致存儲節點CPU使用率增高。此時需要觀察刪除TPS、寫入TPS、更新TPS和LOAD_TPS等監控指標是否同樣出現了突增。

  常見的寫入導致CPU使用率增高原因如下：

  • 超長主鍵

    當主鍵非常長的時候，會導致查詢的主鍵索引比較大，從而消耗較大的CPU資源。

  • DELETE SQL

    如果單個DELETE WHERE語句命中了較多行數據，計算引擎需要計算出所有行的主鍵，然后再逐個下發給存儲節點進行刪除操作。一個DELETE SQL操作步驟可能會放大很多倍，從而導致CPU使用率增高。

  • UPDATE SQL

    如果單個UPDATE WHERE語句命中了較多行數據，計算引擎需要計算出所有命中行的主鍵，并更新其對應的字段值，然后再逐個下發給存儲節點進行標記舊行以及追加（Append）新行的操作。一個UPDATE SQL操作步驟可能會放大很多倍，從而導致CPU使用率增高。

  • INSERT OVERWRITE

    批量寫入（Batch load）的過程中需要進行數據解析、按照聚集索引字段（如果有聚集鍵）進行排序（Sort）、構建主鍵索引和普通索引等操作，上述操作都屬于CPU密集型操作（每個Shard需要一個線程進行上述工作）。目前雖然有批量寫入并發數量限制（例如最多同時存在2個批量寫入SQL），但是每個Shard需要一個線程進行批量寫入相關操作，仍舊可能導致CPU使用率增高。

  • INSERT INTO SELECT

    短時間內大量數據寫入，當后臺Build任務堆積時會導致實時數據增多，此時查詢如果涉及實時數據的話，數據庫需要掃描大量實時數據（因為實時數據沒有索引），最終導致CPU使用率增高。

• Build

  Build任務會對數據進行構建索引、建立和清除分區等操作，很可能會導致存儲節點的CPU使用率增高。您可以在控制臺對比CPU使用率和Build任務數的監控數據，可以較容易發現兩個指標間的相關性。

  說明

  • 關于Build的介紹請參考BUILD。

  • 如何定位和分析Build導致的資源水位增高的問題，請參見Build任務數增多。

CPU最大使用率傾斜

CPU最大使用率展示的是在某個時間點，多個節點中CPU使用率最高節點的值。當CPU最大使用率和CPU平均使用率長時間相差較大時，說明集群內部存在任務處理不均勻的情況（有些節點計算量較大，有些節點計算量較小，最終導致CPU使用率傾斜）。CPU使用率傾斜嚴重（例如1倍以上），會較大地影響集群運行的穩定性，并且會導致資源浪費，因為分布式的查詢子任務受到了CPU最大使用率的限制，而無法進一步的提升性能，只能升配解決，但是其他節點的CPU使用率并不高。

導致CPU使用率傾斜可能存在如下原因：

• 源表傾斜

  通常是建表時選擇的分布鍵不均勻，導致不同Shard上的數據量存在較大差異。

  如下圖所示，某個大表分布不均，存儲節點0上的Shard_0和Shard_1中數據量較大，而在存儲節點1上的Shard_2和Shard_3中數據量較小，那么當您查詢這個大表時，較大概率會出現存儲節點0需要處理的數據多，存儲節點1上需要處理的數據少的情況，這樣就會導致存儲節點0的CPU使用率長期高于存儲節點1的CPU使用率，最終導致CPU使用率傾斜。

  

  關于源表傾斜的診斷，請參見存儲空間診斷。一鍵診斷也會檢測占用磁盤空間較大的傾斜表，分析資源傾斜。

• 中間數據傾斜

  中間數據傾斜不同于源表傾斜。在中間數據傾斜的場景下，源表數據可能在各個Shard上是分布均勻的，但是Shard中包含的某個字段的值又是分布不均的。

  當您根據分布不均的字段來做分組聚合查詢或者作為JOIN的條件，AnalyticDB for MySQL內部會根據這些字段對數據進行一次不同節點間的重分布，重新分布后，因為相關的字段值的數據會被分發到同一個節點上，就出現了字段分布不均的現象。

  如下圖所示，某張表是根據a字段進行分布，因為a字段本身比較均勻，所以數據均勻地分布在不同的存儲節點上，當您使用了b字段進行分組（group by b），那么存儲節點1會將b字段值為b1的數據行分發到計算節點1，為確保計算節點1具有所有b字段值為b1的行，存儲節點2會把b字段值為b1的數據分發到計算節點1，值為b2的數據分發到計算節點2。因此，計算節點1具有的數據行遠大于計算節點2，就產生了數據傾斜，對于后續的計算任務，計算節點1就需要消耗較多的集群資源。

  

  針對中間數據傾斜導致的CPU使用率不均勻，您可以通過分析查詢的Stage級別診斷結果進行問題定位。

磁盤IO吞吐增高

磁盤IO吞吐表示底層存儲介質的吞吐消耗，單位MB/s。磁盤IO吞吐的最高值請參見ESSD云盤。由于該上限值是理想狀態下的測試值，與集群實際的負載情況不完全相符，一般實際負載可能能夠達到該標稱值的80%左右。

磁盤IOPS增高

磁盤IOPS表示底層存儲介質每秒的IO次數，磁盤IOPS的最高值請參見ESSD云盤。由于該上限值是理想狀態下的測試值，與集群實際的負載情況不完全相符，一般實際負載可能能夠達到該標稱值的80%左右。

計算內存使用率增高

分析型數據庫在進行大量數據計算時，會消耗較多的內存資源。消耗內存較高的SQL一般包含Aggregation算子、TopN算子、Window算子以及Join算子：

• Aggregation算子

  Aggregation算子消耗內存較高主要是因為AnalyticDB for MySQL在進行數據的分組時，會把分組信息暫存在內存中，如果分組字段唯一值較多，那么就會在分布式聚合的Final階段消耗較多的內存資源（Partial階段因為不需要進行全局的聚合，各個節點完成部分數據的局部聚合就可以將數據發送到下游節點，所以Partial階段消耗的內存不大）。

• TopN算子

  AnalyticDB for MySQL在進行TopN計算時（例如SQL中有ORDER BY id LIMIT m,n），當m較大時，AnalyticDB for MySQL中的TopN算子會緩存較多數據在內存中，以完成最終的全局排序，這個過程會消耗較多的內存資源。

• Window算子

  Window算子用于計算窗口函數。為了達到語義的最終結果，和Aggregation算子類似，同樣需要暫存較多的數據到內存中。

• Join算子

  AnalyticDB for MySQL支持標準的Join查詢操作，系統內部實現Join過程一般使用Hash算法和Index算法，更多介紹，請參見算子。Hash算法會將小表（Build表）緩存到內存中，并在內存中為Build表構建一個Hash表，加速Join的過程。以下原因可能導致Hash表占用較多內存：

  • Build表本身較大：

    AnalyticDB for MySQL會根據統計信息評估Join操作兩邊的表的大小，以較小的表作為Build表，但不排除Build表仍然較大。

  • 統計信息過期或者統計信息評估不準

    當Join操作的兩表不是源表，而是經過了多次的聚合、過濾、其他Join等計算后，基于源表的統計信息很難準確統計兩表的大小?；蛘弋斀y計信息過期，沒有及時更新，也會錯誤選擇了較大的表作為Build表，并為其構建Hash表。更多介紹，請參見統計信息。

  • Left Join

    由于語義的原因，Left Join的右表一定要用來構建Hash表，以達到正確的語義結果。如果Left Join的右表較大，就會導致本次Join操作占用較大內存。

更多這些算子的介紹，請參見算子。

當包含這些算子的SQL并發較高，或者單算子占用較高的內存，那么計算內存使用率指標就會增高，影響集群的穩定性，并且導致查詢報錯，常見報錯如下：

• Query exceeded reserved memory limit：某個查詢在單個節點上使用內存超過限制。

• Query exceeded system memory pool limit：單個字段過長或參與計算的列過多。

• Out of Memory Pool size pre cal. avaliable：物理內存池耗盡。

• The cluster is out of memory, and your query was killed：集群內存不足時，會終止當前正在運行的最大的一個查詢。

如果要降低計算內存使用率，您需要對包含這些算子類型的SQL進行調優，具體操作請參見算子級別診斷結果。

Build任務數增多

Build主要完成對寫入的數據進行構建索引、清理過期數據、執行異步DDL任務等，將數據從寫優化轉變為讀優化。Build任務在某些情況下會消耗較高的存儲節點CPU資源以及磁盤IO資源，可能會影響到其他操作，導致出現集群穩定性問題。關于Build指標的說明如下。

集群的Build任務數增多并影響到讀寫節點CPU使用率，可以從以下幾個方面進行定位和分析：

• 分區表的單分區較大。單分區較大時，這類大分區被寫入、更新或者刪除概率較大，更容易觸發分區被Build。您可以通過存儲空間診斷來定位這些類型的表，進行表結構的優化。

• 過大的非分區表。當非分區表較大時，也更容易被寫入、更新或者刪除，也更容易觸發全表Build。

• 大量的讀寫請求導致存儲節點CPU持續較高，進而導致Build執行過慢。

節點掉線個數增多

當AnalyticDB for MySQL集群內部的節點無法提供服務時，會存在節點掉線的情況，節點掉線對于集群的穩定運行有較大的危害，會導致查詢和寫入變慢，也會導致查詢報錯。節點掉線時，您可以分析CPU使用率是否持續增高、IO相關指標是否持續打滿等。

P95曲線

AnalyticDB for MySQL對CPU使用率、接入節點CPU使用率、計算內存使用率、磁盤IO吞吐、磁盤IOPS、磁盤IO使用率、磁盤IO等待時間等監控指標增加了P95監控曲線。P95指標即95%的指標小于等于該值。以計算節點CPU使用率為例，假設集群有100個計算節點，在某個時間點，將所有節點的CPU使用率按照升序排列，第95個計算節點的CPU使用率即計算節點P95 CPU使用率。

最大值、平均值與P95有以下區別：

• 最大值單純指出數據的上限，在存在異常值或者極端值的情況下，監控指標最大值會被這些個別值所影響，不能很好地代表數據集的一般水平或典型情況。

• 平均值旨在描述數據的集中趨勢，但在數據集存在異常值或傾斜分布時，也不再能準確反映數據的一般狀態。

• P95則是關注的較高部分數據的表現，忽略了最極端的數據點，適合評估大部分情況下的性能或水平。

查詢響應時間增長

查詢響應時間指標表示查詢從提交、排隊到真正執行結束的時間，關于AnalyticDB for MySQL中耗時的說明，請參見監控FAQ。

當集群的查詢響應時間突然增高，可能存在如下原因：

• Bad SQL

  Bad SQL會占用較多的集群資源，影響其他正常SQL的執行。

• 異常Pattern

  有時某個SQL消耗的資源并不大，但是這類SQL出現的次數較多；或者某些SQL資源消耗較大，導致整個集群處理任務的性能出現瓶頸，最終影響其他查詢，使整體查詢響應時間增高。

• 寫入量增大

  寫入量增大會占用較多的CPU資源、磁盤IO資源，觸發更多的Build任務，最終會導致整體的查詢響應時間增加。

您可以在控制臺的監控信息頁面，選擇查詢響應時間增高的時段，發起一鍵診斷，根據各項診斷結果分析具體原因。

查詢等待時間增長

當查詢提交到集群的接入層節點后，集群會根據接入層隊列的大小設置，檢查查詢是否需要排隊，防止同一時間段執行的SQL太多，導致集群壓力增大，從而影響整體穩定性。更多介紹，請參見并發控制。

當查詢的等待時間突然出現增高的情況，通常是因為集群內部執行效率降低導致，例如出現Bad SQL或者異常Pattern，導致占用了大量的集群資源。您可以通過一鍵診斷，查看多維度Bad SQL檢測結果和異常Pattern檢測結果。寫入數據量增大，導致占用了較多的存儲節點CPU資源和IO資源也會導致查詢等待時間增高。

查詢失敗率增多

查詢失敗率僅統計失敗查詢的占比，不會統計查詢失敗原因。導致查詢失敗可能有多種原因，常見原因和處理方法如下：

• SQL存在問題導致查詢失敗

  • 語法錯誤

    SQL不符合AnalyticDB for MySQL官方對SQL語法的定義，通常在SQL語法解析階段報錯。例如，SQL不完整、格式錯誤、關鍵字缺失、標點符號缺失等。

  • 語義錯誤

    SQL符合AnalyticDB for MySQL官方對SQL語法的定義，但在語義檢查時，發現數據庫對象錯誤，在語義分析階段報錯。例如，表名錯誤、列不存在、GROUP BY字段缺失、函數參數類型錯誤等。

• 集群內部問題導致查詢失敗

  • 查詢超時

    AnalyticDB for MySQL有默認的查詢超時時間。您也可以根據實際業務需求來配置查詢超時時間，如果查詢執行時間超過了該時間，將會查詢失敗。

    說明

    • 默認查詢超時時間的介紹，請參見使用限制。

    • 修改查詢超時時間的方法，請參見Config和Hint配置參數。

  • 集群壓力較大

    當集群出現較大壓力時，內部節點通信超時或者內部進程無法服務都會導致查詢失敗。

• Readonly

  當系統發現Raft Log出現問題時，會直接將進程狀態置為Readonly，此時寫入操作會出現報錯。

• Timeout

  當系統無法即時消費Raft Log Queue（例如有超長主鍵導致寫入慢等），此時會出現反壓，最終導致寫入速度變慢，出現Timeout報錯。

表讀取結果數據量

AnalyticDB for MySQL的數據會存儲在不同的存儲節點上。表讀取結果數據量展示某個時間點，多個存儲節點上所有SQL查詢從存儲層返回到計算層的數據量。

如下圖所示，在某個時間點（Time_1），假設共有6條SQL語句（query1、query2、query3、query4、query5、query6）分別從6張表（user、report、customer、test、region、partition）中讀取數據。在該時間點，表讀取結果數據量為20.1 GB（計算方法為：1.6+2+3+0.7+4.8+8=20.1 GB）；表平均讀取結果數據量為6.7 GB（計算方法為：所有存儲節點讀取的數據量/存儲節點個數，即(1.6+2+3+0.7+4.8+8)/3=6.7 GB）；表最大讀取結果數據量為12.8 GB（計算方法為：4.8+8=12.8 GB）。

表讀取結果數據量、表最大讀取結果數據量和表平均讀取結果數據量能在一定程度上反映SQL查詢對集群的壓力。

• 當表平均讀取結果數據量突然增加時，說明存儲層中有較多的數據被發送到計算層進行處理，消耗更多的CPU資源和內存資源。同時，從存儲層讀取的數據量增加，也會占用更多的磁盤IO資源。

• 當表最大讀取結果數據量和表平均讀取結果數據量相差較大時，說明從多個存儲節點讀取的數據量存在差異，節點處理的數據量不同會導致某些節點過早地達到資源瓶頸，進而影響集群的整體性能。這種情況通常源于表設計的不合理，例如某些表選擇了不均勻的分布字段，導致數據在多個存儲節點上的分布不均。

寫入、刪除、更新的響應時間增長

寫入響應時間表示INSERT INTO VALUES操作處理每行數據的響應時間；刪除響應時間表示DELETE操作處理每行數據的響應時間；更新響應時間表示UPDATE操作處理每行數據的響應時間。響應時間一般會受到以下因素的影響：

• 存儲節點CPU使用率增高

  存儲節點CPU使用率增高可能受到其他指標增高的影響，例如集群出現了Bad SQL，或者寫入（刪除/更新）的TPS增加等。

• 存儲節點寫相關IO指標增高

  存儲節點寫相關IO指標包括磁盤IO吞吐量和磁盤IOPS等，這些指標增高的可能原因如下：

  • Build任務數增加所致。

  • 執行了備份、擴容等操作。

  因為以上操作都需要對磁盤進行寫入操作，所以可能會影響相關的響應時間。