在企業遭遇的 IT 故障中，約有 30% 與資料庫相關。當這些故障涉及到應用系統、網路環境、硬體裝置時，恢復時間可能達到數小時，對業務連續性造成破壞，影響使用者體驗甚至營收。在複雜分散式系統場景下，如何提高資料庫的可觀測性，幫助運維人員快速診斷問題，優化故障處理流程一直是困擾著企業的一大難題。
一次海量資料場景下的效能排查經歷
沒有 continuous profiling 的客戶故障排查案例
- 19:15 新節點上線
- 19:15 - 19:32 上線的節點由於 OOM 反覆重啟，導致其他節點上 Snapshot 檔案積累，節點狀態開始異常
- 19:32 收到響應時間過長業務報警
19:56 客戶聯絡 PingCAP 技術支援，反映情況如下：
- 叢集響應延遲很高，一個 TiKV 節點加入叢集后發生掉量，而後刪除該節點，但其他 TiKV 節點出現 Disconnect Store 現象，同時發生大量 Leader 排程，叢集響應延遲高，服務掛掉。
- 20:00 PingCAP 技術支援上線排查
- 20:04 - 21:08 技術支援對多種指標進行排查，從 metrics 的 iotop 發現 raftstore 執行緒讀 io 很高，通過監控發現有大量的 rocksdb snapshot 堆積，懷疑是 region snapshot 的生成導致的，建議使用者刪掉之前故障 TiKV 節點上的 pending peer，並重啟叢集。
- 20:10 ~ 20:30 技術支援同時對 profiling 資訊排查，抓取火焰圖，但因為抓取過程中出問題的函式沒有執行，沒有看到有用的資訊。
<center>火焰圖的檢視方式：（源自：https://www.brendangregg.com/flamegraphs.html）<center>
y 軸表示呼叫棧，每一層都是一個函式。呼叫棧越深，火焰就越高，頂部就是正在執行的函式，下方都是它的父函式。
x 軸表示抽樣數，如果一個函式在 x 軸佔據的寬度越寬，就表示它被抽到的次數多，即執行的時間長。注意，x 軸不代表時間，而是所有的呼叫棧合併後，按字母順序排列的。火焰圖就是看頂層的哪個函式佔據的寬度最大。只要有 "平頂"（plateaus），就表示該函式可能存在效能問題。顏色沒有特殊含義，因為火焰圖表示的是 CPU 的繁忙程度，所以一般選擇暖色調。
從以上檢視方式可以發現，這次抓取到的火焰圖並沒有一個大的 “平頂”，所有函式的寬度（執行時間長）都是不會太大。在這個階段，沒能直接從火焰圖發現效能瓶頸是令人失望的。這時候客戶對於恢復業務已經比較著急。
- 21:10 通過刪除 pod 的方式重啟了某個 TiKV 節點之後，發現 io 並沒有降下來。
- 21:08 - 21:53 客戶繼續嘗試通過刪除 pod 的方式重啟 TiKV 節點。
- 21:50 再次抓取火焰圖，發現 raftstore::store::snap::calc_checksum_and_size 函式處佔用的大量的 CPU，確認根因。
這次抓取到的火焰圖發現一個明顯的 “大平頂”，可以明顯看到是 raftstore::store::snap::calc_checksum_and_size 函式。這個函式佔用了大量的 CPU 執行時長，可以確定整體效能瓶頸就在這裡函式相關的功能。到這一步，我們確定了根因，並且也可以根據根因確定恢復方案。 - 22:04 採取操作：停止 TiKV pod，刪除流量大的 TiKV 節點 snap 資料夾下所有 gen 檔案。目前逐漸恢復中。
- 22:25 業務放量，QPS 恢復原先水平，說明操作有效。
- 22:30 叢集完全恢復
叢集恢復耗時：19:56 - 22:30，共 2 小時 34 分（154 分）。
確認根因，提出有效操作耗時：19:56 - 22:04，共 2 小時 8 分（128 分）。
在這個案例中，如果我們能夠有一個在故障前、中、後期，連續性地對叢集進行效能分析的能力，我們就可以直接對比故障發生時刻和故障前的火焰圖，快速發現佔用 CPU 執行時間較多的函式，極大節約這個故障中發現問題根因的時間。因此，同樣的案例，如果有 continuous profiling 功能：
- 19:15 新節點上線
- 19:15 - 19:32 上線的節點由於 OOM 反覆重啟，導致其他節點上 snapshot 檔案積累，節點狀態開始異常
- 19:32 收到響應時間過長業務報警
19:56 客戶聯絡 PingCAP 技術支援，反映情況如下：
- 叢集響應延遲很高，一個 TiKV 節點加入叢集后發生掉量，而後刪除該節點，但其他 TiKV 節點出現 Disconnect Store 現象，同時發生大量 Leader 排程，叢集響應延遲高，服務掛掉
- 20:00 PingCAP 技術支援上線排查
- 20:04 - 21:40 技術支援對多種指標進行排查，從 metrics 的 iotop 發現 raftstore 執行緒讀 io 很高，通過監控發現有大量的 rocksdb snapshot 堆積，懷疑是 region snapshot 的生成導致的
- 20:10 ~ 20:40 技術支援同時對 continuous profiling 資訊排查，檢視故障發生時刻的多個火焰圖，與未發生故障的正常火焰圖對比，發現 raftstore::store::snap::calc_checksum_and_size 函式佔用的大量的 CPU，確認根因
- 20:55 採取操作：停止 TiKV pod，刪除流量大的 TiKV 節點 snap 資料夾下所有 gen 檔案。目前逐漸恢復中
- 21:16 業務放量，QPS 恢復原先水平，說明操作有效
- 21:21 叢集完全恢復
叢集恢復（預期）耗時：19:56 ~ 21:21，共 1 小時 25 分（85 分），相比下降 44.8 %。
確認根因，提出有效操作（預期）耗時：19:56~20:55，共 59 分，相比下降 53.9 %。
可以看到該功能可以極大縮短確定根因時間，儘可能幫助客戶換回因效能故障造成的業務停擺損失。
“持續效能分析” 功能詳解
在剛剛釋出的 TiDB 5.3 版本中，PingCAP 率先在資料庫領域推出 “持續效能分析”（Continuous Profiling）功能（目前為實驗特性），跨越分散式系統可觀測性的鴻溝，為使用者帶來資料庫原始碼水平的效能洞察，徹底解答每一個資料庫問題。
“持續效能分析” 是一種從系統呼叫層面解讀資源開銷的方法。引入該方法後，TiDB 提供了資料庫原始碼水平的效能洞察，通過火焰圖的形式幫助研發、運維人員定位效能問題的根因，無論過去現在皆可回溯。
持續效能分析以低於 0.5% 的效能損耗實現了對資料庫內部執行狀態持續打快照（類似 CT 掃描），以火焰圖的形式從系統呼叫層面解讀資源開銷，讓原本黑盒的資料庫變成白盒。在 TiDB Dashboard 上一鍵開啟持續效能分析後，運維人員可以方便快速地定位效能問題的根因。
<center>火焰圖示例<center>
主要應用場景
- 當資料庫意外當機時，可降低至少 50% 診斷時間
在網際網路行業的一個案例中，當客戶叢集出現報警業務受影響時，因缺少資料庫連續效能分析結果，運維人員難以發現故障根因，耗費 3 小時才定位問題恢復叢集。如果使用 TiDB 的持續效能分析功能，運維人員可比對日常和故障時刻的分析結果，僅需 20 分鐘就可恢復業務，極大減少損失。
- 在日常執行中，可提供叢集巡檢和效能分析服務，保障叢集持續穩定執行
持續效能分析是 TiDB 叢集巡檢服務的關鍵，為商業客戶了提供叢集巡檢和巡檢結果資料上報。客戶可以自行發現和定位潛在風險，執行優化建議，保證每個叢集持續穩定執行。
- 在資料庫選型時，提供更高效的業務匹配
在進行資料庫選型時，企業往往需要在短時間內完成功能驗證、效能驗證的流程。持續效能分析功能能夠協助企業更直觀地發現效能瓶頸，快速進行多輪優化，確保資料庫與企業的業務特徵適配，提高資料庫的選型效率。
深入瞭解和體驗 “持續效能分析”：https://docs.pingcap.com/zh/tidb/stable/continuous-profiling