sysbench 测 7T83 比 7H12 略好，可能是 ECS、OS 等带来的差异。
测试环境：4.19.91-011.ali4000.alios7.x86_64，5.7.34-log MySQL Community Server (GPL)。
| 测试核数 | AMD EPYC 7H12 2.5G（QPS、IPC） | 说明 |
|---|
| 单核 | 24363 0.58 | CPU跑满 |
| 一对HT | 33519 0.40 | CPU跑满 |
| 2物理核(0-1) | 48423 0.57 | CPU跑满 |
| 2物理核(0,32) 跨node | 46232 0.55 | CPU跑满 |
| 2物理核(0,64) 跨socket | 45072 0.52 | CPU跑满 |
| 4物理核(0-3) | 97759 0.58 | CPU跑满 |
| 16物理核(0-15) | 367992 0.55 | CPU跑满，sys占比20%，si 10% |
| 32物理核(0-31) | 686998 0.51 | CPU跑满，sys占比20%, si 12% |
| 64物理核(0-63) | 1161079 0.50 | CPU跑到95%以上，sys占比20%, si 12% |
| 64物理核(0-31,64-95) | 964441 0.49 | socket2上的32核一直比较闲，数据无参考意义 |
| 64物理核(0-31,64-95) | 1147846 0.48 | 重启mysqld，立即绑核，sysbench 在32-63上，导致0-31的CPU只能跑到89% |
说明，压测过程动态通过 taskset 绑核，所以会有数据残留其它核的 cache 问题。
跨 socket taskset 绑核的时候要压很久任务才会跨 socket 迁移过去，也就是刚 taskset 后CPU 是跑不满的。
1 numastat -p 437803 2 Per-node process memory usage (in MBs) for PID 437803 (mysqld) 3 Node 0 Node 1 Node 2 4 --------------- --------------- --------------- 5 Huge 0.00 0.00 0.00 6 Heap 1.15 0.00 5403.27 7 Stack 0.00 0.00 0.09 8 Private 1921.60 16.22 10647.66 9 ---------------- --------------- --------------- --------------- 10 Total 1922.75 16.22 16051.02 11 Node 3 Total 12 --------------- --------------- 13 Huge 0.00 0.00 14 Heap 0.03 5404.45 15 Stack 0.00 0.09 16 Private 16.20 12601.68 17 ---------------- --------------- --------------- 18 Total 16.23 18006.22
