爱可生 DBA 团队成员，擅长故障分析、性能优化，个人博客：https://www.jianshu.com/u/a95ec11f67a8，欢迎讨论。
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
网络瓶颈
一次压测结果是这样的：
sysbench oltp_read_write --mysql-host=10.18x.xx.104 --mysql-port=3308 \
--mysql-user=sysbench --mysql-password=sysbench --mysql-db=sbtest --tables=10 \
--table-size=10000000 --report-interval=5 --threads=200 --time=600 run
##结果：
SQL statistics:
queries performed:
read: 4682958
write: 1337988
other: 668994
total: 6689940
transactions: 334497 (2783.82 per sec.)
queries: 6689940 (55676.32 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
ifconfig -a|grep -B 1 inet
。立马就看到确实是双网卡，我们压测用的是em3，还有另外一个网络接口 vlan2 ：
然后再确认下带宽：ethtool {dev_name} |grep Speed。em3 是千兆带宽，压测时 124MB/s 的流量已经打满了：
所以在sysbench压测时换成 vlan2 万兆网络接口后（即修改 --mysql-host=10.0.xx.104），轻松到1万。如果实在没有万兆网卡怎么办？那就在本地使用回环接口进行测试吧。下图是使用3个网口测试的网络流量图，明显可以看出千兆网口的网络瓶颈：
SSL
MySQL8.0 或者 MySQL5.7 企业版压测时会遇到一个坑：默认开启 SSL，压测结果 tps 只有3700：
sysbench oltp_read_write --mysql-host=10.18x.xx.104 --mysql-port=3308 \
--mysql-user=sysbench --mysql-password=sysbench --mysql-db=sbtest --tables=10 \
--table-size=10000000 --report-interval=5 --threads=200 --time=600 run
##结果：
SQL statistics:
queries performed:
read: 6303388
write: 1800968
other: 900484
total: 9004840
transactions: 450242 (3747.71 per sec.)
queries: 9004840 (74954.25 per sec.)
Latency (ms):
min: 6.35
avg: 53.31
max: 542.71
95th percentile: 104.84
sum: 24004566.42
和前面说的一样，观察系统负载，发现 CPU 使用率已经用到了 80% ，但是 CPU system 时间反常的高，再去看压测结果 95% 的响应时间也很高需要 100 多毫秒，正是因为需要消耗大量的系统资源进行加密连接：
解决办法就是配置文件写入 skip-ssl 重启 MySQL。其实 sysbench 有个参数 --mysql-ssl[=on|off]，看说明只要设置为 off 就可以关闭 ssl 连接，但实测并没有用，通过 select * from status_by_thread where VARIABLE_NAME like '%ssl%'；查看连接还是开启 ssl 的，对 ssl 机制比较懵逼，欢迎有了解的大佬留言。
sort_buffer_size
sort_buffer_size 会影响 sysbench 性能吗？官方文档有这样的描述：
On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation, so you should consider staying below one of those values.
也许你会觉得问题不大，但实际看下面这组测试结果：11000 tps VS 930 tps
## sort_buffer_size=31M
SQL statistics:
queries performed:
read: 16358846
write: 4673956
other: 2336978
total: 23369780
transactions: 1168489 (11678.75 per sec.)
queries: 23369780 (233574.94 per sec.)
## sort_buffer_size=32M
SQL statistics:
queries performed:
read: 392182
write: 112052
other: 56026
total: 560260
transactions: 28013 (930.07 per sec.)
queries: 560260 (18601.38 per sec.)
事实就是这么不可思议，当 sort_buffer_size 达到阈值32M后（我测试的阈值和文档给出的阈值256K、2M不一样），内存分配方式发生改变，内存分配效率变低， CPU system 时间剧增：
细说一下内存分配方式变化为什么会引起这个结果，参考：【技术分享 | MySQL 内存管理初探】
malloc() 是 C 标准库提供的内存分配函数，对应到系统调用上，有两种实现方式，即 brk() 和 mmap()。
brk 方式 对于小块内存（<128K），C 标准库使用 brk() 来分配。也就是通过移动堆顶的位置来分配内存。这些内存释放后并不会立刻归还系统，而是被缓存起来，重复使用。
优缺点：brk() 方式可以减少缺页异常的发生，提高内存访问效率。不过，由于这些内存没有归还系统，所以在内存工作繁忙时，频繁的内存分配和释放会造成内存碎片。
mmap 匿名映射方式 对于大块内存（>128K），C 标准库使用 mmap() 来分配，也就是在文件映射段找一块空闲内存分配出去。mmap() 方式分配的内存，会在释放时直接归还系统，所以每次 mmap 都会发生缺页异常。
优缺点：mmap() 方式可以将内存及时返回给系统，避免 OOM。但是工作繁忙时，频繁的内存分配会导致大量的缺页异常，使内核的管理负担增大。这也是 malloc 只对大块内存使用 mmap 的原因。
所 谓的缺页异常是指进程申请内存后，只分配了虚拟内存。 这些所申请的虚拟内存，只有在首次访问时才会分配真正的物理内存，也就是通过缺页异常进入内核中，再由内核来分配物理内存（本质就是建立虚拟内存与物理内存的地址映射）。
总结
当压 测结果不乐观，第一时间去看 CPU 使用率，只要总使用率低，或者 iowait、system 高，都是异常情况，需要去排查原因。my.cnf 规范模板可以解决大部分的压测结果异常的问题，另一方面则需要我们掌握基本的分析方法，再配合一些过往经验，就能测出理想的数据了。
文章推荐：
技术分享 | show engine innodb status 中 Pages flushed up to 的含义
社区近期动态
点一下“阅读原文”了解更多资讯
本文分享自微信公众号 - 爱可生开源社区（ActiontechOSS）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。