在 ARM64 上面运行 TiDB

相比于 Intel 的 x86-64 架构，ARM 架构虽然作为后来者，但在服务器领域也开始在不停地攻城拔寨，很多企业也开始将自己的服务迁移到 ARM 架构上面，自然，对于 TiDB 来说，大家也想将 TiDB 运行到 ARM 上面。因为 AWS 上面直接提供了 ARM 机型，所以我们决定先尝试在 AWS 的 ARM 上面编译运行 TiDB。

TiDB 主要包含三个组件 - PD，TiKV 和 TiDB，对于 PD 和 TiDB 来说，使用的是 Go 进行编译的，所以我们只需要在 ARM 机器上面装好 Go 的版本就可以了。这里，我使用的是 go1.12.6.linux-arm64 这个版本。

用 Go 编译 TiDB 和 PD 比较容易，中途遇到了一个 TiDB 的编译问题，只需要升级下 vendor 就解决了。

编译 TiKV 就比较麻烦了，因为我们使用的是 CentOS 系统，系统用 yum 就能安装相关的依赖，除了 cmake3 ，装 cmake 需要做如下处理：

当然，编译 RocksDB 还有 Titan 的时候还遇到了一些错误，不过多数就是传递编译参数的时候需要处理下 ARM64 相关的选项，并不是特别的困难。

总的来说，编译并没有花太多的时间，这里有一个 脚本 ，大家可以自行去看如何在 ARM64 上面编译 TiDB。对于运行集群需要的 Grafana 和 Prometheus，官方都提供了 ARM64 版本，大家可以直接去 Google。

编译好了 ARM64 的版本，自然就是测试了，这里我使用了 go-ycsb 进行了简单的测试，这里我使用的是 16c32g 的 ARM64 机器，顺带也开了一台同配置的 x86 作为对比。

在每台测试机器上面，启动一个 PD，一个 TiKV，使用的是默认配置，然后 go-ycsb 使用 100 并发，导入 1 百万数据， *** 作次数 1 百万，batch size 为 0。

结果如下：

可以看到，ARM 的机器性能比 x86 的差了很多，需要来优化了。在网上找了这篇 文章 ，使用了上面的脚本，但发现没有什么变化。在这个脚本里面，主要的优化就是将网卡中断的处理绑定到某一个 CPU 上面，然后将 RPS 分散到不同的 CPU。对于 16c32g 的机器来说，这个脚本将网卡中断的处理绑定到 CPU core 0 和 8 上面，然后把 RPS 分散到所有的 CPU 上面，但是我通过 mpstat 发现，core 0 和 8 几乎被打满：

于是我重新调了下，将 RPS 分散到除开 core 0 和 8 的地方：

然后 OPS 稍微提升了一点，但 CPU core 0 和 8 仍然是瓶颈。而这个瓶颈明显是网络处理造成的，直观的优化就是减少网络消息的处理，于是将 batch size 设为 128，可以发现在 ARM 上面性能提升很多，譬如对于 workload C，OPS 能提升到 118270。但即使这样，CPU core 0 和 8 还是会成为瓶颈。

对比 ARM，x86 下面 CPU 的分配明显的均匀很多：

所以后面我们要考虑的事情就是如何让 ARM 能更好的处理网络消息。

上面简单的说了一下如何在 ARM 上面编译运行 TiDB，以及一些调优策略。个人认为，虽然 ARM 在性能上面还赶不上相同配置的 x86，但低功耗，成本这些是一个非常大的优势，加上很多不可说的原因，个人认为会有越来越多的企业使用 ARM，所以这块也会是趋势。

虚拟机linux下安装 arm-linux-gcc 编译器

①　获取软件源码包arm-linux-gcc-4.3.2.tgz

②　解压以上文件 按照路径放到 /usr/local/arm/4.3.2(版本号)

③　向linux声明、注册：

找到配置文件 /etc/profile ，打开profile 在倒数第二行添加以下语句：

PATH=/usr/local/arm/4.3.2(源码包中的一个文件夹—版本号)/bin:$PATH

④　运行profile文件：

在终端中使用命令：source /etc/profile

⑤　查看路径：

在终端中使用命令：echo $PATH

若有路径 /usr/local/arm/4.3.2/bin: 表示安装成功

⑥　编译命令：arm-linux-gcc -o test test.c (gcc编译器中用的是：gcc -o test test.c)

运行命令：./test

---