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

话题一

如何调优系统、部署环境以及 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 性能调优专场”精彩回顾