strace -T 能直接显示每个系统调用的完整耗时（秒级），配合 -tt（微秒时间戳）、-e trace=open,read,write等（聚焦I/O）、-s 256（防截断）可精准定位真实I/O延迟，如open>100ms、read接近超时值或fsync突增，并需结合iostat/lsof等交叉验证。
用 strace -T 能直接看到每个系统调用从发起、内核处理到返回的完整耗时（单位：秒），这是定位 I/O 延迟最直观的依据——不是靠猜，而是看哪次 open、read、write 或 connect 真的卡住了。
关键参数组合：-T 必须搭配 -tt 和精准 trace
-T 单独用效果有限，容易被海量输出淹没。真正有用的组合是：
-
-T：在每行末尾显示该次调用实际耗时，例如
read(3, ...)= 4096 <0.234567> - -tt：加上微秒级时间戳，便于对齐业务日志或监控报警时间点
- -e trace=open,read,write,fsync,connect,recvfrom,sendto：只聚焦 I/O 相关调用，避免 poll/select/rt_sigreturn 等干扰项
- -s 256：防止路径、IP、SQL 等关键参数被截断（默认仅 32 字节）
识别真实 I/O 延迟的三个信号
别把正常阻塞当故障。真正值得警惕的延迟有明确特征：
- openat/open 耗时 >100ms：可能挂载点卡住、NFS 服务异常、或磁盘响应慢（配合 iostat 验证）
-
read/write 在阻塞 fd 上耗时接近或超过预期超时值：比如
read(5, ...)= -1 EAGAIN <2.998s>，而应用层设置 read timeout 是 3 秒 - fsync 耗时突增（如从 0.001s 跳到 1.2s）：说明底层存储写入缓慢，可能是 SSD 寿命下降、RAID 卡电池失效或 ext4 日志模式配置不当
生产环境安全抓取建议
strace 对进程性能有影响，尤其高并发服务。稳妥做法是：
- 先用
ps aux | grep your_service找到具体 worker 进程 PID，不 attach master 或主线程 - 加 -o /tmp/strace_io.log 输出到文件，避免终端刷屏和丢失
- 单次采样控制在 30–60 秒，用
timeout 60 strace -T -tt -e trace=io -p $PID -o /tmp/strace.log - 怀疑是文件路径问题时，加 -y 参数，让
read(3)显示成read(3</var/log/app/error.log>, ...)，一眼锁定目标文件
配合验证，排除误判
strace 显示的是“发生了什么”，但不解释“为什么”。需交叉验证：
- 看到大量
open("/etc/localtime", ...)耗时波动？检查是否频繁加载 locale，可改用export LC_ALL=C - 发现
read(4, ...)总是返回 0 且紧跟着poll(..., POLLIN)？可能是对端已关闭连接，程序未正确处理 EOF - 对比
lsof -p $PID和 strace 中的 fd 号，确认描述符对应的真实资源（如 socket、pipe、regular file）
