本文分享自天翼雲開發者社群《 VictoriaMetrics常見效能問題排查 》，作者 ： YT20

（ https://www.ctyun.cn/developer/article/408979728740421）

叢集架構

VM叢集由以下子模組組成

vmstorage： 儲存原始資料，並根據指定時間範圍和標籤過濾條件等返回查詢資料集

vminsert： 接收資料寫入，並根據指標名和標籤按一致性hash分發至叢集中vmstorage節點

vmselect：執行查詢請求，從資料所在的vmstorage節點獲取資料

每個模組可以獨立擴縮容。其中 vmstorage各節點之間不互相通訊，屬於share nothing架構。如此可以增加叢集可用性，也簡化了叢集維護、擴容。

 

慢攝入

VM慢攝入的常見原因如下：

1.   記憶體不足（活躍時序資料快取）

vmstorage在記憶體中維護一個快取，用於快速檢索每個傳入指標的內部序列ID。此快取名為storage/tsid。VM會根據執行vmstorage的主機上的可用記憶體自動確定此快取大小。如果快取大小不足以容納活躍時序資料的所有條目，則VM會從磁碟載入並重建缺失的條目並將其放入快取中。這需要消耗額外的CPU時間和磁碟IO。

VM官方的Grafana儀表板包含了慢攝入（slow inserts）圖表，其中顯示了資料攝入過程中的storage/tsid快取未命中率。如果圖表顯示慢攝入比例高於5%持續10分鐘以上，則很可能當前的活躍時序資料與storage/tsid快取大小不匹配了。

針對這個問題，有以下方法可以處理：

·  增加執行 VM的主機上的可用記憶體，直到慢攝入比例低於5%：要麼增加每個現有vmstorage節點的可用記憶體，要麼向叢集中新增更多的vmstorage結點。

·  減少活動時序資料的數量。 VM官方Grafana儀表板包含一個顯示活動時序數量的圖表。最近版本的VM提供了cardinality explorer，可以有助於確定和修復高cardinality的資料來源。

2.   高週轉率（ Churn Rate ）

在 VM指標中，Churn Rate即舊時序資料被新時序資料取代的速率。當VM發現新的時序樣本時，它需要為其在內部索引（即indexdb）中註冊，以便在後續的select查詢中快速定位。在內部索引中註冊新時序的過程，比已經註冊過的時序新增新樣本的過程慢一個數量級。因此VM在高週轉率情況下的資料攝入速率會比預期要慢許多。

VM官方Grafana儀表盤提供了Churn Rate圖表，顯示了過去24小時內註冊的新時序資料的平均數量。如果這個數字超過了活動時序的數量，那就需要排查並修復高週轉率的來源。高週轉率最常見的問題來源是取值經常變化的標籤。生產上應儘量避免這樣的標籤。cardinality explorer可以幫助識別這樣的標籤。

3.   資源不足

VM官方Grafana儀表板包含資源利用率圖表，顯示記憶體利用率、CPU利用率、磁碟IO利用率和可用磁碟控制元件。為確保VM有足夠的空閒資源來合理處理工作負載潛在高峰，建議在生產上保留一定的空閒資源，比如50%空閒CPU、50%空閒記憶體、20%可用磁碟空間。

如果 VM元件沒有足夠的空閒資源，就會導致在工作負載增長時其效能顯著下降。例如：

·  如果 CPU空閒率接近0，則VM攝入資料時會出現較大延遲

·  如果空閒記憶體接近 0%，則執行VM元件的OS可能沒有足夠的記憶體用於page cache。VM依靠page cache對最近攝入的資料進行快速查詢。如果OS沒有足夠的可用記憶體用於page cache，則需要從磁碟中重新讀取請求的資料，顯著增加磁碟IO，並降低查詢和資料接收速度。

·  如果可用磁碟空間低於 20%，則VM無法對寫入資料執行後臺合併。這導致磁碟上的資料檔案數量增加，從而降低了資料接收和查詢的速度。

4.   網路延遲

執行叢集版 VM時，需要保證vminsert和vmstorage之間網路延時要足夠低。vminsert負責將寫入資料成批打包並序列傳給vmstorage，即只有前一個資料包回覆ack以後才會發下一個。如果vminsert和vmstorage網路延遲高（比如跨地區部署），則資料攝入速率必然受限。

VM官方Grafana儀表板包含了vminsert元件的connection saturation圖表。如果這個圖表達到100%（1秒內），則vminsert和vmstorage之間的網路延遲必然有問題。另一個導致這個指標100%的可能性是vmstorage資源不足了。

5.   混合部署影響

生產上要確保 VM元件執行在相對獨立的環境中，起碼要保證環境內沒有其他資源消耗大戶程式。如果與其他非常耗資源的程式混合部署，則很難僅透過VM官方Grafana儀表板發現，此時需要檢查執行VM的例項的資源利用率。

慢查詢

VM可透過-search.logSlowQueryDuration命令列標記設定慢查詢時間閾值（預設5s），並提供了/api/v1/status/top_queries介面來給返回執行時間最長的查詢請求。排查解決VM慢查詢問題的常用方法有：

·  直接擴容：為 VM新增更多的CPU和記憶體，因此可以更快地執行慢查詢請求；如果使用叢集版本的VM，那麼將vmselect節點遷移到具有更多CPU和記憶體的機器有助於提高慢查詢請求的速度。查詢效能總是受到處理查詢的一個vmselect的資源的限制。例如，如果vmselect上的2 vCPU不能足夠快地處理查詢，那麼將vmselect遷移到具有4vCPU的機器應該會將繁重的查詢效能提高2倍。如果VM的官方Grafana儀表板上的Concurrent select圖上接近極限，那麼更傾向於向叢集中新增更多的vmselect節點。有時，新增更多的vmstorage節點也有助於提高慢查詢請求的速度。

·  重寫慢查詢請求，使它們變得更快。但僅僅透過觀察很難確定查詢請求是否緩慢。 VM提供了查詢跟蹤功能，可以幫助確定慢查詢的來源。另請參閱本文，其中解釋瞭如何確定和最佳化慢速查詢。

在實踐中，由於子查詢的使用不當，會生成許多慢查詢請求。如果不清楚子查詢是如何工作的，建議避免子查詢。在不知道的情況下建立子查詢很容易。例如， rate（sum（some_metric））根據MetricsQL查詢的隱式轉換規則隱式轉換為子查詢rate ( sum ( default_rollup ( some_metric[1i] ) ) [1i:1i] )。此查詢很可能不會返回預期的結果，應該改為使用sum（rate（some_metric））。