背景
环境两台云上相同 128C的EC2(有点豪)，一台当压力机一台当服务器，用Sysbench测试MySQL纯读场景，不存在任何修改，也就几乎没有锁
|
1
2
3
4
5
|
#uname -r
5.10.84.aarch64
Server: MySQL
Server version: 8.0.18 Source distribution
|
EC2机器128核，故意只给MySQLD绑定了其中的24Core，网卡32队列
|
1
2
3
4
5
6
7
8
9
10
11
12
|
#ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX: 0
TX: 0
Other: 0
Combined: 32
Current hardware settings:
RX: 0
TX: 0
Other: 0
Combined: 32
|
压测过程
走同一交换机内网IP压MySQL跑不满CPU，跑压力和不跑压力时ping rtt 分别是 0.859/0.053(RTT 有增加–注意点), 此时TPS：119956.67 1000并发 RT 8.33
下图是压测时 htop 看到的MySQLD 所在EC2的 CPU使用情况，右边65-88是MySQLD进程(绿色表示us, 红色表示sys+si CPU)
用top查看详细的每个 core 使用(只展示MySQLD使用的24core ，top 然后按1–还可以试试2/3，有惊喜)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
top - 13:49:55 up 160 days, 18:10, 3 users, load average: 555.26, 720.12, 462.21
Tasks: 1065 total, 1 running, 499 sleeping, 0 stopped, 0 zombie
%Node1 : 10.1 us, 5.3 sy, 0.0 ni, 83.3 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
%Cpu64 : 29.3 us, 16.5 sy, 0.0 ni, 54.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu65 : 37.0 us, 18.5 sy, 0.0 ni, 26.9 id, 0.0 wa, 0.0 hi, 17.5 si, 0.0 st
%Cpu66 : 34.2 us, 17.8 sy, 0.0 ni, 47.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu67 : 26.0 us, 15.1 sy, 0.0 ni, 58.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu68 : 26.1 us, 14.8 sy, 0.0 ni, 59.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu69 : 27.2 us, 13.8 sy, 0.0 ni, 59.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu70 : 25.7 us, 11.8 sy, 0.0 ni, 62.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu71 : 18.3 us, 10.6 sy, 0.0 ni, 71.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu72 : 29.7 us, 12.6 sy, 0.0 ni, 57.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu73 : 21.2 us, 13.0 sy, 0.0 ni, 65.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu74 : 18.9 us, 10.8 sy, 0.0 ni, 70.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu75 : 28.9 us, 15.1 sy, 0.0 ni, 36.1 id, 0.0 wa, 0.0 hi, 19.9 si, 0.0 st
%Cpu76 : 30.3 us, 15.5 sy, 0.0 ni, 54.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu77 : 25.1 us, 13.2 sy, 0.0 ni, 61.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu78 : 18.2 us, 10.3 sy, 0.0 ni, 71.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu79 : 14.9 us, 8.8 sy, 0.0 ni, 76.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu80 : 23.4 us, 12.2 sy, 0.0 ni, 64.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu81 : 35.3 us, 17.6 sy, 0.0 ni, 30.2 id, 0.0 wa, 0.0 hi, 16.9 si, 0.0 st
%Cpu82 : 28.2 us, 16.1 sy, 0.0 ni, 55.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu83 : 37.5 us, 16.9 sy, 0.0 ni, 27.0 id, 0.0 wa, 0.0 hi, 18.6 si, 0.0 st
%Cpu84 : 35.4 us, 18.5 sy, 0.0 ni, 46.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu85 : 27.9 us, 16.8 sy, 0.0 ni, 55.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu86 : 28.2 us, 13.7 sy, 0.0 ni, 58.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu87 : 27.2 us, 11.0 sy, 0.0 ni, 61.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu88 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
|
继续尝试用2000并发，TPS、CPU、ping rtt都和1000并发没有区别，当然按照我们以前QPS、RT理论2000并发的时候RT应该翻倍，实际确实是16.66，所以这里的问题就是翻倍的 RT哪里来的瓶颈就在哪里。
也试过用两个压力机每个压力机分别用1000并发同时压，QPS一样稳定——目的快速排除压力端、链路上有瓶颈。
写到这里RT 刚好翻倍16.66=8.33*2 数字精准得好像编故事一样，不得不贴一下原始数据证实一下：
1000 并发和2000并发时的ping RTT对比(ttl 64说明内网直达)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
#ping mysqld27
PING yt27 (mysqld217) 56(84) bytes of data.
---以下是2000并发
64 bytes from mysqld27 (mysqld217): icmp_seq=1 ttl=64 time=0.867 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=2 ttl=64 time=0.952 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=3 ttl=64 time=0.849 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=4 ttl=64 time=0.857 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=5 ttl=64 time=0.987 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=6 ttl=64 time=0.860 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=7 ttl=64 time=0.909 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=8 ttl=64 time=0.875 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=9 ttl=64 time=0.979 ms
---终止压测，无无压力的rtt
64 bytes from mysqld27 (mysqld217): icmp_seq=10 ttl=64 time=0.104 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=11 ttl=64 time=0.079 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=12 ttl=64 time=0.075 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=13 ttl=64 time=0.075 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=14 ttl=64 time=0.074 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=15 ttl=64 time=0.078 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=16 ttl=64 time=0.075 ms
---开启1000并发时的rtt
64 bytes from mysqld27 (mysqld217): icmp_seq=17 ttl=64 time=0.872 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=18 ttl=64 time=0.969 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=19 ttl=64 time=0.862 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=20 ttl=64 time=0.877 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=21 ttl=64 time=0.961 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=22 ttl=64 time=0.828 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=23 ttl=64 time=0.098 ms
64 bytes from mysqld27 (mysqld217): icmp_seq=24 ttl=64 time=0.083 ms
|
抓包证明
在抓保证明前推荐一个工具快速绕过抓包(原理也是通过pcap lib去分析网络包，tcpdump也会调用pcap lib)
监控tcprstat，从网络层抓包来对比两个并发下的RT：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
#tcprstat -p 14822 -t 1 -n 0 -l mysqld217 -f "%T\t\t%n\t\t%a\n"
timestamp count avg
1683785023 50743 626
1683785024 120004 100
1683785025 120051 103
1683785026 120042 102
1683785027 120031 103
1683785028 120034 104
1683785029 120034 104
1683785030 55209 103 ---以上是2000并发
1683785038 0 0
1683785039 0 0
1683785040 55224 614 ---以下是1000并发
1683785041 119998 104
1683785042 120039 105
1683785043 120039 105
1683785044 120026 107
1683785045 120039 108
1683785046 120047 108
1683785047 120037 108
1683785048 120032 108
1683785049 120041 108
|
也就是网卡层面确认了压不上去瓶颈不在MySQL 上，加并发后网卡的RT没变(网卡RT包含MySQLD RT)，因为ping RTT 在1000和2000并发也没有差异，推测交换机不是瓶颈，大概率出网卡的虚拟层面
在客户端的机器上抓包，上面我们说过了1000并发的RT是8.33毫秒：
注意上图，我把RT排序了，明显看到5ms到17ms 中间没有这个RT范围的包，但是有很多25ms的RT，平均下来确实是8.33毫秒，留下一个疑问：RT分布不符合正态，而且中间有很大一段范围镂空了！这是不应该的。
同样我们再到MySQLD 所在机器抓包分析(注：正常路径先抓MySQLD上的包就行了)：
同样是对RT 排序了，但是慢的RT都是对端发慢了(注意最右边的select， MySQL相应是 response)，同样对这个抓包求平均时间就是tcprstat 看到的103微秒，也就是0.1毫秒。
同样在2000并发时也对MySQLD所在网卡抓包对比，response 的RT 没有变化，从这里可以看出瓶颈点在sysbench 和 MySQLD 的网卡之间的链路上，似乎有限流、管控
快速验证
到这里我们已经找到了有力的证据，RT是在离开MySQLD网卡后增加上去的，先验证下走走本机127.0.0.1快速压一把，让sysbench 跑在0-7 core上，这时可以看到MySQL跑满了CPU，下图左边1-8核是压力进程，右边65-88是业务进程，TPS：239969.91 1000并发 RT 4.16
htop状态：
各CPU 详细分析：
- us MySQL解析SQL、处理查询
- si 网络软中断
- sy OS 的sys API 消耗，一般用户进程会调用系统 API, 比如读写文件、分配内存、网络访问等
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
//sysbench
top - 13:44:27 up 160 days, 18:04, 3 users, load average: 792.17, 619.09, 311.58
Tasks: 1073 total, 1 running, 500 sleeping, 0 stopped, 0 zombie
%Cpu0 : 14.0 us, 29.1 sy, 0.0 ni, 33.3 id, 0.0 wa, 0.0 hi, 23.5 si, 0.0 st
%Cpu1 : 12.5 us, 33.0 sy, 0.0 ni, 33.7 id, 0.0 wa, 0.0 hi, 20.8 si, 0.0 st
%Cpu2 : 11.2 us, 32.7 sy, 0.0 ni, 34.2 id, 0.0 wa, 0.0 hi, 21.9 si, 0.0 st
%Cpu3 : 13.4 us, 31.2 sy, 0.0 ni, 34.4 id, 0.0 wa, 0.0 hi, 21.0 si, 0.0 st
%Cpu4 : 12.1 us, 31.3 sy, 0.0 ni, 34.2 id, 0.0 wa, 0.0 hi, 22.4 si, 0.0 st
%Cpu5 : 10.5 us, 31.8 sy, 0.0 ni, 33.6 id, 0.0 wa, 0.0 hi, 24.1 si, 0.0 st
%Cpu6 : 12.9 us, 31.3 sy, 0.0 ni, 34.2 id, 0.0 wa, 0.0 hi, 21.6 si, 0.0 st
%Cpu7 : 12.3 us, 31.4 sy, 0.0 ni, 34.3 id, 0.0 wa, 0.0 hi, 22.0 si, 0.0 st
%Cpu8 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
//MySQLD
Tasks: 1073 total, 1 running, 505 sleeping, 0 stopped, 1 zombie
%Node1 : 22.6 us, 10.1 sy, 0.0 ni, 62.4 id, 0.0 wa, 0.0 hi, 4.8 si, 0.0 st
%Cpu64 : 57.9 us, 29.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 12.9 si, 0.0 st
%Cpu65 : 60.3 us, 26.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 13.6 si, 0.0 st
%Cpu66 : 57.6 us, 28.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 14.2 si, 0.0 st
%Cpu67 : 60.9 us, 25.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 13.6 si, 0.0 st
%Cpu68 : 59.9 us, 26.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 13.9 si, 0.0 st
%Cpu69 : 57.9 us, 27.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 14.6 si, 0.0 st
%Cpu70 : 61.3 us, 26.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 12.6 si, 0.0 st
%Cpu71 : 64.0 us, 23.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 12.5 si, 0.0 st
%Cpu72 : 61.3 us, 26.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 11.9 si, 0.0 st
%Cpu73 : 63.0 us, 22.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 14.2 si, 0.0 st
%Cpu74 : 61.4 us, 27.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 11.2 si, 0.0 st
%Cpu75 : 63.9 us, 26.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 9.6 si, 0.0 st
%Cpu76 : 61.3 us, 27.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 11.6 si, 0.0 st
%Cpu77 : 55.0 us, 30.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 14.6 si, 0.0 st
%Cpu78 : 60.9 us, 26.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 12.3 si, 0.0 st
%Cpu79 : 58.4 us, 26.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 14.9 si, 0.0 st
%Cpu80 : 58.7 us, 29.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 12.2 si, 0.0 st
%Cpu81 : 62.6 us, 27.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 10.3 si, 0.0 st
%Cpu82 : 61.9 us, 25.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 12.6 si, 0.0 st
%Cpu83 : 58.7 us, 27.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 13.9 si, 0.0 st
%Cpu84 : 59.4 us, 27.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 12.9 si, 0.0 st
%Cpu85 : 58.9 us, 28.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 12.6 si, 0.0 st
%Cpu86 : 58.4 us, 28.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 13.2 si, 0.0 st
%Cpu87 : 61.1 us, 27.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 11.6 si, 0.0 st
|
就以上sysbench VS MySQLD 的CPU 消耗来看，因为sysbench 处理逻辑简单，就是发SQL给MySQLD，所以 sysbench自身US很少，大部分都是调用OS的网络操作，而MySQLD有 60% CPU用于US，也就是自身业务逻辑，MySQLD收到SQL要做SQL解析，要去查找数据，这些都是用户态消耗，找到数据后走网络发给Sysbench，这部分是sy
到这里可以拿着证据去VIP通道(土豪+专业的客户得有VIP通道)找做网络管控的了，不会再有撕逼和甩锅
sysbench 结果不是正态分布
把所有请求RT 分布进行图形化，此时平均 RT 8.33，理论上是一个正态分布，下图是有限速时：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
3.615 | 2177
3.681 |** 14738
3.748 |******* 55690
3.816 |************* 109713
3.885 |*************** 121830
3.956 |*************** 124851
4.028 |******************* 154927
4.101 |*********************** 188826
4.176 |*************************** 226206
4.252 |************************************ 302617
4.329 |**************************************** 333310 //这里以4.329为中心符合正态
4.407 |******************************* 257048
4.487 |******************** 163100
4.569 |************ 101785
4.652 |******** 63871
4.737 |***** 43998
4.823 |***** 40854
4.910 |***** 42189
4.999 |***** 41182
5.090 |**** 35652
5.183 |**** 30343
5.277 |*** 28573
5.373 |*** 24763
5.470 |*** 22210
5.570 |*** 21808
5.671 |*** 25606
5.774 |*** 26994
5.879 |*** 24672
5.986 |*** 22087
6.095 |** 18466
6.205 |** 14822
6.318 |** 13688
6.433 |** 15381
6.550 |** 13573
6.669 |* 11325
6.790 |* 9442
6.913 |* 7412
省略一大堆
20.736 |* 11407
21.112 |* 9755
21.496 |* 8957
21.886 |* 9434
22.284 |* 9715
22.689 |** 12774
23.101 |** 17000
23.521 |*** 22937
23.948 |***** 40401
24.384 |******** 65370
24.827 |********** 82186
25.278 |********** 85505
25.737 |*********** 94347 //以25.7附近大概又是一个新正态
26.205 |********** 82958
26.681 |**** 30760
27.165 | 2222
27.659 | 69
28.162 | 16
28.673 | 15
29.194 | 20
29.725 | 17
|
去掉限速后平均 RT 3.26(比下图中大概的中位数2.71大了不少) 完美正态
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
1.857 |** 19894
1.891 |*** 23569
1.925 |*** 27912
1.960 |**** 33720
1.996 |**** 39892
2.032 |***** 48289
2.069 |****** 57649
2.106 |******** 69437
2.145 |********* 83611
2.184 |*********** 99507
2.223 |************* 119275
2.264 |**************** 141013
2.305 |******************* 165450
2.347 |********************** 191778
2.389 |************************* 219706
2.433 |**************************** 250885
2.477 |******************************* 278379
2.522 |********************************** 303931
2.568 |************************************* 325777
2.615 |*************************************** 342948
2.662 |**************************************** 354029
2.710 |**************************************** 356295
2.760 |**************************************** 353068
2.810 |************************************** 341345
2.861 |************************************ 324600
2.913 |********************************** 303525
2.966 |******************************* 280221
3.020 |***************************** 255042
3.075 |************************** 230861
3.130 |*********************** 206909
3.187 |********************* 184616
3.245 |******************* 164903
3.304 |**************** 146199
3.364 |*************** 131427
3.425 |************* 117059
3.488 |************ 104954
3.551 |*********** 94404
3.615 |********* 83739
3.681 |******** 75705
3.748 |******** 67944
3.816 |******* 60727
3.885 |****** 53757
3.956 |***** 47053
4.028 |***** 42130
4.101 |**** 38069
4.176 |**** 33666
4.252 |*** 30048
4.329 |*** 26923
4.407 |*** 23886
4.487 |** 21615
4.569 |** 19897
4.652 |** 18458
4.737 |** 17729
4.823 |** 17041
4.910 |** 16011
4.999 |** 16099
5.090 |** 16090
5.183 |** 16393
5.277 |** 16729
5.373 |** 17412
|
用其他网络业务验证
先测试一下网络下载时的ping：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
--无流量
64 bytes from 172.16.0.205: icmp_seq=11 ttl=64 time=0.075 ms
64 bytes from 172.16.0.205: icmp_seq=12 ttl=64 time=0.080 ms
--从有网络限速的机器下载，带宽100MB
64 bytes from 172.16.0.205: icmp_seq=13 ttl=64 time=0.738 ms
64 bytes from 172.16.0.205: icmp_seq=14 ttl=64 time=0.873 ms
64 bytes from 172.16.0.205: icmp_seq=15 ttl=64 time=0.993 ms
64 bytes from 172.16.0.205: icmp_seq=16 ttl=64 time=0.859 ms
64 bytes from 172.16.0.205: icmp_seq=17 ttl=64 time=0.892 ms
64 bytes from 172.16.0.205: icmp_seq=18 ttl=64 time=0.972 ms
64 bytes from 172.16.0.205: icmp_seq=19 ttl=64 time=1.05 ms
64 bytes from 172.16.0.205: icmp_seq=20 ttl=64 time=0.973 ms
64 bytes from 172.16.0.205: icmp_seq=21 ttl=64 time=0.997 ms
64 bytes from 172.16.0.205: icmp_seq=22 ttl=64 time=0.915 ms
64 bytes from 172.16.0.205: icmp_seq=23 ttl=64 time=0.892 ms
64 bytes from 172.16.0.205: icmp_seq=24 ttl=64 time=0.960 ms
64 bytes from 172.16.0.205: icmp_seq=25 ttl=64 time=1.05 ms
64 bytes from 172.16.0.205: icmp_seq=26 ttl=64 time=0.089 ms
64 bytes from 172.16.0.205: icmp_seq=27 ttl=64 time=0.097 ms
64 bytes from 172.16.0.205: icmp_seq=28 ttl=64 time=0.081 ms
--从没有网络限速的机器下载，带宽1000MB
64 bytes from 172.16.0.205: icmp_seq=29 ttl=64 time=0.078 ms
64 bytes from 172.16.0.205: icmp_seq=30 ttl=64 time=0.077 ms
64 bytes from 172.16.0.205: icmp_seq=31 ttl=64 time=0.073 ms
64 bytes from 172.16.0.205: icmp_seq=32 ttl=64 time=0.072 ms
64 bytes from 172.16.0.205: icmp_seq=33 ttl=64 time=0.079 ms
64 bytes from 172.16.0.205: icmp_seq=34 ttl=64 time=0.074 ms
64 bytes from 172.16.0.205: icmp_seq=35 ttl=64 time=0.080 ms
64 bytes from 172.16.0.205: icmp_seq=36 ttl=64 time=0.077 ms
|
有限速方向，尝试了BBR和cubic 拥塞算法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
#tcpperf -c 172.16.0.205 -t 100
Connected mysqld217:51254 -> 172.16.0.205:2009, congestion control: cubic
Time (s) Throughput Bitrate Cwnd Rwnd sndbuf ssthresh Retr CA Pacing rtt/var
0.000s 0.00kB/s 0.00kbps 14.3Ki 41.3Ki 85.0Ki 2048Mi 0 0 65.2Mi 427us/213
1.029s 122MB/s 975Mbps 1595Ki 1595Ki 9512Ki 576Ki 0 0 123Mi 15.2ms/8
2.005s 105MB/s 843Mbps 1595Ki 1595Ki 9512Ki 576Ki 0 0 123Mi 15.2ms/10
3.010s 105MB/s 843Mbps 1595Ki 1595Ki 9512Ki 576Ki 0 0 123Mi 15.2ms/17
4.016s 105MB/s 843Mbps 1595Ki 1595Ki 9512Ki 576Ki 0 0 123Mi 15.2ms/13
5.022s 105MB/s 843Mbps 1595Ki 1595Ki 9512Ki 576Ki 0 0 123Mi 15.2ms/14
6.028s 105MB/s 842Mbps 1595Ki 1595Ki 9512Ki 576Ki 0 0 123Mi 15.2ms/17
7.003s 105MB/s 843Mbps 1595Ki 1595Ki 9512Ki 576Ki 0 0 123Mi 15.2ms/15
8.009s 105MB/s 843Mbps 1595Ki 1595Ki 9512Ki 576Ki 0 0 123Mi 15.2ms/13
#tcpperf -c 172.16.0.205 -t 100
Connected mysqld217:51932 -> 172.16.0.205:2009, congestion control: bbr
Time (s) Throughput Bitrate Cwnd Rwnd sndbuf ssthresh Retr CA Pacing rtt/var
0.000s 0.00kB/s 0.00kbps 14.3Ki 41.3Ki 128Ki 2048Mi 0 0 98.0Mi 406us/203
1.011s 120MB/s 957Mbps 271Ki 2281Ki 10.4Mi 560Ki 2244 0 108Mi 2427us/11
2.033s 104MB/s 831Mbps 271Ki 2281Ki 10.4Mi 560Ki 1056 0 109Mi 2417us/18
3.021s 104MB/s 830Mbps 274Ki 2281Ki 10.4Mi 560Ki 1056 0 109Mi 2428us/18
4.014s 103MB/s 827Mbps 271Ki 2281Ki 10.4Mi 560Ki 1452 0 108Mi 2423us/19
5.031s 104MB/s 835Mbps 274Ki 2281Ki 10.4Mi 560Ki 660 0 80.2Mi 2435us/22
6.033s 102MB/s 818Mbps 271Ki 2272Ki 10.4Mi 560Ki 2112 0 109Mi 2426us/17
7.030s 103MB/s 823Mbps 274Ki 2281Ki 10.4Mi 560Ki 1716 0 117Mi 2430us/18
8.023s 103MB/s 826Mbps 274Ki 2281Ki 10.4Mi 560Ki 1452 0 109Mi 2428us/20
9.016s 103MB/s 827Mbps 271Ki 2281Ki 10.4Mi 560Ki 1452 0 108Mi 2423us/15
|
跑tcpperf触发限速时的监控(上下两个窗口是同一台机器)，红色是丢包率挺高的，绿色丢包就没了，应该是拥塞算法和限速管控达成了平衡
反过来限速被我去掉了(限速可以进出双向单独控制)
|
1
2
3
4
5
6
7
8
9
10
11
|
#tcpperf -c mysqld217 -t 1000
Connected 172.16.0.205:32186 -> mysqld217:2009, congestion control: bbr
Time (s) Throughput Bitrate Cwnd Rwnd sndbuf ssthresh Retr CA Pacing rtt/var
0.000s 0.00kB/s 0.00kbps 14.3Ki 41.3Ki 128Ki 2048Mi 0 0 100Mi 397us/198
1.001s 1107MB/s 8859Mbps 471Ki 985Ki 4641Ki 277Ki 0 0 1083Mi 390us/22
2.001s 1103MB/s 8823Mbps 465Ki 985Ki 4641Ki 277Ki 0 0 1089Mi 393us/16
3.000s 1111MB/s 8892Mbps 465Ki 985Ki 4641Ki 277Ki 0 0 1072Mi 403us/25
4.000s 1099MB/s 8789Mbps 459Ki 985Ki 4794Ki 277Ki 0 0 799Mi 399us/18
5.001s 1098MB/s 8786Mbps 459Ki 985Ki 4794Ki 277Ki 0 0 1066Mi 387us/12
6.000s 1100MB/s 8799Mbps 462Ki 974Ki 4794Ki 277Ki 0 0 1069Mi 399us/16
7.001s 1135MB/s 9078Mbps 453Ki 985Ki 4794Ki 277Ki 0 0 1059Mi 377us/19
|
查看限速配置如下：
|
1
2
3
4
5
6
|
{txcmbps:844.000, txckpps:120.000}
//限速解释
0-31 我猜这是网卡队列(可以修改);
txcmbps:844.000 105.5MB/s 每秒带宽105.5MB
txckpps:120.000 120K packet/s 每秒12万网络包
|
sysbench(主键查询-小包) 12万QPS 正好命中 txckpps:120，tcpperf (大包)稳定的105MB带宽命中txcmbps:844
去掉后长这样：
|
1
2
3
4
|
#ovsctl -n set_out_pps -v -1 //把pps限制为-1==不限制
#ovsctl set_tx -p {} -r -1; //带宽不限制
{vport: 2 {map: 0, prio:L, weight: 0}meter: {-}queue: [ 0- 31L]}
|
对这块网络管控感兴趣可以去了解一下 ovs 这个开源项目(open virtual switch)
去掉网卡限速后的结果
实际结构如下：
放开所有网络控制后，1000并发压力 30万QPS，RT 3.28，此时从sysbench 以及空闲机器ping MySQLD机器的 RTT和没压力基本一致
top状态：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
%Node1 : 23.4 us, 12.3 sy, 0.0 ni, 61.4 id, 0.0 wa, 0.0 hi, 3.0 si, 0.0 st
%Cpu64 : 63.2 us, 36.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu65 : 44.4 us, 21.9 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 33.8 si, 0.0 st
%Cpu66 : 66.6 us, 33.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu67 : 63.4 us, 36.6 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu68 : 64.2 us, 35.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu69 : 64.9 us, 35.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu70 : 66.6 us, 33.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu71 : 65.3 us, 34.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu72 : 67.7 us, 32.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu73 : 63.6 us, 36.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu74 : 66.7 us, 33.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu75 : 42.4 us, 19.9 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 37.7 si, 0.0 st
%Cpu76 : 63.9 us, 36.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu77 : 67.0 us, 33.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu78 : 68.3 us, 31.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu79 : 64.9 us, 35.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu80 : 65.2 us, 34.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu81 : 44.4 us, 21.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 34.1 si, 0.0 st
%Cpu82 : 63.9 us, 36.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu83 : 44.2 us, 23.4 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 32.3 si, 0.0 st
%Cpu84 : 65.7 us, 34.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu85 : 68.3 us, 31.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu86 : 67.5 us, 32.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu87 : 62.4 us, 37.6 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu88 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
|
小思考：
我们中间尝试走本机127.0.0.1 压测时QPS 是24万，比跨机器压的 30万打了8折，想想为什么？网络延时消耗完全没影响？
总结
简单可复制的证明办法：抓包，快速撕逼和分析
肯定有很多人想到：内存、磁盘、线程池、队列、网络等等原因，但是这些所有原因有一个共同的爹：RT，所有这些影响因素最后体现出来就是RT 高了，你CPU资源不够、内存慢最后总表现就是在客户端看来你的 RT 太高。
所以我们去掉这些复杂因素先在MySQLD所在EC2 的网卡上抓一个包看看RT，再对比一下1000/2000并发时抓包看到的 RT 有没有升高，如果有升高说明问题在MySQLD这端(含OS、MySQLD的问题)，如果 RT 不变那么问题不在MySQLD这端，并且从EC2网卡出去都是很快的，那么问题只能是在路上或者客户端的sysbench自己慢了。
这是我们星球里说的无招胜有招–抓包大法，扯皮过程中我还没见过几个不认网络抓包的，也有那么一两个扯上是不是网卡驱动有问题，我的代码不会有问题
两个限速条件：pps 120k(每秒最多12万网络包)，带宽 844mbps=105.5MB/s
Sysbench 查询都是小包，触发第一个条件，tcpperf触发第二个条件
ping ping神功失效了吗？也没有，我后来又测试了100、200并发，rtt 0.2ms和0.4ms，也就是说随着并发的增加rtt 增加到0.8ms后就不再增加了。上来1000并发已经到了天花板
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
64 bytes from polardbxyt27 (mysqld217): icmp_seq=159 ttl=64 time=0.226 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=160 ttl=64 time=0.334 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=161 ttl=64 time=0.336 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=162 ttl=64 time=0.213 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=163 ttl=64 time=0.104 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=164 ttl=64 time=0.096 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=165 ttl=64 time=0.101 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=166 ttl=64 time=0.116 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=167 ttl=64 time=0.104 ms--以上 100并发，QPS 119K
64 bytes from polardbxyt27 (mysqld217): icmp_seq=168 ttl=64 time=0.093 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=169 ttl=64 time=0.088 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=170 ttl=64 time=0.405 ms--以下 200并发，QPS 119K
64 bytes from polardbxyt27 (mysqld217): icmp_seq=171 ttl=64 time=0.419 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=172 ttl=64 time=0.386 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=173 ttl=64 time=0.474 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=174 ttl=64 time=0.462 ms
64 bytes from polardbxyt27 (mysqld217): icmp_seq=175 ttl=64 time=0.410 ms
|