作者： 数据源的TiDB学习之路 原文来源： https://tidb.net/blog/513a4eef
背景
前段时间参与了一个 TiDB 的性能测试，具体是在三台海光服务器（512G内存、128 core 分8个NUMA、4块3.5T SSD）搭建一个混合部署的 TiDB 集群，并测试 OLTP 和 OLAP 的性能指标。
TiDB 针对性能优化部分，提供了很多方式方法。比如在配置调优模块，提供操作系统性能参数调优、TiDB/TiKV 内存调优、TiKV 线程调优、Region 调优、TiFlash 调优等；在 SQL 调优模块，针对 SQL 优化流程、控制执行计划等方式提供了多种优化路径。
优化方法虽然多，但是优化起来也比较复杂，且优化的效果可能还不明显，尤其是 TiKV 线程调优部分。相反，恰恰是一些直观的、简单的优化方法，对性能测试却可能起到非常大的帮助。笔者根据自身实践经验概括了以下几点，供大家参考。
NUMA 绑核是最有效的优化手段
早期的计算机系统主要是 SMP(Symmetric Multi-Processor) 架构，也就是对称多处理器架构，所有的 CPU 都通过一条总线来访问内存，内存是统一结构和统一寻址的(UMA，Uniform Memory Architecture)。以前由于一般物理机器的 CPU 核数较少，SMP 架构在这种情况下表现较好，实验证明 SMP 服务器 CPU 利用率最好的情况是2至4个CPU。
然而随着 CPU 多核技术的发展，一颗物理 CPU 中集成了越来越多的 core，导致 SMP 架构的性能瓶颈越来越明显。随着处理器的增加，系统总线成为了瓶颈，另外处理器和内存之间的通信延迟也增大。为解决此问题，NUMA 架构应运而生，NUMA 调整了 CPU 和内存的布局和访问关系。虽然 NUMA 很好的解决了 SMP 架构下 CPU 大量扩展带来的性能问题，但其自身也存在着不足，当 NUMA Node 节点本地内存不足时，需要跨节点访问内存，节点间的访问速度慢，从而也会带来性能下降。要充分利用 NUMA 系统这个特点，应尽量减少不同 CPU 模块之间的交互，避免远程访问资源，如果应用程序能有方法固定在一个 CPU 模块，应用的性能将会有很大的提升。
国产海光服务器一般有 8 个 NUMA Node，而 TiDB 数据库在混合部署模式下，每个物理节点会包括多个组件，如 1*PD、N*TiDB Server、N*TiKV、N*TiFlash 以及监控告警组件。合理的对不同组件绑定不同的 NUMA，在性能上会有非常大的差异。
在集群拓扑配置文件中，可以对不同的组件增加 numa_node 参数来绑定 NUMA。以下表格是同一个测试场景( 百万记录表关联聚合 ) 中针对 TiFlash 组件分别绑定 不同 NUMA Node 时的性能差异。从结果可以看出，在单并发场景下， 每个 TiFlash 绑定 2个 NUMA Node 时可以获得最佳性能 TPS 约为 2.6/秒，而如果绑定 8 个 NUMA Node 时性能最差 TPS 约为 0.7/秒 。
| 并发度 | 8 NUMA | 6 NUMA | 4 NUMA | 2 NUMA | 1 NUMA |
|---|---|---|---|---|---|
| 1 | 0.7 | 未测试 | 2.2 | 2.6 | 2.2 |
| 10 | 3.2 | 未测试 | 10.1 | 7.2 | 未测试 |
| 20 | 3.4 | 7.8 | 未测试 | 未测试 | 未测试 |
同样测试场景在 10 并发 情况下，TiFlash 组件分别绑定不同 NUMA Node，可以看出当 每个 TiFlash 绑定 4 个 NUMA 时可以获得最佳性能 TPS 10.1/秒，而在 8 个 NUMA 时性能最差为 TPS 3.2/秒 。在 20 并发 时， 绑定 6 个 NUMA 也比绑定 8 个 NUMA 要快 2 倍以上 。
从以上测试结果可以看出，NUMA 的绑核对于性能有着非常大的影响。在并发较低时，绑定较少的NUMA将获得更佳的性能，在上述案例中，单并发百万表关联聚合场景在 2个 NUMA 时可以获得最佳性能，这比不绑定 NUMA 或绑定所有 NUMA 性能高出 3 倍。在并发较高时，多绑定几个 NUMA 性价比更高，上述案例在 10 并发百万表关联聚合场景时 4个 NUMA 性能最佳，但不绑定 NUMA 性能仍然是最差的。
TiFlash 并不是越多性能越好
每台服务器有4块 SSD 磁盘，起初每台上面部署 2 个 TiFlash，每个 TiFlash 使用 2 块磁盘，在10并发百万级表关联聚合场景下 TPS 大约在 9.5~10 之间。 而当把每个节点调整为 1 个 TiFlash 使用 4 块磁盘时，性能可以稳定在 10~10.5 之间 。 当把 3 个 TiFlash 缩容到 2 个 TiFlash 时，性能又进一步提升，TPS 可以接近到 12/秒 。
以上测试结果，说明 TiFlash 并不是越多越好。从原理上，越多的 TiFlash 会造成更多的数据 shuffle 交互，这可能是 TiFlash 多反而不如 TiFlash 少性能好的原因。
| TiFlash 个数 | 平均TPS |
|---|---|
| 6 | 9.8 |
| 3 | 10.3 |
| 2 | 11.8 |
Scatter 打散后可能有意外收获
TiDB 在 PD 管控的调度机制下，基本可以保证每个节点的 Region 数和 Leader 数是均衡的，然而，对于单张表而言，却没有很好的机制可以保证 Region 在任何时刻都能均衡分布在每个 TiKV 节点上。
TiDB 提供了一个 scatter 功能，允许对单张表进行均衡打散。在测试中我们发现，scatter 打散对性能的提升非常明显。以一个 TP 类的测试场景为例， 未 scatter 前的平均 TPS 约为 4千/秒，在 scatter 之后平均 TPS 可以达到 6千/秒。
| 平均TPS | |
|---|---|
| Scatter 前 | 4000 |
| Scatter 后 | 6000 |
总结
本篇幅简单整理了 TiDB 性能测试中的几个优化点，包括 NUMA 绑核、TiFlash 个数变化以及 Scatter 对性能的影响，这些优化手段比复杂的参数优化更简单直观，获得的收益可能也会更大，可以作为性能优化和性能测试中常用的手段。NUMA 绑核主要适用于NUMA较多的服务器，TiFlash 适用于使用 TiFlash 做AP分析类场景测试，Scatter 针对的是 TiKV 中的 region 因此主要用于偏 TP 类场景的测试。