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

語言: CN / TW / HK

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 下給我們留言~