TiDB 故障诊断与性能排查:发生即看见,一切可回溯,Continuous Profiling 应用
在企业遭遇的 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 信息排查,抓取火焰图,但因为抓取过程中出问题的函数没有运行,没有看到有用的信息
火焰图的查看方式:(源自:https://www.brendangregg.com/flamegraphs.html)
21:10 通过删除 pod 的方式重启了某个 TiKV 节点之后,发现 io 并没有降下来 21:10 - 21:50 客户继续尝试通过删除 pod 的方式重启 TiKV 节点 21:50 再次抓取火焰图,发现 raftstore::store::snap::calc_checksum_and_size 函数处占用的大量的 CPU,确认根因
22:04 采取操作:停止 TiKV pod,删除流量大的 TiKV 节点 snap 文件夹下所有 gen 文件。目前逐渐恢复中
22:25 业务放量,QPS 恢复原先水平,说明操作有效
22:30 集群完全恢复
19:15 新节点上线
19:15 - 19:32 上线的节点由于 OOM 反复重启,导致其他节点上 snapshot 文件积累,节点状态开始异常
19:32 收到响应时间过长业务报警
19:56 客户联系 PingCAP 技术支持,反映情况如下:
集群响应延迟很高,一个 TiKV 节点加入集群后发生掉量,而后删除该节点,但其他 TiKV 节点出现 Disconnect Store 现象,同时发生大量 Leader 调度,集群响应延迟高,服务挂掉
20:00 PingCAP 技术支持上线排查 20:04 - 20: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 集群完全恢复
“持续性能分析” 功能详解
在刚刚发布的 TiDB 5.3 版本中,PingCAP 率先在数据库领域推出 “持续性能分析”(Continuous Profiling)功能(目前为实验特性),跨越分布式系统可观测性的鸿沟,为用户带来数据库源码水平的性能洞察,彻底解答每一个数据库问题。“持续性能分析”是一种从系统调用层面解读资源开销的方法,通过火焰图的形式帮助研发、运维人员定位性能问题的根因,无论过去现在皆可回溯。
火焰图示例
主要应用场景
当数据库意外宕机时,可降低至少 50% 诊断时间
相关文章