看不懂監控怎麼辦?TiDB 新推出了耗時關係圖

TiDB 使用 Prometheus 和 Grafana 提供了非常詳細的監控指標。在遇到各種性能或穩定性問題時,這些監控一般是問題的關鍵線索。但詳盡的細節監控指標使用門檻較高,剛入門的 TiDB DBA 可能難以上手,例如:

  • 如何快速瞭解當前集羣最耗時的是哪類操作?

  • 發現寫入耗時很長,如何進一步定位原因,應該查看哪些監控項?

  • 監控項這麼多,它們之間的關係是什麼?

TiDB 4.0.7 起提供了一個新功能,可以將數據庫各個內部流程的耗時監控按父子關係繪製爲關係圖,幫助用戶快速以另一種維度瞭解集羣狀態。

簡介

監控關係圖是在指定的時間範圍內,將各個監控項按父子關係繪製的關係圖。圖中每個方框節點代表一個監控項,包含了以下信息:

  • 監控項的名稱

  • 監控項的總耗時

  • 監控項總耗時和查詢總耗時的比例

父節點監控的總耗時 = 自己的耗時 + 孩子節點的耗時,所以有些節點還會顯示自己的耗時和總耗時的比例。

例如下面監控節點表示:tidb_execute 監控項的總耗時爲 19306.46 秒,佔總查詢耗時的 89.4%,其中本身的耗時是 9070.18 秒,佔總查詢耗時的 42%。將鼠標懸停在該方框上,可以看到監控項的註釋說明,總次數,平均耗時,平均 P99 耗時等更多該監控的信息。

每個節點的大小和顏色深淺,與監控項自己的耗時佔總查詢耗時的比例成正比。一般在這個圖中可以重點關注耗時較多的監控節點,然後順着父子關係向下梳理。詳細介紹請參考官方文檔。話不多說,來看兩個簡單的示例吧。

示例 1

最近新上線一個業務後,原來的集羣響應突然變慢了很多,小明看服務器 CPU 都挺空閒的呀,然後抓了一個監控關係圖如下:

可以很快發現,上圖中:

  1. tidb_query.Update 表示 update 語句的執行耗時佔總查詢耗時的 99.59%。

  2. tidb_execute 表示 TiDB 的執行引擎本身耗時佔 68.69%

  3. tidb_txn_cmd.commit 表示事務提交的耗時佔總耗時的 30.66%

  4. tidb_kv_backoff.txnLock 表示事務遇到鎖衝突的 backoff 總耗時佔 15%,這要比發送 prewrite 和 commit 的 tidb_kv_request 的耗時高很多。

到此,可以確定 update 語句存在嚴重的寫衝突,可以按照 樂觀事務模型下寫寫衝突問題排查 進一步排查衝突的表和 SQL 語句,然後和業務方溝通從業務上避免寫衝突。

示例 2

最近需要導入一批數據到 TiDB 集羣,導入速度有點慢,小明想看看系統現在慢在哪兒,然後看能不能優化下,他抓了一個導入數據時的監控耗時關係圖如下:

上圖中,最下面可以看到 tikv 的 raftstore 在處理 propose 前的等待耗時很長,說明 raftstore 存在瓶頸了,然後可以進一步查看 raftstore cpu,append/apply log 的延遲,如果 raftstore 的 thread cpu 使用率不高,則大概率是磁盤是磁盤的問題。具體可以按照 Performance TiKV Map 中 raftstore 相關模塊和 TiDB 磁盤 I/O 過高的處理辦法 進行排查,

除此之外,可以排查是否存在熱點,可以按照 TiDB 熱點問題處理 進一步排查是否有熱點。

使用介紹

注:生成監控關係圖時,會從 prometheus 中讀取各項監控的數據。所以 TiDB 集羣需要部署 prometheus ,推薦使用 tiup 部署集羣。

登錄 Dashboard 後點擊左側導航的集羣診斷可以進入此功能頁面:

設置區間起始時間區間長度參數後,點擊生成監控關係圖按鈕後,會進入監控關係圖頁面。

最後

本文介紹的監控關係圖旨在幫助用戶快速瞭解 TiDB 集羣的負載情況和衆多監控項之間的關係,後續計劃集成 TiDB Performance Map,把和該項監控項相關的其他監控以及配置也關聯上,進一步完善 TiDB 集羣中各個組件監控項之間的關係。

如有任何疑問或者建議,歡迎在 AskTUG 下給我們留言~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章