ping的avg值是rtt min/avg/max/mdev中第二个数，反映ICMP往返延迟，轻量但仅限网络层；真实业务延迟需用curl分段测TTFB、iostat看await等综合判断。
ping 的 avg 值怎么看，但别当真
直接执行 ping -c 10 example.com，末尾那行 rtt min/avg/max/mdev = X/X/X/X ms 里第二个数就是 avg 值——它确实是 Linux 下最轻量、最常被查的“平均响应时间”。但它只测 ICMP 往返，不包含 DNS、TCP、TLS、服务端处理任何一环。
常见错误现象：ping example.com 耗时 80ms，curl -s https://example.com 却要 1200ms；或者 ping 完全超时，但网站能正常打开。
- 用 IP 直连（如
ping 93.184.216.34）可排除 DNS 解析干扰 - 若目标禁 ICMP（CDN、云主机常见），avg 会失真或全为 timeout，此时 avg 没参考价值
- avg 是算术平均，对毛刺敏感；一次丢包重传拖慢整轮，就拉高 avg，但用户感知未必如此
iostat -x 看磁盘 await，这才是真 I/O 延迟
Linux 没有全局“系统平均响应时间”，await 才是块设备层最核心的延迟指标。它代表 I/O 请求从发出到完成的平均耗时（含排队 + 实际服务），单位毫秒。
执行 iostat -x 1，重点关注三列：
-
await > 10ms（HDD）或> 1ms（SSD/NVMe）需立即关注；持续 >50ms 基本确认瓶颈 -
r_await显著高于w_await？优先排查读密集型操作（如数据库全表扫描、日志归档） -
avgqu-sz > 1且与await同步上升？说明请求卡在内核块层队列，不一定是磁盘慢，可能是调度器配置错（比如 NVMe 设备启用了bfq）
curl -w 测真实 HTTP 响应分段耗时
要贴近用户打开网页的真实体验，必须走 TCP+HTTP 栈。用 curl 的 -w 参数分离各阶段：
curl -w"DNS: %{time_namelookup} | TCP: %{time_connect} | TLS: %{time_appconnect} | TTFB: %{time_starttransfer} | TOTAL: %{time_total}\n" -o /dev/null -s https://example.com
关键字段含义：
-
%{time_namelookup}：DNS 解析耗时（用 IP 直连可归零） -
%{time_connect}：TCP 连接建立完成（含三次握手） -
%{time_appconnect}：TLS 握手完成（HTTPS 必看，若为空说明是 HTTP） -
%{time_starttransfer}：首字节到达时间（TTFB，含服务端逻辑处理） -
%{time_total}：整个请求耗时（含响应体下载）
注意：-o /dev/null 防止下载内容干扰计时；单次结果波动大，建议循环 10 次取 TTFB 中位数，比 TOTAL 更反映“页面开始渲染”体验。
查不到进程时，去 /proc/diskstats 和 dmesg 深挖
当 iotop -oP 和 pidstat -d 1 都显示安静，但 await 居高不下，问题大概率不在用户进程层。
- 执行
cat /proc/diskstats，对比同一设备前后 5 秒的第 9 列（aveq，加权队列长度）和第 11 列（await累加值），确认是否真实堆积 - 检查
/sys/block/nvme0n1/queue/scheduler：NVMe 设备必须为none，若显示mq-deadline或bfq，说明调度器被错误启用 - 运行
dmesg | grep -i "nvme\|ata\|error\|timeout"：PCIe 链路重试、ACPI 电源异常、AER 错误都会引发延迟毛刺，iostat完全不体现
最常被忽略的一点：await 高 ≠ 磁盘坏了。它可能只是队列深度压满、驱动 Bug、甚至 BIOS 中 PCIe ASPM 设置不当。
