0
1
1
0
专栏/.../

TiDB 性能测试的几个优化点

 数据源的TiDB学习之路  发表于  2024-09-25

背景

前段时间参与了一个 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 类场景的测试。 

0
1
1
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论