TiDB 實(shí)踐 | TiDB 故障診斷與性能排查：發(fā)生即看見，一切可回溯，Continuous Profiling 應(yīng)用實(shí)踐
在企業(yè)遭遇的 IT 故障中，約有 30% 與數(shù)據(jù)庫相關(guān)。當(dāng)這些故障涉及到應(yīng)用系統(tǒng)、網(wǎng)絡(luò)環(huán)境、硬件設(shè)備時(shí)，恢復(fù)時(shí)間可能達(dá)到數(shù)小時(shí)，對業(yè)務(wù)連續(xù)性造成破壞，影響用戶體驗(yàn)甚至營收。在復(fù)雜分布式系統(tǒng)場景下，如何提高數(shù)據(jù)庫的可觀測性，幫助運(yùn)維人員快速診斷問題，優(yōu)化故障處理流程一直是困擾著企業(yè)的一大難題。
一次海量數(shù)據(jù)場景下的性能排查經(jīng)歷
沒有 Continuous Profiling 的客戶故障排查案例
19:15 新節(jié)點(diǎn)上線 19:15 - 19:32 上線的節(jié)點(diǎn)由于 OOM 反復(fù)重啟，導(dǎo)致其他節(jié)點(diǎn)上 snapshot 文件積累，節(jié)點(diǎn)狀態(tài)開始異常
19:32 收到響應(yīng)時(shí)間過長業(yè)務(wù)報(bào)警
19:56 客戶聯(lián)系 PingCAP 技術(shù)支持，反映情況如下：
集群響應(yīng)延遲很高，一個(gè) TiKV 節(jié)點(diǎn)加入集群后發(fā)生掉量，而后刪除該節(jié)點(diǎn)，但其他 TiKV 節(jié)點(diǎn)出現(xiàn) Disconnect Store 現(xiàn)象，同時(shí)發(fā)生大量 Leader 調(diào)度，集群響應(yīng)延遲高，服務(wù)掛掉
20:00 PingCAP 技術(shù)支持上線排查
20:04 - 21:08 技術(shù)支持對多種指標(biāo)進(jìn)行排查，從 metrics 的 iotop 發(fā)現(xiàn) raftstore 線程讀 io 很高，通過監(jiān)控發(fā)現(xiàn)有大量的 rocksdb snapshot 堆積，懷疑是 region snapshot 的生成導(dǎo)致的，建議用戶刪掉之前故障 TiKV 節(jié)點(diǎn)上的 pending peer，并重啟集群
20:10 -?20:30 技術(shù)支持同時(shí)對 profiling 信息排查，抓取火焰圖，但因?yàn)樽ト∵^程中出問題的函數(shù)沒有運(yùn)行，沒有看到有用的信息
火焰圖的查看方式：（源自：https://www.brendangregg.com/flamegraphs.html）
21:10 通過刪除 pod 的方式重啟了某個(gè) TiKV 節(jié)點(diǎn)之后，發(fā)現(xiàn) io 并沒有降下來 21:10 - 21:50 客戶繼續(xù)嘗試通過刪除 pod 的方式重啟 TiKV 節(jié)點(diǎn) 21:50 再次抓取火焰圖，發(fā)現(xiàn) raftstore::store::snap::calc_checksum_and_size 函數(shù)處占用的大量的 CPU，確認(rèn)根因
22:04 采取操作：停止 TiKV pod，刪除流量大的 TiKV 節(jié)點(diǎn) snap 文件夾下所有 gen 文件。目前逐漸恢復(fù)中
22:25 業(yè)務(wù)放量，QPS 恢復(fù)原先水平，說明操作有效
22:30 集群完全恢復(fù)
19:15 新節(jié)點(diǎn)上線
19:15 - 19:32 上線的節(jié)點(diǎn)由于 OOM 反復(fù)重啟，導(dǎo)致其他節(jié)點(diǎn)上 snapshot 文件積累，節(jié)點(diǎn)狀態(tài)開始異常
19:32 收到響應(yīng)時(shí)間過長業(yè)務(wù)報(bào)警
19:56 客戶聯(lián)系 PingCAP 技術(shù)支持，反映情況如下：
集群響應(yīng)延遲很高，一個(gè) TiKV 節(jié)點(diǎn)加入集群后發(fā)生掉量，而后刪除該節(jié)點(diǎn)，但其他 TiKV 節(jié)點(diǎn)出現(xiàn) Disconnect Store 現(xiàn)象，同時(shí)發(fā)生大量 Leader 調(diào)度，集群響應(yīng)延遲高，服務(wù)掛掉
20:00 PingCAP 技術(shù)支持上線排查 20:04 - 20:40 技術(shù)支持對多種指標(biāo)進(jìn)行排查，從 metrics 的 iotop 發(fā)現(xiàn) raftstore 線程讀 io 很高，通過監(jiān)控發(fā)現(xiàn)有大量的 rocksdb snapshot 堆積，懷疑是 region snapshot 的生成導(dǎo)致的 20:10 -?20:40 技術(shù)支持同時(shí)對 continuous profiling 信息排查，查看故障發(fā)生時(shí)刻的多個(gè)火焰圖，與未發(fā)生故障的正?；鹧鎴D對比，發(fā)現(xiàn) raftstore::store::snap::calc_checksum_and_size 函數(shù)占用的大量的 CPU，確認(rèn)根因 20:55 采取操作：停止 TiKV pod，刪除流量大的 TiKV 節(jié)點(diǎn) snap 文件夾下所有 gen 文件。目前逐漸恢復(fù)中 21:16 業(yè)務(wù)放量，QPS 恢復(fù)原先水平，說明操作有效 21:21 集群完全恢復(fù)
“持續(xù)性能分析” 功能詳解
在剛剛發(fā)布的 TiDB 5.3 版本中，PingCAP 率先在數(shù)據(jù)庫領(lǐng)域推出 “持續(xù)性能分析”（Continuous Profiling）功能（目前為實(shí)驗(yàn)特性），跨越分布式系統(tǒng)可觀測性的鴻溝，為用戶帶來數(shù)據(jù)庫源碼水平的性能洞察，徹底解答每一個(gè)數(shù)據(jù)庫問題。“持續(xù)性能分析”是一種從系統(tǒng)調(diào)用層面解讀資源開銷的方法，通過火焰圖的形式幫助研發(fā)、運(yùn)維人員定位性能問題的根因，無論過去現(xiàn)在皆可回溯。
火焰圖示例
主要應(yīng)用場景
當(dāng)數(shù)據(jù)庫意外宕機(jī)時(shí)，可降低至少 50% 診斷時(shí)間
