tpcc并发到一定程度后主要是锁导致性能上不去，所以超多核意义不大。
如果在Hygon 7280 2.1GHz 麒麟上起两个MySQLD实例，每个实例各绑定32物理core，性能刚好翻倍：
测试过程CPU均跑满（未跑满的话会标注出来），IPC跑不起来性能就必然低，超线程虽然总性能好了但是会导致IPC降低(参考前面的公式)。可以看到对本来IPC比较低的场景，启用超线程后一般对性能会提升更大一些。
CPU核数增加到32核后，MySQL社区版性能追平xdb， 此时sysbench使用120线程压性能较好（AMD得240线程压）
32核的时候对比下MySQL 社区版在Hygon7280和Intel 8163下的表现：
三款CPU的性能指标
| 测试项 | AMD EPYC 7H12 2.5G | Hygon 7280 2.1GHz | Intel 8163 CPU @ 2.50GHz |
|---|
| 内存带宽(MiB/s) | 12190.50 | 6206.06 | 7474.45 |
| 内存延时(遍历很大一个数组) | 0.334ms | 0.336ms | 0.429ms |
在 lmbench 上的测试数据
stream 主要用于测试带宽，对应的时延是在带宽跑满情况下的带宽。
lat_mem_rd 用来测试操作不同数据大小的时延。总的来说带宽看stream、时延看lat_mem_rd
飞腾2500
用stream测试带宽和latency，可以看到带宽随着numa距离不断减少、对应的latency不断增加，到最近的numa node有10%的损耗，这个损耗和numactl给出的距离完全一致。跨socket访问内存latency是node内的3倍，带宽是三分之一，但是socket1性能和socket0性能完全一致
1 time for i in $(seq 7 8 128); do echo $i; numactl -C $i -m 0 ./bin/stream -W 5 -N 5 -M 64M; done
2 numactl -C 7 -m 0 ./bin/stream -W 5 -N 5 -M 64M
3 STREAM copy latency: 2.84 nanoseconds
4 STREAM copy bandwidth: 5638.21 MB/sec
5 STREAM scale latency: 2.72 nanoseconds
