共计 4666 个字符，预计需要花费 12 分钟才能阅读完成。
NVIDIA InfiniBand 是一种被宽泛应用的网络互联技术，基于 IBTA(InfiniBand Trade Association)而定义的高带宽、低延时、低 CPU 占用率、大规模易扩大的通信技术，是世界领先的超级计算机的互连首选，为高性能计算、人工智能、云计算、存储等泛滥数据密集型利用提供了弱小的网络性能撑持。通过高速的 InfiniBand 技术，将业务负载由单机运行转化为基于多机合作的高性能计算集群，并使高性能集群的性能得以进一步开释与优化。
GreatSQL 是由万里数据库保护的国内自主 MySQL 分支版本，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，实用于金融级利用。
此次通过比照测试基于 InfiniBand 的 NVMe SSD 池化计划 及本地 NVMe SSD 的传统计划的性能体现，评估应用基于 InfiniBand 的存算拆散架构对分布式数据库性能的晋升水平及扩展性。
通过单方单干，通过大量数据分析，能够看出基于 InfiniBand 池化计划的存算拆散架构的性能更优、稳定性更强，为 GreatSQL 实现更高性能的分布式部署提供了无力的技术平台撑持。
1、NVIDIA InfiniBand 池化计划介绍
分布式数据库集群由两局部组成：
- 计算节点是无 SSD 盘的裸金属服务器，运行 MySQL 数据库服务程序；
- 存储节点提供 NVMe SSD 资源池，通过软件聚合形式提供高性能 Lun 实现对于数据库的数据的存储服务；
两局部服务器通过 Quantum 平台的 InfiniBand 网络实现对计算节点和存储节点的无损连贯，联合 NVMe-oF（NVMe over Fabric）高效的数据存储传输协定，将存储节点的 Lun 挂载到计算节点，实现结算节点本地高性能的数据存储能力。
- 测试环境
为了能够偏心比照两种计划的优劣，两次测试均采纳同一台计算服务器进行测试，不同的是，本地计划存储由本地的 PCIe4.0 NVMe SSD 承载，InfiniBand 池化计划由 100Gbps 速率的 HDR100 网卡接入，通过雷同型号的 NVMe SSD 组成的全闪服务器借助 NVMe-oF 提供高性能虚构 Lun 实现数据拜访。
2.1 存储设备
本次测试次要采取两种存储计划：
- InfiniBand + NVMe SSD 设施
-
本机挂 NVMe SSD 设施
$ nvme list Node SN Model Namespace Usage Format FW Rev --------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- -------- # InfiniBand + NVMe SSD 设施 /dev/nvme0n1 MNC12 Mellanox BlueField NVMe SNAP Controller 1 1.10 TB / 1.10 TB 512 B + 0 B 1.0 # 本机挂载的两个 NVMe SSD 设施 /dev/nvme2n1 S5L9NE0NA00144 SAMSUNG MZWLJ7T6HALA-0007C 1 7.68 TB / 7.68 TB 512 B + 0 B EPK99J5Q /dev/nvme3n1 S5L9NE0NA00091 SAMSUNG MZWLJ7T6HALA-0007C2.2 CPU& 内存
- 内存：512GB
- CPU，最多 128 核
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 128
On-line CPU(s) list: 0-127
Thread(s) per core: 2
Core(s) per socket: 32
Socket(s): 2
NUMA node(s): 1
Vendor ID: AuthenticAMD
BIOS Vendor ID: Advanced Micro Devices, Inc.
CPU family: 23
Model: 49
Model name: AMD EPYC 7542 32-Core Processor
BIOS Model name: AMD EPYC 7542 32-Core Processor
Stepping: 0
CPU MHz: 3381.667
CPU max MHz: 2900.0000
CPU min MHz: 1500.0000
BogoMIPS: 5799.52
Virtualization: AMD-V
L1d cache: 32K
L1i cache: 32K
L2 cache: 512K
L3 cache: 16384K
NUMA node0 CPU(s): 0-127
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca2.3 操作系统
OS：CentOS 8
内核：Linux g4 5.4.90-1.el8.x86_64 #1 SMP Fri Mar 11 10:11:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linu文件系统
$ mount | grep xfs
LABEL=/nvme0 /nvme0 xfs defaults,noatime,nodiratime,inode64 0 0
LABEL=/nvme2 /nvme2 xfs defaults,noatime,nodiratime,inode64 0 0
LABEL=/nvme3 /nvme3 xfs defaults,noatime,nodiratime,inode64 0 0
$ df -hT
/dev/nvme0n1 xfs 1.0T 247G 778G 25% /nvme0
/dev/nvme2n1 xfs 7.0T 1.1T 6.0T 15% /nvme2
/dev/nvme3n1 xfs 7.0T 245G 6.8T 4% /nvme32.4 压测参数 & 指标
-
压测工具：sysbench
- 模式：oltp_read_write。
- 每轮压测时长：900 秒。
- 每轮压测休眠距离：180 秒。
- 共 64 个表。
- 每个表 12500000 条记录。
- 整个测试库大小约 186G。
- 采纳 InnoDB 引擎。
- 并发线程数变动：8、16、32、64、128。
- ibp（innodb buffer pool）变动：47G、93G、140G、186G（约为物理数据的 25%、50%、75%、100%）。
-
主要参数选项
sync_binlog = 1 innodb_flush_log_at_trx_commit = 1 innodb_log_buffer_size = 32M innodb_log_file_size = 2G innodb_log_files_in_group = 3 innodb_doublewrite_files = 2 innodb_io_capacity = 400000 innodb_io_capacity_max = 800000 innodb_flush_method = O_DIRECT innodb_thread_concurrency = 0sysbench 测试命令模板：
$ sysbench oltp_read_write.lua \ --tables=64 \ --table_size=12500000\ --report-interval=1 \ --threads=128 \ --rand-type=uniform \ --db-ps-mode=disable \ --mysql-ignore-errors=all \ --time=900 run
3. 性能体现 & 总结
3.1 测试总结
论断后行，整体测试状况如下：
-
当 ibp 不足以笼罩全副物理数据时：
1）GreatSQL 8.x 性能远高于 GreatSQL 5.7。
2）并发线程数越高，IB+NVMe SSD vs 本地 NVMe SSD 的差距越小。
3）ibp 越大，GreatSQL 5.7 和 8.0 性能越靠近。
-
当 ibp 根本能够笼罩全副物理数据时：
1）GreatSQL 5.7 的性能整体比 GreatSQL 8.0 略好。
- 总的测试下来看，IB NVMe SSD 相比 本地 NVMe SSD 的性能更好，也更稳固一些。
- 尝试比照测试了组提交（binlog group commit），在本案中对性能影响很小，这里不再赘述。
- 尝试比照设置 innodb_thread_concurrency = 64|128，发现加上后，在 ibp 足够大，且并发也打满 128 线程后，性能更稳固些，稳定没那么大了，且最终整体性能也能晋升约 8% ~ 10%（不过也要思考到，实在生产环境中，很少会跑满这么大压力）。
- 总的来说，当物理内存不足以笼罩业务数据时（生成环境中这种状况很常见），如果单靠减少物理内存以晋升数据库性能可能从性价比角度看并不划算，不如换个思路，晋升本地物理 I / O 设施的性能，毕竟当初 NVMe SSD 的性能能够跑到很高。
3.2 测试数据比照图表
1）ibp=47G
2）ibp=93G
3）ibp=140G
4）ibp=186G
4. 结语
从以上测试数据中，能够显著看到采纳了 InfiniBand 池化计划数据库性能在不同场景中性能都有不同水平的显著晋升，尤其在高并发场景下，体现突出。
将来，万里数据库将联结 NVIDIA 在万里数据库 GreatDB 集中式及分布式数据库产品中，摸索更多基于 InfiniBand 在数据库中的结合点和翻新点，基于 NVIDIA InfiniBand 打造数据库 + 网络软硬一体化联结解决方案，为用户发明更多价值。
## 对于 GreatSQL
GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。
GreatSQL 社区 Gitee GitHub Bilibili
https://greatsql.cn/
技术交换群：
微信：扫码增加
GreatSQL 社区助手微信好友，发送验证信息加群。
