sysbench压测mysql性能调优案例分享

1 问题背景

使用sysbench对mysql5.7.21进行256并发压测时，调优前在Kunpeng920压测TPS为4197，与理想数据有较大差距。

2 原因分析

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

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

2.2 perf命令查看热点函数

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

进一步明确分析函数调用栈关系，使用perf record命令抓取一段时间perf 数据，进行解析后生成相应火焰图(火焰图生成过程可参考https://github.com/brendangregg/FlameGraph )：

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

3 解决方案

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

通过github上mysql-5.7.21相关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时，其中加锁的全局变量或数据一般是在高频的访问，这就可能导致性能的下降。（对于高频访问的锁变量，实际是对锁变量进行高频的读写操作，容易发生伪共享问题）

3.2 修改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，达到并超过了预期的TPS值。

4 总结

遇到性能问题时，首先需要对比查看各项系统参数是否异常。对于cpu占用较高时，需要善于应用perf工具进行热点函数分析，逐一进行排查。

MySQL 应用性能调优 SQL 数据库

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。