前置图片缓存HIT却还需要加载时间排查
故障现象
很多用户反馈小程序打不开
图片打开超时

接口请求超时

环境
上线之前已经做了很多优化,如果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

[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优化,基本上可以排除。
检查网络带宽分析

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拥堵控制频繁触发。基于上线前我们有对各项参数做了优化,且突发的这种生产异常状态,我们的结论是客户的网络问题。
前置机有三台,作为前面负载器的三个上游节点。大概率是负载器异常。告知客户让其联系负载器厂家进行排查。

浙公网安备 33010602011771号