前置图片缓存HIT却还需要加载时间排查

故障现象

很多用户反馈小程序打不开

图片打开超时

image

接口请求超时

image

环境

上线之前已经做了很多优化,如果tcp优化,连接超时优化,各类缓存优化,各类压缩,内核优化等等等

排查思路

早就做了图片缓存优化,正常命中缓存HIT,响应时间是0,因为读缓存是非常快的,但是从日志上看,一个图片就用了好几秒。
排查的方向更侧重于网络,不排除是不是用到swap分区。怀疑是不是带宽满了
free -h确认swap分区为0,没用到,接下来就是查如下

开始排查

#网络连接状态
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
#检查网络带宽
sar -n DEV 1 3
#检查是否有丢包
netstat -s | grep -i segment
#检查IO情况
iostat -x 1

8865140fc323c6e557c4069ba674631f

[root@wc-tyn-1-0032 ~]# iostat -x 1
Linux 3.10.0-1160.66.1.el7.x86_64 (wc-tyn-1-0032.novalocal)     11/07/2025      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.92    0.00    1.00    0.03    0.00   98.04

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     2.69    0.00    2.60     0.16    45.94    35.34     0.00    1.09    3.34    1.09   0.44   0.11
vdb               0.00     0.02    0.00    0.18     0.01     2.84    31.80     0.00    0.58    4.17    0.57   0.51   0.01
dm-0              0.00     0.00    0.00    0.20     0.01     2.91    29.16     0.00    0.60    4.26    0.59   0.17   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.00    0.00    6.00    0.00    0.00   90.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    2.00    0.00     8.00     0.00     8.00     0.00    1.00    1.00    0.00   0.50   0.10
vdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.54    0.00    5.56    0.00    0.00   90.91

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.55    0.00    5.61    0.00    0.00   91.84

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     0.00    0.00    1.00     0.00   108.00   216.00     0.00    2.00    0.00    2.00   3.00   0.30
dm-0              0.00     0.00    0.00    1.00     0.00   108.00   216.00     0.00    2.00    0.00    2.00   2.00   0.20

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.01    0.00    2.01    0.00    0.00   96.98

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.51    0.00    1.01    0.00    0.00   98.48

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.51    0.00    1.52    0.00    0.00   97.98

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    26.00    0.00   34.00     0.00   240.00    14.12     0.03    0.85    0.00    0.85   0.15   0.50
vdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

分析

网络连接状态分析

LAST_ACK 5 # 等待最后确认
SYN_RECV 1 # 收到SYN,等待确认
ESTABLISHED 130 # 正常连接
FIN_WAIT1 22 # 主动关闭,等待远程TCP确认
FIN_WAIT2 59 # 主动关闭,等待远程TCP关闭
CLOSING 1 # 双方同时关闭
TIME_WAIT 316 # 连接已关闭,等待清理

1.FIN_WAIT1 和 FIN_WAIT2 过多,一共有81个,大量连接没有正常关闭
2.TIME_WAIT 316 这个是最高的,只能说明连接在频繁的建立和断开,这种情况正常是端口耗尽才会出现,但上线前有做了tcp优化,基本上可以排除。

检查网络带宽分析

image
0.计算一下吞吐量:
571.87 + 103.41 = 675.28 KB/s
1 Byte = 8 bits
675.28 KB/s × 8 = 5402.24 Kb/s
1 Mbps = 1000 Kb/s
5402.24 Kb/s ÷ 1000 = 5.402 Mbps

1.发送包比接收包还要多,接近1.5:1,不正常。
2.发现有大量的小包
发送包平均大小: 571.87KB/s ÷ 516.67包/s ≈ 1.1KB/包
接收包平均大小: 103.41KB/s ÷ 337.67包/s ≈ 0.3KB/包
3.
500多个包/秒,却只有5Mbps左右的吞吐量,说明网络效率极低。

检查是否有丢包分析

1324058413 segments received 
1914606420 segments send out  #总发送段数
75486333 segments retransmited #重传段数
5406 bad segments received.

最直观的发现了问题!!!
75486333/1914606420=3.94%【重传率】
正常应该低于0.1%,超过1%就会明显的影响性能。

检查IO情况分析

%util 最高只有 0.5%,远低于瓶颈值,await 平均 1-2ms,响应良好,读写操作很少,系统非常空闲,非IO问题

结论

网络质量差导致了大量TCP重传。每个图片请求都可以发生多次的重传。TCP拥堵控制频繁触发。基于上线前我们有对各项参数做了优化,且突发的这种生产异常状态,我们的结论是客户的网络问题。
前置机有三台,作为前面负载器的三个上游节点。大概率是负载器异常。告知客户让其联系负载器厂家进行排查。

posted @ 2025-11-12 11:07  海yo  阅读(8)  评论(0)    收藏  举报