被測服務(wù)背景說明
服務(wù)調(diào)用鏈路
一個后臺的被測服務(wù)+2個數(shù)據(jù)庫
服務(wù)調(diào)用鏈.png
接口功能
單個查詢接口壓測莹妒，接口調(diào)用鏈如下：
接口調(diào)用鏈.png
一、環(huán)境介紹
1.1 壓測環(huán)境
windows本地環(huán)境忌警，部署的locust環(huán)境
壓測環(huán)境.png
1.2 被測服務(wù)環(huán)境
騰訊云申請的linux服務(wù)器，部署在測試環(huán)境中
4C 8G
二、壓測結(jié)果
2.1 TPS和RT
TPS和RT.png
2.2 服務(wù)器資源
先來一個整體的資源狀態(tài)：
服務(wù)器性能.png
在服務(wù)器上筐喳，通過top命令看一下服務(wù)器資源
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使用率在增加壓力之后，并沒有達(dá)到100%
- TCP_tw告警
應(yīng)該先看哪個呢函喉？
先看CPU為什么不能被壓滿避归。TCP_tw在不影響TCP的條件下，可以先放一放管呵。
三梳毙、問題分析
3.1看下啟動的php進(jìn)程數(shù)量
[ops@gzqc-172_24_16_88-null hk_ipo2]$ ps -ef|grep php-fpm | wc -l
64
64的數(shù)量并不是很多，為啥說不多捐下。
猜測：通過top命令看到一個php進(jìn)程大概占用0.2%的內(nèi)存账锹。
6440.002=0.512 < 4G. 不會對內(nèi)存產(chǎn)生影響
3.2 看下當(dāng)前的網(wǎng)絡(luò)鏈接狀態(tài)
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.
創(chuàng)建的表滿了，這里可以對表進(jìn)行配置優(yōu)化坷襟。
如何優(yōu)化奸柬，之前高老師有專欄描述過。先放放婴程，應(yīng)該不影響CPU
3.3 查一下服務(wù)器的網(wǎng)卡和隊列
[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
為什么要查廓奕，能看出來啥呢？現(xiàn)在還不清楚
3.4 查詢一下服務(wù)器的網(wǎng)絡(luò)狀態(tài)
[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
在當(dāng)前建立的TCP鏈接中排抬，Send-Q隊列有積壓懂从。
再查詢下，當(dāng)前服務(wù)器有多少個鏈接數(shù)
[ops@gzqc-172_24_16_88-null hk_ipo2]$ netstat |grep 9933 |grep ESTABLISHED |wc -l
272
真的非常多了~
猜測施壓端的帶寬可能堵塞蹲蒲。導(dǎo)致服務(wù)器端發(fā)送出去的請求番甩，壓力端無法接收。
導(dǎo)致服務(wù)端的Send-Q隊列有積壓届搁。服務(wù)器CPU上不去缘薛。
3.5 看一下施壓端到服務(wù)端經(jīng)過的路由
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
大概經(jīng)過了11跳恕齐。真的是很多~
四乞娄、解決方法
那么改成用測試環(huán)境的服務(wù)器，來壓服務(wù)器試試效果把~
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使用率上來之后显歧，對應(yīng)的php服務(wù)的進(jìn)程數(shù)也上來了~
響應(yīng)時間仪或，為什么到后面還是會那么長呢？這個可能需要繼續(xù)分析原因士骤。
請看下次分析~
五范删、分析過程中用到的命令
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
