---
title: 使用Sysbench对MySQL 5.7.21进行并发压测时，MySQL性能较差的解决方法
description: "使用Sysbench对MySQL 5.7.21进行256并发压测时，x86下TPS为10685，鲲鹏920处理器下压测结果为4197，性能较原有x86环境下有较大差距。"
url: https://www.hikunpeng.com/document/detail/zh/kunpengdbs/troubleshooting/trouble/boostkit_database_troublecase_019.html
sourcePath: /source/zh/kunpengdbs/troubleshooting/trouble/boostkit_database_troublecase_019.html
indexId: 6f2a2227f0a66c6c471d6aa17c12d558022880ff87c9157b8478f39217c6c9b984
---
# 使用Sysbench对MySQL 5.7.21进行并发压测时，MySQL性能较差的解决方法

#### 问题现象描述

使用Sysbench对MySQL 5.7.21进行256并发压测时，x86下TPS为10685，鲲鹏920处理器下压测结果为4197，性能较原有x86环境下有较大差距。


#### 关键过程、根本原因分析

1. 执行脚本进行压测时发现，top命令下MySQL进程CPU使用率6000%左右，其中系统调用占用较高，为进一步明确MySQL进程在执行哪些过程进行perf热点函数和火焰图分析。
2. 通过在压测过程中执行perf top命令，查看到相关函数调用较高。
3. 进一步明确分析函数调用栈关系，使用perf record命令抓取一段时间的perf数据，进行解析后生成相应火焰图。
  分析发现MySQL中调用的热点函数MVCC::view_open和PolicyMutex_在底层调用的是spin_lock相关函数，进而导致系统调用高，大量线程都在进行自旋空转，消耗CPU资源。


#### 结论、解决方案及效果

通过对MySQL的相关优化，在256并发下，鲲鹏920处理器上TPS达到了11700，优于原x86压测结果（TPS 10685）。

1. （可选优化项）修改MySQL源码中CacheLine。
  通过github上MySQL相关issue发现，在MySQL中存在对cacheline的硬编码现象，MySQL中cacheline大小是适配x86平台的，为64字节；鲲鹏920处理器下cacheLine为128字节。因此需要对MySQL源码进行修改，以获得相应的性能提升。关于修改MySQL源码的更多信息，请参见Github社区(https://github.com/mysql/mysql-server/pull/66/files)。

2. 修改MySQL数据库配置参数。

  a. MySQL中主要影响spin_lock相关性能参数的主要有：innodb_thread_concurrency、innodb_spin_wait_delay、innodb_sync_spin_loops。其中innodb_thread_concurrency推荐设置为CPU的核心数，通过上调innodb_spin_wait_delay和innodb_sync_spin_loops参数，同时使用perf top命令观测MVCC::view_open和PolicyMutex_热点函数使用率，当使用率下降到合理范围内时，即达到预期效果。
  b. 在高并发压测MySQL时，在x86和鲲鹏920处理器平台上的原子操作实现存在差异，而鲲鹏920处理器的核心数较多，这导致了spin_lock相关系统调用较高的情况。为了解决这个问题，可以通过相应的MySQL参数优化来提高性能。同时，可以结合MySQL相关自旋锁的代码实现来更好地理解这两个参数的作用。关于自旋锁的更多信息，请参见    MySQL自旋锁(https://blog.csdn.net/sun_ashe/article/details/81291347)
。