北京“TiDB 性能调优专场”活动小组讨论结论

作者： 张鱼小丸子 -PingCAP 原文来源：https://tidb.net/blog/5f3dce79

话题一

如何调优系统、部署环境以及 TiDB 的各种参数，保障 TiDB 高效稳定运转？

讨论总结：

我们主要讨论了四个问题。

第一是如何防止业务抖动。在我们应用的场景之下，TiKV 离线或者往 TiKV 里加机器的时候，Leader 之间会有 Transfer 的情况，TiKV 做若干动作，导致我们的业务不太平稳。我们的总结是，慢就是快。在加节点的时候，节点未 Ready 之前不要把 Leader 切过来，这是一个 high level 的方式。

第二个是部署的易用性。现在社区提供两种方式部署，第一种是用 Ansible，运维人员大都比较熟悉，但是它有个特别大的问题是多个集群不好维护。第二种方式是用 K8S。K8S 有个好处就是不用维护那么多东西。但是要使用 K8S 管理大规模集群，可能团队需要一个 K8S 工程师，而且它引入了另外一个问题：TiDB 集群本身是一个集群，上面再加一个 K8S 的话，发生故障后要定位到底是 K8S 的问题还是 TiDB 集群的问题，是一件非常麻烦的事情。所以我们认为应该有一个集中式的部署中心，在里面统一管理部署和监控的需求。

第三，我们现在发现不论是 HAProxy，还是 LVS，作为 TiDB 的一个 Proxy，它本身对于 SQL 打到哪个机器上的机制还有些欠缺。我们更希望 Proxy 能够有一个更智能的机制，通过 SQL 预判 Session 打到了哪个 Server。

话题二

线上故障定位排查

讨论结果：

我们主要分了几个重点问题，也就是通常线上出现故障，我们会从几个角度来看。

• 最常见的是监控 /Grafana，还有自己的 TiDB 和 TiKV 的报错日志，或者常见的社区里边有哪些坑，我们都可以参考来解决。

• 像 IO 使用率高的问题，可以使用闪存卡，我们线上的业务 IO 使用率 90%，使用闪存卡降到 20%，直接解决了这个问题。

• 还有就是升级对于业务的影响，升级对于我们的影响不大，因为我们当前上的业务不是太重要，都是我们白天找适当的时间来做，因为正常影响我们的话，Grafana 的 QPS 显示，正常它是在一千左右，升级到 TiDB 3.0.3 版本有 1 分钟降到 700 左右，这是对业务的一个影响，业务都可接受的。所以我们正常的白天升级了。

• 还有锁冲突多的场景会频繁发生锁的问题，这是涉及悲观锁和乐观锁，会有一些参数调优，我们接触的比较少。

• 剩下大家关注的问题，有些配置，像网卡，我们有一个静默 region，或者将网卡升级为万兆，或者可以通过扩节点，扩 TiDB 或 TiKV，来提高数量，降低 TiKV 之间的网卡消耗情况。

• 剩下就是 CPU 与 TiKV 的实例数推荐。比如说 40 多核 CPU，我们 TiKV 可以部署两个，官方的意思大概一个 TiKV 需要 16 核 CPU，如果你是 24 核 CPU，部署一个 TiKV，这样 CPU 的消耗不会那么高；我们是单机四个 TiKV，那时候是 24 核 CPU，我们 TiKV 机器宕机的次数比较多，CPU 一直 80% 左右，后来下了两个节点，CPU 就恢复到百分之五六十了。相对好一点。

• 还有高 QPS 这个业务，可以通过适当扩容 TiKV 来部分解决，我们业务方通过 Cache 来解决。因为 TiDB 是底层的数据库，高负载能力是有限的，可以通过 Cache 解决。

• 剩下就是重点监控项，Grafana 中我们常关注的一些项包括机器 CPU，IO，网卡，内存使用量，实例里面 SQL 的执行时间，QPS，每个 SQL 插入的量，还有失败重试的次数也可以观察一下，从这些重点监控项来看 TiDB 的故障情况。

话题三

如何优化 SQL 和 TiDB 相关的参数设定来改善在线业务的 latency 和 throughput 表现，控制运维操作对线上性能的影响？

讨论结果：

第一步，我们首先判断问题的原因，看怎么从慢查询日志里很快判断一个 SQL 到底是慢在 TiDB 上，还是慢在 TiKV 上。

第二步，当我们判断问题大概率是出在 TiDB 上的时候，下一步我们关注执行计划对不对，关注一下这个地方的统计信息准不准。统计信息有些相关的参数，一般在 3.0 是默认打开收集参数，当前默认数据量到 50% 的时候，会自动触发收集统计信息。如果对执行计划准确度要求比较高，建议把这参数稍微调低一些。

另外，在执行计划不准确的情况下，可能统计信息没法实时收集，实在不行的时候，我们建议和业务方商量一下，强制反馈执行计划。这样的话，即使统计信息变化，这个 SQL 也是会按照我们希望的执行计划去执行的。TiDB 3.0 版本接入了 SQL plan management 的功能，也就说业务方不需要修改 SQL，也可以反馈需要的执行计划。

我们的下一个建议是，在某些特定的场景下，比如 OLAP，确实是可以适当的修改一些并行参数，能够提高 SQL 执行效率。

最后，如果实在没有办法，可以适当升级的一下自己的 TiKV 或者 TiDB 硬件配置，加大内存，比如说可以通过 hashjoin 来代替原来的 nestedloopjoin 方式，提高性能。

更多阅读：

TUG 北京区第三场线下活动“TiDB 性能调优专场”精彩回顾