问题背景描述

使用sysbench对mysql5.7.21进行256并发压测时，x86下TPS为10685，Kunpeng920 下压测结果为4197，性能较原有X86环境下有较大差距。

问题分析过程

Top命令查看cpu资源使用情况

执行脚本进行压测时发现，top命令下mysql进程cpu使用率6000%左右，其中系统调用占用较高，为进一步明确mysql进程在执行哪些过程进行perf 热点函数和火焰图分析。

perf命令查看热点函数

通过在压测过程中执行perf top命令，查看到相关函数调用较高：

进一步明确分析函数调用栈关系，使用perf record命令抓取一段时间perf 数据，进行解析后生成相应火焰图：

分析发现mysql中调用的热点函数MVCC::view_open和PolycyMutex_在底层调用的是spin_lock相关函数，进而导致系统调用高，大量线程都在进行自旋空转，消耗cpu资源。

问题解决措施及结果

修改Mysql源码中CacheLine(可选优化项)

通过github上mysql相关issue发现，在mysql中存在对cacheLine的硬编码现象，mysql中cachline大小是适配X86平台的为64字节，Kunpeng 920下cacheLine为128字节。可参考以下issue链接https://github.com/mysql/mysql-server/pull/66/files对mysql源码进行修改，此措施可获得相应的性能提升。

Cacheline机制理解：

CPU标识Cache中的数据是否为有效数据不是以内存位宽为单位，而是以Cacheline为单位。这个机制可能会导致伪共享（false sharing）现象，从而使得CPU的Cache命中率变低。出现伪共享的常见原因是高频访问的数据未按照Cacheline大小对齐，而在高并发压测mysql时，其中加锁的全局变量或数据一般是在高频的访问，这就可能导致性能的下降。（对于高频访问的锁变量，实际是对锁变量进行高频的读写操作，容易发生伪共享问题）

修改mysql数据库配置参数

Mysql中主要影响spin_lock相关性能参数的主要有：innodb_thread_concurrency、innodb_spin_wait_delay、innodb_sync_spin_loops。其中nnodb_thread_concurrency推荐设置为cpu的核心数，通过上调innodb_spin_wait_delay和innodb_sync_spin_loops参数，同时使用perf top命令观测MVCC::view_open和PolycyMutex_热点函数使用率，当使用率下降到合理范围内时，即达到预期效果。

由于原子操作在x86和kunpeng 920平台上的实现存在差异，加上kunpeng920的核心数较多，导致在mysql高并发压测时出现了spin_lock相关系统调用较高，通过相应的mysql参数优化即可实现性能提升，结合Mysql下相关自旋锁的代码实现，可更好的理解这两个参数的作用，参考链接如下：

https://blog.csdn.net/sun_ashe/article/details/81291347

优化后测试结论

通过对mysql的相关优化，最终在256并发下，kunpeng 920上TPS达到了11700,优于原X86压测结果(TPS 10685)。