共计 3150 个字符，预计需要花费 8 分钟才能阅读完成。
在企业遭逢的 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