译者：bzhaoopenstack
原文链接：https://mysqlonarm.github.io/MySQL-on-x86-vs-ARM/
作者: Krunal Bauskar
在开始探索这一领域之前，我相信大家对这个话题都会非常感兴趣，包括本人在内。另外，在深入讨论具体的数据前，让我们先来了解一下两种架构之间的基本差异。除了CISC和RISC之外，让我们从Mysql的角度来看待这些重要的差异。
- 强 vs 弱内存模型 (弱内存模型在无锁写场景下需要适当的内存屏障).
- 底层硬件特定专用指令。例如：两者现在都支持crc32c硬件指令，但是底层调用它们的方式不同。更多指令差异请参看x86-SSE/ARM-ACLE。
- Cache Line 差异。 大多数ARM处理器倾向于使用更大的cacheline size (所有缓存以128 bytes为单位或者 64/128字节混合的方式)。
- 其他系统调用级别的差异，如：ARM的PAUSE指令缺失和具有非常低延迟的替代指令无法引导硬件达到所需的延迟，sched_getcpu在ARM上引入了使用无锁构造的挑战，内存操作似乎带来更高的延迟等。
Mysql社区已经为这个领域的问题贡献了多个补丁（另一个博客的主题）。自从MySQL刚刚宣称开始支持ARM架构以来，几乎没有什么优化，大部分工作仍然没有完成。
性能
现在让我们来看看最重要的方面：性能
我们在x86和ARM上测试了MySQL（当前版本8.0.19）的性能。试验步骤和机器详情如下。
测试步骤
- 24核/48GB Intel(R) Xeon(R) Gold 6266C CPU @ 3.00GHz，用于在x86上运行MySQL数据库软件。
- 24核/48GB ARM @ 2.60GHz，用于在ARM上运行MySQL
- sysbench运行在一台专用的机器，且位于相同的数据中心。
- sysbench步骤:
- 加载测试表. (相同的数据库被多次运行重用，所以需要预热).
- Checksum预热。对所有表执行checksum。对于checksum,流程中需要获取bufferpool中的行记录。
- Query 预热。 如果您使用的是自适应哈希索引，可以跳过此节，但它确实有些效果。
- 执行测试套件 (oltp-read-write/oltp-update-index/oltp-update-non-index/oltp-read-only/oltp-point-select)
- 每个测试套件以多种不同的扩展性来执行。如对于24 vCPU，尝试多threads 1/2/4/8/16/32/128/256.
- 在切换测试套件中间，引入一些睡眠操作确保之前的测试套件完全运行完毕。虽然这不能保证所有的数据库刷新都完成了，但是X秒的睡眠可以保证对后续测试套件的影响最小。
- MySQL-Server Configuration:
- 足够大的BP(bufferpool) ，以保证可以存储完整的数据
- 了解更多配置详情，参看 以下配置
运行脚本和调用sysbench的自动化测试脚本细节在 这里
测试运行具体细节:
- Table: 96-tables * 150万数据 (data-size= 34GB)
- Buffer Pool: 36GB
- Redo-Log: 4GB*2
- TC-run-time: 300 secs
- TC-warmup: 60 (sysbench –warmup-time)
- workload-query-based warmup: 600
- change-over-sleep: 180
- checksum-based-warmup: enabled
- data-storage: 300GB (支持16500 IOPS(对Burst IOPS无效果).)
注: Frequency Scaling (FS)频率缩放. 所述ARM 主频规格2.6 GHz vs x86主频规格3.0 GHz。直接比较它们的数据是不公平的。为了补偿频率差，下面的图还为ARM添加了频率调整 tps/qps（ARM-fscaled简单地按(3/2.6）的算法基于原始数据算出ARM tps/qps数据)。在现实生活中，考虑到CPU频率的增加会影响争用曲线图和等待周期，这个影响因素可能会稍微高一些。
1. Point Select:
| threads | ARM (qps) | x86 (qps) | ARM (qps - fscaled (FS)) | % ARM-vs-x86 | % ARM (FS)-vs-x86 |
|---|---|---|---|---|---|
| 1 | 6696 | 6439 | 7726 | 4 | 20 |
| 2 | 12482 | 11774 | 14402 | 6 | 22 |
| 4 | 23881 | 21308 | 27555 | 12 | 29 |
| 8 | 45993 | 42110 | 53069 | 9 | 26 |
| 16 | 88517 | 81239 | 102135 | 9 | 26 |
| 32 | 142974 | 136724 | 164970 | 5 | 21 |
| 64 | 198839 | 212484 | 229430 | -6 | 8 |
| 128 | 217778 | 241555 | 251282 | -10 | 4 |
| 256 | 209797 | 224009 | 242073 | -6 | 8 |
分析:
- ARM在较低扩展性上性能比X86要好，但是在扩展到与cpu数目相近的threads时，性能就开始下降了
- 在频率缩放下，尽管存在扩展性问题，ARM仍然击败X86
2. Read Only:
| threads | ARM (qps) | x86 (qps) | ARM (qps - fscaled (FS)) | % ARM-vs-x86 | % ARM (FS)-vs-x86 |
|---|---|---|---|---|---|
| 1 | 5222 | 5259 | 6025 | -1 | 15 |
| 2 | 10333 | 10200 | 11923 | 1 | 17 |
| 4 | 19176 | 19349 | 22126 | -1 | 14 |
| 8 | 36881 | 37035 | 42555 | 0 | 15 |
| 16 | 70337 | 67065 | 81158 | 5 | 21 |
| 32 | 109207 | 113210 | 126008 | -4 | 11 |
| 64 | 139294 | 164148 | 160724 | -15 | -2 |
| 128 | 151382 | 175872 | 174672 | -14 | -1 |
| 256 | 149136 | 164382 | 172080 | -9 | 5 |
分析:
- 在低扩展性上，ARM与X86基本持平，在较高扩展性败于X86
- 应用频率缩放，ARM在大多数场景下继续击败X86
3. Read Write:
| threads | ARM (tps) | x86 (tps) | ARM (tps - fscaled (FS)) | % ARM-vs-x86 | % ARM (FS)-vs-x86 |
|---|---|---|---|---|---|
| 1 | 137 | 149 | 158 | -8 | 6 |
| 2 | 251 | 273 | 290 | -8 | 6 |
| 4 | 462 | 502 | 533 | -8 | 6 |
| 8 | 852 | 920 | 983 | -7 | 7 |
| 16 | 1539 | 1678 | 1776 | -8 | 6 |
| 32 | 2556 | 2906 | 2949 | -12 | 1 |
| 64 | 3770 | 5158 | 4350 | -27 | -16 |
| 128 | 5015 | 8131 | 5787 | -38 | -29 |
| 256 | 5676 | 8562 | 6549 | -34 | -24 |
分析:
- 在read-write测试套件中情况有些不同。ARM开始落后了。在低扩展性情况下，频率缩放会减缓这种落后，在高扩展性则持续增大了差距。
4. Update Index:
| threads | ARM (tps) | x86 (tps) | ARM (tps - fscaled (FS)) | % ARM-vs-x86 | % ARM (FS)-vs-x86 |
|---|---|---|---|---|---|
| 1 | 328 | 373 | 378 | -12 | 1 |
| 2 | 623 | 768 | 719 | -19 | -6 |
| 4 | 1060 | 1148 | 1223 | -8 | 7 |
| 8 | 1905 | 2028 | 2198 | -6 | 8 |
| 16 | 3284 | 3590 | 3789 | -9 | 6 |
| 32 | 5543 | 6275 | 6396 | -12 | 2 |
| 64 | 9138 | 10381 | 10544 | -12 | 2 |
| 128 | 13879 | 16868 | 16014 | -18 | -5 |
| 256 | 19954 | 25459 | 23024 | -22 | -10 |
分析:
- 频率缩放下，ARM继续与X86处于同等/更好的状态 (除了高竞争用例)
5. Update Non-Index:
| threads | ARM (tps) | x86 (tps) | ARM (tps - fscaled (FS)) | % ARM-vs-x86 | % ARM (FS)-vs-x86 |
|---|---|---|---|---|---|
| 1 | 328 | 373 | 378 | -12 | 1 |
| 2 | 588 | 686 | 678 | -14 | -1 |
| 4 | 1075 | 1118 | 1240 | -4 | 11 |
| 8 | 1941 | 2043 | 2240 | -5 | 10 |
| 16 | 3367 | 3662 | 3885 | -8 | 6 |
| 32 | 5681 | 6438 | 6555 | -12 | 2 |
| 64 | 9328 | 10631 | 10763 | -12 | 1 |
| 128 | 14158 | 17245 | 16336 | -18 | -5 |
| 256 | 20377 | 26367 | 23512 | -23 | -11 |
分析:
- 频率缩放下，ARM继续与X86处于同等/更好的状态 (除了高竞争用例)
结论
基于以上的数据，我们能够得到如下结论:
- 在只读场景中测试Mysql, ARM和X86性能几乎一致。
- 在涉及写场景中测试Mysql，ARM开始有些落后，但是如果我们考虑频率缩放，情况可能会好一点。
- 在生活里，我们通常不会考虑频率缩放，而会考虑他们的性价比。这是一个话题，但通常是事实：ARM实例比X86实例便宜34%（我们在测试中用相同的flavor 24U48G）。
- 有一点我们需要持续观察，就是， ARM工作负载在达到CPU限制之前具有很好的可伸缩性。随着可伸缩性的增强，争用增加，ARM开始滞后。这是因为互斥/竞争热点都是针对x86调优的（例如：自旋锁 spin-lock）。现在MySQL正式支持ARM，并且ARM的社区和来自各地开发者的兴趣也不断增长，所以Mysql社区也会针对ARM进行调优，让我们拭目以待把。
总之，Mysql on ARM是一个值得从成本和性能角度来尝试的选择。
如果你还有问题/疑问，请告诉我。我会试着去回答。