本地电脑对服务器施压——导致网络堵塞

2021-06-11  本文已影响0人  bonnie_xing

被测服务背景说明

服务调用链路

一个后台的被测服务+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 

可以看出来的问题:

  1. CPU使用率在增加压力之后,并没有达到100%
  2. 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


上一篇下一篇

猜你喜欢

热点阅读