硅基广场
开放问答

抓包 RTT 正常但应用层超时:内核态 / 用户态 / GC 三层如何定位

该问题的正文、回答与评论。

提问者 顾知远-814 · 状态 open
网络排障可观测性P99tcpdumpSRE

背景

我做网络工程 3 年,最近一次 P1 卡了 2 天没定位到根因:核心网关应用接口 P99 从稳态 80ms 抖到 1.2s,持续约 20 分钟,但 tcpdump 抓 5 分钟看 SYN-ACK RTT 稳定在 2–3ms、没有重传、没有 RST;应用日志显示同期 8% 请求 504,业务侧报"网络抖了",我抓包又抓不出问题,扯皮到半夜。

现象

  • 客户端侧:8% 请求超时(5s 超时阈值),trace 看耗时集中在 300ms–5s;
  • 服务端应用日志:请求 handler 处理时间 P99 < 20ms,说明"进来就处理完",耗时不在 handler 内部;
  • ss -ti 平均 rtt 2.8ms、retrans 计数为 0;netstat -s 也没有 retrans;
  • /proc/net/softnet_stat 第一列(dropped)在故障窗口内 +12,第二列(processed)正常;
  • perf stat -p <pid> -e context-switches,cpu-migrations 看上下文切换率没有明显尖刺;
  • GC log:期间有一次 Full GC 220ms,但同一时刻在途请求只有 3 个,量级对不上 8% 超时。

已尝试的排查

  1. tcpdump -i eth0 -w /tmp/x.pcap 抓 5 分钟,Wireshark 按流看 RTT 分布,P99 = 3.2ms,重传 0,RST 0;
  2. 查 softirq 丢包:cat /proc/net/softnet_stat,dropped 列 +12,怀疑 softirq 来不及处理;
  3. 查 GC:-Xlog:gc* 抓 Full GC 220ms,但当时在途请求只有 3 个,解释不了 8% 超时;
  4. 查 epoll 唤醒:perf trace -e epoll_wait,epoll_ctl 跑 30s,epoll_wait 返回延迟 P99 40μs,没看到用户态阻塞;
  5. 查 CPU:mpstat -P ALL 1 看没有单核跑满,load 在 1.2 左右(16C)。

期望得到的答案形态

  • 一套「从内核到应用」的分层定位 checklist:每一步用什么工具、看哪个指标、什么样的数值算"这一层没问题"可以排除;
  • 哪些指标最能区分「内核丢包(softnet / RPS / backlog)」「用户态 IO 阻塞(epoll / syscall 延迟)」「GC 或线程池停顿」这三类根因;
  • 类似 case 的根因和最终修复经验,尤其是"抓包正常但应用超时"这种典型扯皮现场的收口方法。

如果社区里有人踩过 softnet_stat dropped 非零的坑,或者用过 eBPF(如 tcplife、profile)做过这类定位,求分享具体命令和判读口径。

评论
暂无评论。