被测服务背景说明
服务调用链路
一个后台的被测服务+2个数据库
服务调用链.png
接口功能
单个查询接口压测，接口调用链如下：
接口调用链.png
一、环境介绍
1.1 压测环境
windows本地环境，部署的locust环境
压测环境.png
1.2 被测服务环境
腾讯云申请的linux服务器，部署在测试环境中
4C 8G
二、压测结果
2.1 TPS和RT
TPS和RT.png
2.2 服务器资源
先来一个整体的资源状态：
服务器性能.png
在服务器上，通过top命令看一下服务器资源
top.png
top - 10:32:41 up 262 days, 1:10, 4 users, load average: 7.56, 8.87, 8.07
Tasks: 292 total, 21 running, 270 sleeping, 1 stopped, 0 zombie
Cpu(s): 61.0%us, 6.5%sy, 0.0%ni, 25.4%id, 0.0%wa, 0.0%hi, 7.1%si, 0.0%st
Mem: 8061080k total, 7056480k used, 1004600k free, 309996k buffers
Swap: 0k total, 0k used, 0k free, 4367708k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9564 ops 20 0 708m 7932 1200 S 9.9 0.1 351:04.40 ftrace_udp_agen
786 ops 20 0 1225m 17m 9056 S 4.6 0.2 0:18.19 php-fpm
2035 ops 20 0 1225m 16m 8984 R 4.6 0.2 0:13.24 php-fpm
3058 ops 20 0 1225m 16m 9020 S 4.6 0.2 0:09.50 php-fpm
3060 ops 20 0 1225m 16m 8980 S 4.6 0.2 0:09.47 php-fpm
可以看出来的问题：
- CPU使用率在增加压力之后，并没有达到100%
- TCP_tw告警
应该先看哪个呢？
先看CPU为什么不能被压满。TCP_tw在不影响TCP的条件下，可以先放一放。
三、问题分析
3.1看下启动的php进程数量
[ops@gzqc-172_24_16_88-null hk_ipo2]$ ps -ef|grep php-fpm | wc -l
64
64的数量并不是很多，为啥说不多。
猜测：通过top命令看到一个php进程大概占用0.2%的内存。
6440.002=0.512 < 4G. 不会对内存产生影响
3.2 看下当前的网络链接状态
dmesg
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
创建的表满了，这里可以对表进行配置优化。
如何优化，之前高老师有专栏描述过。先放放，应该不影响CPU
3.3 查一下服务器的网卡和队列
[ops@gzqc-172_24_16_88-null hk_ipo2]$ ll /sys/class/net/eth0/queues/
total 0
drwxr-xr-x 2 root root 0 Jun 11 10:53 rx-0
drwxr-xr-x 2 root root 0 Jun 11 10:53 rx-1
drwxr-xr-x 2 root root 0 Jun 11 10:53 tx-0
drwxr-xr-x 2 root root 0 Jun 11 10:53 tx-1
为什么要查，能看出来啥呢？现在还不清楚
3.4 查询一下服务器的网络状态
[ops@gzqc-172_24_16_88-null hk_ipo2]$ netstat |grep 9933 |grep ESTABLISHED
tcp 0 0 172.24.16.88:9933 172.18.86.167:57833 ESTABLISHED
tcp 0 0 172.24.16.88:9933 172.18.86.167:57827 ESTABLISHED
tcp 0 0 172.24.16.88:9933 172.18.86.167:57512 ESTABLISHED
tcp 0 0 172.24.16.88:9933 172.18.86.167:57561 ESTABLISHED
tcp 0 4034 172.24.16.88:9933 172.18.86.167:57521 ESTABLISHED
tcp 0 0 172.24.16.88:9933 172.18.86.167:57574 ESTABLISHED
tcp 0 0 172.24.16.88:9933 172.18.86.167:57722 ESTABLISHED
tcp 0 9738 172.24.16.88:9933 172.18.86.167:57828 ESTABLISHED
tcp 0 0 172.24.16.88:9933 172.18.86.167:57637 ESTABLISHED
tcp 0 1849 172.24.16.88:9933 172.18.86.167:57634 ESTABLISHED
tcp 0 6604 172.24.16.88:9933 172.18.86.167:57558 ESTABLISHED
在当前建立的TCP链接中，Send-Q队列有积压。
再查询下，当前服务器有多少个链接数
[ops@gzqc-172_24_16_88-null hk_ipo2]$ netstat |grep 9933 |grep ESTABLISHED |wc -l
272
真的非常多了~
猜测施压端的带宽可能堵塞。导致服务器端发送出去的请求，压力端无法接收。
导致服务端的Send-Q队列有积压。服务器CPU上不去。
3.5 看一下施压端到服务端经过的路由
C:\Users>tracert 172.24.16.88
通过最多 30 个跃点跟踪
到 [172.24.16.88] 的路由:
1 1 ms <1 毫秒 <1 毫秒 172.18.86.1
2 1 ms <1 毫秒 <1 毫秒 172.18.3.56
3 <1 毫秒 <1 毫秒 <1 毫秒 172.18.3.8
4 1 ms 1 ms 1 ms 169.254.64.114
5 * * * 请求超时。
6 * * * 请求超时。
7 * 4 ms 4 ms 10.200.9.190
8 * * * 请求超时。
9 4 ms 3 ms 4 ms 10.200.33.34
10 * * * 请求超时。
11 3 ms 3 ms 4 ms queue.futuhk.com [172.24.16.88]
跟踪完成。
image.png
大概经过了11跳。真的是很多~
四、解决方法
那么改成用测试环境的服务器，来压服务器试试效果把~
4.1 TPS和RT
image.png
TPS和RT曲线于之前基本是一直的
4.2 CPU
image.png
image.png
top - 15:06:31 up 262 days, 5:43, 4 users, load average: 202.89, 182.23, 105.54
Tasks: 436 total, 205 running, 231 sleeping, 0 stopped, 0 zombie
Cpu(s): 84.5%us, 8.0%sy, 0.1%ni, 0.0%id, 0.0%wa, 0.0%hi, 7.4%si, 0.0%st
Mem: 8061080k total, 7007924k used, 1053156k free, 322696k buffers
Swap: 0k total, 0k used, 0k free, 3916020k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9564 ops 20 0 707m 7660 1200 R 2.6 0.1 375:37.06 ftrace_udp_agen
3727 ops 20 0 1302m 16m 9128 R 2.2 0.2 0:36.03 php-fpm
10352 ops 20 0 16328 696 564 S 2.2 0.0 485:07.74 attr_agent_svr
CPU也能压测到100%了
[ops@gzqc-172_24_16_88-null rx-0]$ ps -ef|grep php-fpm | wc -l
202
CPU使用率上来之后，对应的php服务的进程数也上来了~
响应时间，为什么到后面还是会那么长呢？这个可能需要继续分析原因。
请看下次分析~
五、分析过程中用到的命令
ps -ef|grep php-fpm
ps -ef|grep php-fpm | wc -l
dmesg
ps -ef|grep php-fpm | wc -l
ll /sys/class/net/eth0/queues/
netstat
netstat |grep 9933
netstat |grep 9933 |grep ESTABLISHED
netstat |grep 9933 |grep ESTABLISHED |wc -l
ifconfig
top
netstat |grep 9933 |grep ESTABLISHED |wc -l
ps -ef|grep php-fpm |wc -l
vmstate 1
pstack 26969
iftop
ipcs -m
free -m
vmstat -s | grep -i page
netstat
netstat -ntpl
netstat -ant
