建立本地网站,网站开发开发需求文档模板,海外公司注册在哪里比较好,app生成工具作者#xff1a; 李文杰_Jellybean 原文来源#xff1a; https://tidb.net/blog/d3d4465f 前言 在日常业务使用或运维管理 TiDB 的过程中#xff0c;每个开发人员或数据库管理员都或多或少遇到过 SQL 变慢的问题。这类问题大部分情况下都具有一定的规律可循#xff0c;… 作者 李文杰_Jellybean 原文来源 https://tidb.net/blog/d3d4465f 前言 在日常业务使用或运维管理 TiDB 的过程中每个开发人员或数据库管理员都或多或少遇到过 SQL 变慢的问题。这类问题大部分情况下都具有一定的规律可循通过经验的积累可以快速的定位和优化。但是有些情况下不一定很好排查尤其涉及到内核调优等方向时如果事先没有对各个组件的互访关系、引擎存储原理等有一定的了解往往难以下手。 本文针对写 TiDB 集群的场景总结业务 SQL 在写突然变慢时的分析和排查思路旨在沉淀经验、共享与社区。 写入原理 业务对集群的数据写入流程会被 TiDB Server 封装为一个个的写事务写事务的完成主要涉及的组件是 TiDB Server 和 TiKV Server。如下所示是 TiDB 集群写入流程的架构简图 事务在写入的过程分别会与 TiDB Server、TiPD Server 和 TiKV Server进行交互 TiDB Server 用户提交的业务 SQL 经过 Protocol Layer 进行 SQL 协议转换后内部 PD Client 向 TiPD Server 申请到一个 TSO此 TSO 即为事务的开始时间 txn_start_tso同时也是事务在全局的唯一 ID 接着 TiDB Server 对 SQL 文本进行解析处理转为抽象语法树 AST 传给下一个处理模块 TiDB Server 对 AST 进行编译、SQL 等价改写等逻辑优化、参考系统统计信息进行物理优化后会生成真正可以执行的计划 可执行的计划经过分析判断点查询操作转到KV模块、复杂查询转到 DistSQL 模块继续转为对单个表访问的多个请求再经过 TiKV Client 模块与 TiKV 进行交互在 TiDB Server 这一侧完成对数据的访问 TiKV Server TiKV 的 Scheduler Worker Pool 模块负责接收通过 gRPC 传过来的写请求数据在这里它能实现写入流量的控制、锁冲突检查与获取latch、快照snapshot版本对比的功能 前面的校验通过后写入的数据会进入到 Raftstore Pool 模块它会将写入数据的请求封装为 raft log Propose 在本地持久化append的同时并发分发到 follower 节点接着完成 raft log 的 commit 操作最后将 raft log 日志数据写入到 rocksdb raft Apply Pool 模块充当消费者的的角色会消费 rocksdb raft 里面的日志数据转为真正的 KV 数据存储到 rocksdb KV至此完成了一次写入数据的流程 rocksdb 里面的数据写入包括了 LSM Tree 的写入过程主要方面有 WAL、MemTable 、Immutable Table、L0~L6 层的内存或磁盘 IO 操作这里并没有详细阐述有兴趣的可以前往官网查阅。 图中 Raftstore Pool 和 Apply Pool 这两步通常统称为 Async Write 操作这个是 TiKV 写入数据的关键流程也是数据写入分析的重点环节所在。 Raftstore Pool 和 Apply Pool 处理数据的过程涉及到线程池的调度和处理等主要消耗 CPU 资源 rocksdb raft 和 rocksdb kv 由于涉及到数据落盘主要消耗磁盘 IO 资源 数据在不同 TiKV 节点之间进行复制、同步等主要消耗网络带宽 IO 资源 写变慢排查思路 常规排查 通常业务的 SQL 变慢后我们在 TiDB Server 的 Grafana 面板可以看到整体的或者某一百分位的请求延迟会升高我们可以依次排查物理硬件环境、是否有业务变更操作、数据库运行的情况等定位到问题后再针对性解决。 如上图是一个写入慢的常规排查思路在实际工作中对于各项内容的排查可以同时进行交叉分析互相配合定位问题所在。 遇到问题先到 Dashboard 看看对整个集群运行状况有个整体的把握 查看集群热力图关注集群高亮的区域分析是否有写热点出现如果有则确认对应的库表、Region 等信息 排查慢 SQL 情况查看集群慢查询结果分析 SQL 慢查询原因 查看 TOP SQL 面板分析集群的 CPU 消耗与 SQL 关联的情况 物理硬件排查 排查客户端与集群之间、集群内部 TiDB 、TiPD、TiKV 各组件之间的网络问题 排查集群的内存、CPU、磁盘 IO 等情况尤其是混合部署的集群确认是否存在资源相互竞争、挤兑的场景出现 排查操作系统的内核操作是否与官方建议的最佳实践值是否一致确认 TiDB 集群运行在最优的系统环境内 业务变更 确认是否是新上线业务 查看集群的 DDL Jobs确认是否由于在线 DDL 导致的问题特别是大表加索引的场景会消耗集群较多的资源从而干扰集群正常的访问请求 全链路排查 对于常规分析无法确认的或者复杂业务的问题通常排查起来比较棘手这时候可以分析数据从写入 TiDB Server 到 TiKV Server 、再落盘至 RocksDB 的整个过程对全部写入链路逐一进行排查从而确认写入慢所在的节点定位到原因后再进行优化即可这一过程大致如下图所示。 毫无疑问这个是一个兜底的排查思路适用范围较广通用性较强但是排查起来要花费更多的时间和精力也要求管理员对数据库本身的运行原理有一定的掌握。 对于写入慢的全链路分析我们首先在问题时段从整体上把握延迟情况再分析 TiDB Server 和 TiKV Server 在对应时段的延迟确认问题处于计算层还是存储层接着再深入分析 对于 TiDB Server层主要观察 SQL 的解析优化过程耗时以及和 TiPD 进行交互过程的延迟情况 对于 TiKV Server 层重点关注 Scheduler Worker Pool 、Raft log 同步复制与写入、Apply 这几个过程 上面的写入过程的延迟情况可以从集群的 Grafana 监控面板观察得到其中 TiKV 是重点所在其每个阶段写入的流程以及对应在 Grafana 上的延迟监控面板如下。 gRPC duration 或 Scheduler command duration 表示整个写入过程在 TiKV 侧的耗时情况 gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长说明 TiDB 和 TiKV 之间网络延迟可能很高或者 TiDB 和 TiKV 之间的网卡带宽被占满 TiKV Details 下 Scheduler - commit 的 Scheduler command duration 表示执行 commit 命令所需花费的时间正常情况下应该小于 1s TiKV Details 下 Scheduler - commit 的 Scheduler latch wait duration表示由于等到锁 latch wait 造成的时间开销正常情况下应该小于 1s !---- TiKV Details 下 Storage 的 Storage async snapshot duration 表示异步处理 snapshot 所花费的时间99% 的情况下应该小于 1s TiKV Details 下 Storage 的 Storage async write duration 表示异步写所花费的时间99% 的情况下应该小于 1s TiKV Details 下 Raft propose 的 Propose wait duration 表示将写入数据请求转为 raft log 的等待时间 TiKV Details 下 Raft IO 的 Append log duration 表示 Raft append 日志所花费的时间 TiKV Details 下 Raft IO 的 Commit log duration 表示 Raft commit 日志所花费的时间 TiKV Details 下 Raft propose 的 Apply wait duration 表示 apply 的等待时间 TiKV Details 下 Raft IO 的 Apply log duration 表示 Raft apply 日志所花费的时间 通过对比分析不同阶段的延迟在整体中的占比通常可以定位到比较慢的环节然后再针对性优化即可。 总结 常规写入慢的问题我们可以依次排查物理硬件环境、是否有业务新上线是否有 DDL 变更操作、执行计划不准、热点问题等情况通常可以定位到问题再针对性解决 对于复杂问题则需要对写入过程逐一分析和对比通常需要反复观察、对比、验证才能找到根本的原因 对于开发人员或 DBA会解决具体的问题是一项很重要的能力但定位问题根因所在的能力更难能可贵 这里想表达的意思和大家耳熟能详的故事异曲同工 “老师傅故障已排除但就凭这一条线也要 10000$ ” “画这条线要 1$但知道在哪里画要 9999$”
