作者：胡呈清
爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。
本文起源：原创投稿
*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
老板让你做一个 MySQL 的性能基准测试，测来测去发现明明机器配置很高，但 tps 就是上不去，为什么？
首先咱们很容易想到的就是 InnoDB 缓冲池设置的不够大、 redo log 太小、数据没有充沛预热、 sysbench 线程数开的太少... 这些是很常见的起因，明天咱们来看一些不那么不言而喻的状况。
以下案例的硬件配置为：64core、256Gmemory、raid 10 15K 机械盘。
网络瓶颈
一次压测后果是这样的：
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.)后果 tps 只有 2800，显然对不起这么高的硬件，这时候就得察看负载了，个别最显著的一点就是 CPU 使用率低，比方这个案例在我的环境上 CPU 使用率只有36%，而网卡流量很高达到 124MB/s ，差不多就是千兆网卡的极限了(1000Mb/s / 8)：
这时候就得意识到“我是不是用错网卡了”？为啥这么说呢，因为个别都会配两块网卡别离拜访内外网，疾速查看网络接口：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.
兴许你会感觉问题不大，但理论看上面这组测试后果：11000tps VS 930tps
## sort_buffer_size=31MSQL 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=32MSQL 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 的起因。
所谓的缺页异样是指过程申请内存后，只调配了虚拟内存。这些所申请的虚拟内存，只有在首次拜访时才会调配真正的物理内存，也就是通过缺页异样进入内核中，再由内核来调配物理内存（实质就是建设虚拟内存与物理内存的地址映射）。
brk() 形式申请的堆内存因为开释内存后并不会归还给零碎，所以下次申请内存时，并不需要产生缺页异样。
mmap() 形式申请的动态内存会在开释内存后间接偿还零碎，所以下次申请内存时，会产生缺页异样（减少内核态 CPU 开销）。
总结
当压
测后果不乐观，第一工夫去看 CPU 使用率，只有总使用率低，或者 iowait、system 高，都是异常情况，须要去排查起因。my.cnf 标准模板能够解决大部分的压测后果异样的问题，另一方面则须要咱们把握根本的分析方法，再配合一些过往教训，就能测出现实的数据了。