1
des 2022-03-18 12:39:25 +08:00 via iPhone
建议先确认你的带宽是不是满了,或者是公网
|
2
wtysos11 2022-03-18 13:00:51 +08:00
原因挺多的,跟具体实现相关,我在实验室和公司都遇到过类似的情况,出问题的点都不一样。
实验室中环境是我们自己搭的 k8s+istio ,一个是楼上说的带宽跑满了,一个是其他的服务在其他地方出现性能瓶颈点,比如说内存或者磁盘读写。还有一个是中间过程中的其他组件到达了瓶颈,实验室中 istio 的 ingressgateway 和 istiod 性能会在一定流量到瓶颈,然后又因为没有到官方设的阈值不会自动加资源。 公司里出的情况主要是具体代码的实现问题,当初那个坑是上一个实习生留下来的,有很多地方加了限速和熔断,然后限速的值又不是自适应的。 |
3
Vegetable 2022-03-18 13:05:40 +08:00
证明瓶颈不是 CPU 。可能是带宽、数据库、内存等等
|
4
vicalloy 2022-03-18 13:09:26 +08:00
除了前面说到的瓶颈可能在磁盘、网络 IO 等地方外,如果进程 /线程过多可能导致 context switch 过高,也跑不慢 CPU 。
|
5
des 2022-03-18 13:20:48 +08:00 via iPhone
给你个排查思路
先看目标机器上 CPU 占用和 uptime 的 load 如果都不高,那就依次检查带宽、数据库负载、慢查询、连接池、线程池、锁争用 如果 uptime 的 load 数值高,那就检查是哪个指标不正常,然后再具体定位 |
6
des 2022-03-18 13:21:41 +08:00 via iPhone
依我的经验来看,建议先检查带宽占用
|
7
des 2022-03-18 13:23:16 +08:00 via iPhone
补充一下,压测机器本身的指标最好也看下,压测机顶不住也是有可能的
|
8
cy21st OP top - 13:42:30 up 6 days, 21:58, 3 users, load average: 8.34, 8.28, 8.21
Tasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie %Cpu0 : 45.8 us, 19.9 sy, 0.0 ni, 7.1 id, 0.0 wa, 0.0 hi, 27.3 si, 0.0 st %Cpu1 : 63.3 us, 26.3 sy, 0.0 ni, 10.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st %Cpu2 : 42.8 us, 20.2 sy, 0.0 ni, 8.4 id, 0.0 wa, 0.0 hi, 28.6 si, 0.0 st %Cpu3 : 60.3 us, 25.8 sy, 0.0 ni, 13.2 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st %Cpu4 : 43.4 us, 20.2 sy, 0.0 ni, 12.1 id, 0.0 wa, 0.0 hi, 24.2 si, 0.0 st %Cpu5 : 53.7 us, 24.2 sy, 0.0 ni, 21.5 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st %Cpu6 : 42.6 us, 21.1 sy, 0.0 ni, 10.7 id, 0.0 wa, 0.0 hi, 25.5 si, 0.0 st %Cpu7 : 54.7 us, 26.0 sy, 0.0 ni, 18.7 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st KiB Mem : 16265792 total, 6559592 free, 5005600 used, 4700600 buff/cache KiB Swap: 0 total, 0 free, 0 used. 10676364 avail Mem |
9
cy21st OP 带宽没有跑满,用的 redis 负载不到 25%左右
|
10
cy21st OP 压测部分日志
Latency distribution: 10% in 10.5121 secs 25% in 11.2028 secs 50% in 11.9332 secs 75% in 12.1955 secs 90% in 12.3108 secs 95% in 12.5069 secs 99% in 17.9934 secs Details (average, fastest, slowest): DNS+dialup: 0.0693 secs, 0.1331 secs, 19.5505 secs DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs req write: 0.0011 secs, 0.0000 secs, 0.9662 secs resp wait: 11.3609 secs, 0.0370 secs, 14.2545 secs resp read: 0.0001 secs, 0.0000 secs, 0.9405 secs Status code distribution: [200] 99994 responses Error distribution: [1] Post "http://xxx/abtest": read tcp xxxxx:52726->xxx:80: read: connection reset by peer [1] Post "http://xxx/abtest": read tcp xxxxx:52922->xxx:80: read: connection reset by peer [1] Post "http://xxx/abtest": read tcp xxxxx:54143->xxx:80: read: connection reset by peer |
11
v2lf 2022-03-18 15:53:50 +08:00
系统占用 cpu 很高
|
12
sampeng 2022-03-18 17:49:23 +08:00
8 核。load 都到 8 了。约等于跑满了。。。不一定 cpu 满了才是满。说明,cpu 一直在等什么东西。
监控太少,需要系统性监控才能分析出来。得一项一项排查。盲猜?盲猜磁盘 io 或者网络 io |
15
des 2022-03-18 18:45:05 +08:00 via iPhone
|
16
des 2022-03-18 19:01:35 +08:00 via iPhone
cat 这个文件看看 /proc/interrupts
照着这个排查一下 https://www.cnblogs.com/qinyujie/p/11127660.html |
17
wangyu17455 2022-03-18 19:01:54 +08:00
也许你需要用 htop 看看是不是 cpu 条里红色部分的内核时间占了那剩下的 25
|