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)
y 轴表示调用栈,每一层都是一个函数。调用栈越深,火焰就越高,顶部就是正在执行的函数,下方都是它的父函数。
x 轴表示抽样数,如果一个函数在 x 轴占据的宽度越宽,就表示它被抽到的次数多,即执行的时间长。注意,x 轴不代表时间,而是所有的调用栈合并后,按字母顺序排列的。火焰图就是看顶层的哪个函数占据的宽度最大。只要有 "平顶"(plateaus),就表示该函数可能存在性能问题。颜色没有特殊含义,因为火焰图表示的是 CPU 的繁忙程度,所以一般选择暖色调。
从以上查看方式可以发现,这次抓取到的火焰图并没有一个大的 “平顶”,所有函数的宽度(执行时间长)都是不会太大。在这个阶段,没能直接从火焰图发现性能瓶颈是令人失望的。这时候客户对于恢复业务已经比较着急。
-
21:10 通过删除 pod 的方式重启了某个 TiKV 节点之后,发现 io 并没有降下来
-
21:10 - 21:50 客户继续尝试通过删除 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 - 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 集群完全恢复
集群恢复(预期)耗时:19:56 - 21:21,共 1 小时 25 分(85 分),相比下降 44.8%。
确认根因,提出有效操作(预期)耗时:19:56 - 20:55,共 59 分,相比下降 53.9%。
可以看到该功能可以极大缩短确定根因时间,尽可能帮助客户挽回因性能故障造成的业务停摆损失。
“持续性能分析” 功能详解
在刚刚发布的 TiDB 5.3 版本中,PingCAP 率先在数据库领域推出 “持续性能分析”(Continuous Profiling)功能(目前为实验特性),跨越分布式系统可观测性的鸿沟,为用户带来数据库源码水平的性能洞察,彻底解答每一个数据库问题。“持续性能分析”是一种从系统调用层面解读资源开销的方法,通过火焰图的形式帮助研发、运维人员定位性能问题的根因,无论过去现在皆可回溯。
持续性能分析以低于 0.5% 的性能损耗实现了对数据库内部运行状态持续打快照(类似 CT 扫描),以火焰图的形式从系统调用层面解读资源开销,让原本黑盒的数据库变成白盒。在 TiDB Dashboard 上一键开启持续性能分析后,运维人员可以方便快速地定位性能问题的根因。
火焰图示例
主要应用场景
当数据库意外宕机时,可降低至少 50% 诊断时间
在互联网行业的一个案例中,当客户集群出现报警业务受影响时,因缺少数据库连续性能分析结果,运维人员难以发现故障根因,耗费 3 小时才定位问题恢复集群。如果使用 TiDB 的持续性能分析功能,运维人员可比对日常和故障时刻的分析结果,仅需 20 分钟就可恢复业务,极大减少损失。
在日常运行中,可提供集群巡检和性能分析服务,保障集群持续稳定运行
持续性能分析是 TiDB 集群巡检服务的关键,为商业客户提供了集群巡检和巡检结果数据上报。客户可以自行发现和定位潜在风险,执行优化建议,保证每个集群持续稳定运行。
在数据库选型时,提供更高效的业务匹配
在进行数据库选型时,企业往往需要在短时间内完成功能验证、性能验证的流程。持续性能分析功能能够协助企业更直观地发现性能瓶颈,快速进行多轮优化,确保数据库与企业的业务特征适配,提高数据库的选型效率。
深入了解和体验 “持续性能分析”:https://docs.pingcap.com/zh/tidb/stable/continuous-profiling
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
让容器跑得更快:CPU Burst 技术实践
作者:常怀鑫、丁天琛 让人讨厌的 CPU 限流影响容器运行,有时人们不得不牺牲容器部署密度来避免 CPU 限流出现。我们设计的 CPU Burst 技术既能保证容器运行服务质量,又不降低容器部署密度。CPU Burst 特性已合入 Linux 5.14,Anolis OS 8.2、Alibaba Cloud Linux2、Alibaba Cloud Linux3 也都支持 CPU Burst 特性。 在 K8s 容器调度中,容器的 CPU 资源上限是由 CPU limits 参数指定。设置 CPU 资源上限可以限制个别容器消耗过多的 CPU 运行时间,并确保其他容器拿到足够的 CPU 资源。CPU limits 限制在 Linux 内核中是用 CPU Bandwidth Controller 实现的,它通过 CPU 限流限制 cgroup 的资源消耗。所以当一个容器中的进程使用了超过 CPU limits 的资源的时候,这些进程就会被 CPU 限流,他们使用的 CPU 时间就会受到限制,进程中一些关键的延迟指标就会变差。 面对这种情况,我们应该怎么办呢?一般情况下,我们会结合这个容器日...
- 下一篇
【网商双十一】基于 ServiceMesh 技术的业务链路隔离技术及实践
文|张化仁(花名:花伦 ) 网商银行基础技术架构部架构师 校对|阚广稳(花名:空门) 本文 4832 字 阅读 10 分钟 |引言| 微服务架构下,服务之间的调用错综复杂,一个应用可能会承载着多种不同的业务流量。由于运行在同一个应用进程内,多种业务流量之间势必会存在相互影响的情况。 如果某种业务流量陡增,导致应用进程负载激增,进而请求排队,其它业务流量也势必会受影响。多数时候这种相互影响的情况都是在容忍范围以内或者可以规避的,特定场景下我们可能就需要考虑通过隔离某些业务流量的方式,来消除业务之间相互影响的风险: 例如,当后台调度型的流量影响了在线用户请求; 再如,当低敏的甚至可失败的业务影响了高敏的需要重保的业务。 业务链路隔离的诉求是业内普遍存在的。通常的方案是新创建一个应用,然后将需要隔离的业务迁移到这个新应用上。 新建应用的方式,研发运维等都需要付出成倍的成本,相关应用还需要配合改造和迁移。对于只有单个应用需要创建的情况或许还能勉强接受,网商银行部分应用例如高保极简网关、高保客户视图等当前就是采用的这种方案。这种方式是非常笨重的,而且当我们期望特定业务关联的整条链路上的多个应用都...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Hadoop3单机部署,实现最简伪集群
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果