作者： 数据源的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 类场景的测试。