手里管着几十台 Linux 服务器的人迟早会面对一类怪问题进程明明活着CPU 占用看着也不高请求却慢得像蜗牛或者日志干干净净生产环境却总在某个特定时刻超时再或者文件描述符以一个诡异的斜率持续上涨直到某天服务突然开始拒绝连接。这种时候top、iostat、日志三板斧往往全部失灵因为问题既不在 CPU 利用率上也不在磁盘 IO 上而在进程与内核之间那一层看不见的接口上。strace 就是专门替你盯住这一层的工具它记录进程发起的每一次系统调用、参数、返回值、耗时和错误码把所有隐蔽行为摊开在终端里。熟悉它之后你会多出一种“顺着系统调用反推现场”的排障能力。如果你之前只是知道 strace 这个名字或者只会 strace ./a.out 看个热闹这篇文章就是为你准备的。它的重点不是入门而是生产环境里真正能救命的几个高级参数、三个典型的实战排查案例以及我长期使用中积累的避坑经验。读完之后你应该能回答这几个问题如何精准追踪子进程如何量化每次调用的耗时如何从几十万行输出里快速提取有效信息以及最关键的一个——在业务高峰期使用 strace怎么才不至于把服务拖垮。1. 先搞清楚 strace 到底在做什么1.1 系统调用就是程序与内核之间唯一的传菜口程序再复杂最终也必须借助操作系统内核来访问硬件和资源。读文件、写网络、申请内存、创建线程、获取当前时间这些动作全部要经过系统调用把请求递进内核。用个不太严谨但很好懂的比方用户态程序好比餐厅前厅的客人内核是后厨系统调用就是服务员把点菜单递给后厨的传菜口。客人是不是真有耐心等和菜单有没有递进后厨、后厨做了多久是两道不同的问题。应用日志能告诉你客人等待时的感受系统调用才能告诉你点菜单是什么时候递进去的、后厨什么时候出的菜。strace 就是这个传菜口附近的一台执法记录仪。它通过 ptrace 机制把目标进程的每一次系统调用都截住记录下调用名、参数、返回值以及耗时等关键字段。举个例子如果应用程序执行了 open(/data/app.log, O_RDONLY) 这个动作strace 会输出 open(/data/app.log, O_RDONLY) 3。等号后面的 3 就是内核返回给进程的文件描述符后续的 read、lseek、close 全都围绕这个数字继续展开。返回的错误码价值同样非常高。很多应用层代码把错误信息吞到日志里或者干脆忽略返回值但 strace 会原样保留 -1、-2 之类的原始 errno 值-1 ENOENT 表示文件不存在-1 EAGAIN 表示资源暂时不可用-1 ECONNRESET 表示连接被对端重置。这些原始信号往往比应用日志里那句“操作失败”精确得多。可以说strace 的价值不在于让你看到更多日志而在于让你看到应用层根本没记录的信息。1.2 原理并不神秘ptrace 与陷入-停止-恢复strace 的底层依赖 Linux 的 ptrace 系统调用。跟踪者通过 PTRACE_ATTACH 挂到目标进程上目标进程每进入一次系统调用内核会先把它停下来通知 strace 读取现场信息等 strace 处理完再通过 PTRACE_SYSCALL 让它继续执行并在系统调用退出时再次停下来记录返回值。这个“陷入-停止-读取-恢复”的循环构成了 strace 的所有能力也解释了它为什么自带性能损耗。这里有个非常实际的交互细节你 strace -p 1234 按回车的那一刻1234 号进程会先收到一个 SIGSTOP 信号随后在 strace 的驱动下恢复运行。绝大多数业务对这个极短暂的中断毫无感知但对于对时间精度要求极高的实时推送进程确实可能造成几个毫秒的毛刺。所以生产环境 attach 之前最好跟业务负责人打声招呼或者在病发率低的时段做不要一声不吭直接挂上去。基于 ptrace 的跟踪还有一个隐含限制strace 只能看到系统调用层面的信息。如果你的程序卡在某个纯用户态循环里疯狂做字符串处理或加密计算strace 的输出里根本看不到对应耗时因为这段过程没有发生系统调用。这种问题应该交给 perf、pstack 去看调用栈而不是拿着一把显微镜找一栋楼的出口。我一直把 strace 定位成“系统调用层取证工具”而不是万能的性能分析器。1.3 先画个范围哪些问题归 strace 管适合 strace 的场景很典型进程 hang 住不退、请求偶尔超时找不到原因、连接数或文件描述符异常增长、程序启动时报莫名其妙的错误、对外部依赖的调用迟迟没有响应、日志里出现断续的 ECONNREFUSED 或 ETIMEDOUT。这些场景的共同点是问题发生在程序与系统资源的交互边界上应用层日志失真或缺失只有系统调用层能留下完整证据。不适合 strace 的场景也很明显CPU 使用率居高不下但系统调用量正常、应用层算法逻辑复杂导致响应慢、内存碎片化或堆内泄漏。前者优先考虑 CPU 采样工具后者优先考虑堆分析或日志审计否则你会在几十万行输出里茫然很久。记住一句话strace 回答的是“进程在向内核做什么”而不是“进程在想什么”。2. 高级参数先学会精准下刀2.1 -f 与 -ff别让真正的“凶手”子进程漏网默认情况下strace 只跟踪你指定的那一个进程fork、vfork、clone 出来的子进程不会自动纳入跟踪范围。这一点让很多人吃过亏主进程只是个调度者真正干活、真正出问题的往往是它拉起的 worker 子进程。如果你只 strace 主进程会看到它反复 fork、waitpid看起来一切正常问题自然无处追寻。加上 -f 之后strace 会把所有子进程一并纳入跟踪输出会混杂在一起。如果子进程很多建议用 -ff 搭配 -o让每个进程单独写入一个文件文件名通过 %p 占位符区分例如 strace -ff -o /tmp/trace-%p.log -p 1234。这在多进程架构下几乎是必需品。我曾经在某个内部网关服务上排查句柄增长主进程只负责 accept请求处理全部分散到 8 个 worker 里如果不加 -ff光是把交错日志按 pid 分开就得折腾半天。这里要澄清一个细节线程与进程的差别。Java 的线程池、Go 的 goroutine 调度本质上不会通过 fork 创建子进程strace -f 对这类“线程型”应用并不会分裂出多个输出流。那是不是就不需要 -f 了也不一定Java 进程如果通过 ProcessBuilder 拉起外部命令仍然需要 -f 才能跟踪到那个子进程。规则只有一条只要你的进程有可能直接或间接产生子进程并且你怀疑问题藏在子进程里就老老实实加 -f 或 -ff。2.2 时间维度-tt 和 -T 告诉你“慢在哪”排查性能问题只看系统调用名称和返回值远远不够。要回答“到底慢在哪”必须引入时间维度。strace 提供三个时间参数-t 精确到秒-tt 精确到微秒-ttt 输出从 epoch 开始的微秒级时间戳-T 则单独打印每个系统调用自身消耗的时间。生产环境里我几乎只使用 -tt 和 -T输出类似下面这样$ strace -f -tt -T -e tracenetwork,read,write -p 1234 14:32:05.108762 read(3, ......, 8192) 4096 0.000128 14:32:05.109234 connect(5, {...}, 16) -1 ETIMEDOUT 2.310240第一行说明这次 read 在内核态只花了 0.128 毫秒第二行说明这次 connect 尝试整整耗了 2.3 秒后超时返回。看到这样的输出定位方向立刻明确如果 connect 耗时长那是网络栈或对端的问题如果系统调用本身都很快但两个调用之间隔了很久说明进程在用户态做计算或者等待锁。两种“慢”的根源完全不同不加时间参数你根本分不出来。读输出时有个技巧连续两条记录里后一条的时间戳减去前一条的时间戳再减去前一条的 -T 值约等于进程在用户态停留的时间。对比不同接口在正常时段与异常时段的这个差值就能把“用户态忙等”和“内核态慢”区分开。这个层面的分析光靠日志很难做到却是 strace 天生擅长的活。2.3 过滤表达式让输出从“天书”变“简报”全量追踪在低负载进程上没问题生产环境动辄每秒数千次系统调用直接 strace -f -p PID输出文件很快就能以 GB 级别增长。高级用法的核心一是会用 -e trace二是要敢用 -e trace 做减法。-e trace 后面可以跟类别比如 file、network、desc、signal、memory、process 等也可以直接写逗号分隔的具体调用名比如 -e traceopen,close,read,write还可以用 ! 取反例如 -e trace!futex 表示排除 futex 调用。我习惯把流程拆成两步先用 -c 看统计下一节细讲确认热点集中在哪几类调用再回来用精确的 trace 列表做聚焦追踪。这一步能同时把磁盘 IO 和干扰降到接近零。除了按调用名过滤还可以用 -e readfd 和 -e writefd让 strace 把指定文件描述符上传输的数据内容原样打印出来。排查协议问题时这个功能很实用想知道这个连接到底发出去一段什么样的内容、另一端回了什么直接使用 -e tracesendto,recvfrom -e write3 -e read3数据内容立刻一览无余。需要提醒的是 -s 参数控制打印字符串的长度默认 32 字节通常不够可以根据需要调到 200 或 1024但调得太长同样会刷屏。2.4 摸黑定位用 -c统计汇总才是第一站当我完全不确认问题方向时第一动作永远是 strace -c -p PID 让它跑 30 到 60 秒。这个参数不会打印每条调用明细而是按系统调用名称汇总次数、总耗时、每次平均耗时和占比输出长得像这样% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 54.21 3.215821 1236 2601 78 futex 21.30 1.263107 1266 997 0 epoll_wait 12.11 0.718394 39 18422 2 read 8.30 0.492220 5 98444 0 write看到这样的汇总表思路会立刻聚焦如果大头在 futex 等待说明线程锁竞争很严重如果大头在 read 且错误数很高可能是 IO 或 socket 出现异常重试如果 write 的调用次数高得离谱则要怀疑日志体系是否有问题。对比正常时段的基线也同样重要——同一个进程健康的时候用 -c 跑几十秒哪个调用占比异常变高基本就是问题所在。这个“先统计、再聚焦”的路径比盲目 -e traceall 从头打到尾高效太多。3. 生产环境实战三个让我印象最深的案例3.1 慢请求的真相connect 超时而不是应用逻辑卡死先讲一个非常典型的“日志无异常响应却间歇变慢”的场景。某个内部网关服务的部分请求会时不时飙到几秒业务方怀疑是服务端线程被锁住。开发同学加了一圈日志发现请求进入方法后下一行日志往往在 1.9 秒之后才出现于是怀疑是业务代码里的某个远程调用出了问题但具体卡在哪一步依旧没有头绪。我用下面这条命令附加到主进程上持续跟踪了几分钟strace -f -tt -T -e tracenetwork,read,write -p 主进程PID输出里的关键一行是 connect(7, {...}, 16) -1 ETIMEDOUT 1.952478后面的 recvfrom 也以超时返回。结论非常清晰两行日志之间那 1.9 秒并不是业务代码在计算而是底层 TCP 连接一直在尝试建立但迟迟得不到确认最终由内核返回 ETIMEDOUT。问题集中在内网网络质量、对端服务的 accept 队列耗尽或防火墙丢包上而不是业务线程卡死。开发顺着这个方向继续查发现是下游服务所在的集群负载已经很高SYN 队列溢出导致握手超时。这个案例里日志只能给一个模糊的“慢”字strace 却把“慢在哪一次系统调用、哪一段网络路径”直接钉在证据上。排障效率的差别就在这里。如果你也在排查“时快时慢”的服务记得把 -e tracenetwork 当作首选过滤条件。它不只会看到 connect、sendto、recvfrom还会看到 accept4、getsockopt 等网络相关调用基本能覆盖网络问题的整个链路。3.2 文件描述符泄漏反复 open 却无人 close第二个案例是关于 too many open files 的。某个常驻服务运行几天后开始拒绝新连接系统日志里反复出现 too many open files。应用自身的日志只记录了异常堆栈和连接失败信息却没有任何代码路径说明是谁创建了新文件描述符。我先用 ls -l /proc/PID/fd 查看现场发现大量文件描述符都指向同一个配置文件数量多达几百个。这是一个强烈的信号某个函数每次处理请求都会重新打开这个文件却没有关闭。下一步就用 strace 做定向过滤strace -f -e traceopen,openat,close,dup,dup2 -o /tmp/fd_trace.log -p 服务PID配合 -c 看统计很快确认 openat 调用次数比 close 多得多而且每次 open 的文件路径都是同一个。修复也很直接把读取配置的逻辑改成进程启动时读一次或者至少保证每次读完都关闭。问题解决后文件描述符曲线重新走平。这个案例给我的教训是fd 泄漏类问题strace 的输出一定要选对类别直接看 open、close 的配对关系就行。如果不加过滤连接池新建 socket 的细节会淹没在 read/write 里反而很难一眼锁定。另外/proc/PID/fd 本身就是一个超高性价比的探针先看它再决定要不要上 strace能省掉很多不必要的追踪。3.3 CPU 飙高问题可能在于反复 EAGAIN 的自旋第三个案例是排查高并发服务 CPU 异常飙高。从 perf top 能看到大量时间花在内核的网络协议栈里但花了一阵子没有锁定具体行为。我改用 strace -c 跑了一分钟发现 read 调用次数异常膨胀超过了同类正常服务的十几倍且错误列表中 EAGAIN 占比极高。接着用 strace -f -e traceread,recvfrom,epoll_wait -tt -T 观察具体时序输出呈现出一个规律epoll_wait 刚报告某个 socket 可读程序立刻去 read却拿到 -1 EAGAIN之后程序没有等待下一次就绪通知而是立刻又 read再拿 EAGAIN。如此高频自旋CPU 自然被白白烧掉。这通常意味着程序把 socket 设成了非阻塞模式却错误地以为 epoll 返回可读之后 read 一定会成功没有正确处理竞争条件或者是习惯性地在循环里先 read 一次再进入 epoll导致忙等。这里的修复点不在 strace而在于代码对非阻塞 IO 的处理策略读到 EAGAIN 就应该让出 CPU等待下一次可读事件而不是立刻重试。但如果没有 strace -c 先捕捉到“read 次数数量级异常”这个线索后面的代码评审根本不知道往哪个方向看。性能问题的排查很多时候不是一锤定音而是靠 strace 提供一把把钥匙把搜索空间逐步缩小。4. 生产环境用 strace性能开销必须先算清4.1 开销可以量化别让追踪本身制造故障strace 的开销远比很多人想象的大。一个普通的系统调用原本只需要陷入内核一次再返回被 strace 跟踪后每次进入和退出都要各自停下由 ptrace 通知跟踪进程并等待它处理。每一步都有上下文切换成本整体开销往往能放大一个数量级以上。我曾经在一台测试机上模拟过高吞吐的小包转发进程附加 strace 后吞吐掉了接近九成。所以生产环境故障排查最忌讳的就是直接 -f -e traceall 挂上一个核心服务追着追着进程先被你拖到超时。如果业务本身对延迟极其敏感哪怕只是 attach 几秒钟也可能引发连锁超时。更稳妥的策略是先用 -c 做样本统计或者用 timeout 20 strace -f -e tracenetwork -p PID 这样的命令强制限制时长再或者挑一个副本或灰度实例来追踪不要动关键的在线节点。采样永远比全量安全拿到的结论虽然只是样本但用于定位问题方向已经足够真需要全量验证就放在低峰期做。4.2 权限、容器与附加时的实战纪律追踪别人的进程需要足够权限root 能追踪同机任意进程普通用户只能追踪同属自己的进程在容器内如果 seccomp 配置禁止 ptrace即使 root 也会收到 Operation not permitted。因此生产环境建议先确认三件事当前用户有没有权限、容器的 seccomp 是否放行、以及 /proc/sys/kernel/yama/ptrace_scope 的值是不是允许跨进程追踪。多数发行版默认值是 1只允许父进程追踪子进程跨进程 attach 到别的用户或别的进程前需要调整或使用 root。附加瞬间目标进程会被 SIGSTOP 短暂冻结绝大多数业务无感但敏感服务仍可能出现毫秒级毛刺。我给自己定的纪律是先通知相关团队再开始跟踪设置输出文件而不是直接打到终端避免把一堆二进制乱码喷进 SSH 会话追踪结束后用 Ctrl-C 让 strace 退出它不会杀掉目标进程。千万不要脑袋一热 kill -9 那个 PID——我见过不止一次把 strace 的 pid 和业务 pid 搞混结果误杀线上进程的惨案。跟踪结束之后尽快压缩或清掉 trace 文件因为它体积通常非常大。4.3 采样时长与基线对比跑多久才算够生产环境最纠结的问题是“该让 strace 跑多久”。跑太短可能正好错过故障点跑太久磁盘和进程双双受累。我的经验是分两种情况如果是周期性出现的慢请求根据监控中的故障时间窗至少覆盖两次异常间隔比如每 5 分钟出现一次就跑 11 分钟如果是持续性性能问题60 秒的 -c 统计已经完全足够。无论哪种情况都建议先记录一份健康时段的基线再和故障时段的输出做对比。没有基线你很难判断 read 出现十万次是正常还是异常。追踪期间还要盯住两样东西目标进程的 CPU 占用有没有因为 strace 异常飙升磁盘剩余空间是否还在健康水位。一旦 strace 让进程的 CPU 占用翻倍马上停止考虑更轻量的方案。常见替代品里perf trace 在不少场景下的开销比 strace 低bpftrace 可以做内核级动态插桩但学习和使用成本都显著高于 strace。先掌握 strace在确有需要的时候再借这些工具做更精细的验证顺序不要搞反。5. 常见报错与避坑速查表5.1 高频报错看到它们别慌生产环境最常见的几类报错和对应的处理思路我整理成了一张表至少能帮你少搜半小时搜索引擎。报错信息含义处理方向strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted没有权限附加到目标进程确认当前用户/root检查 yama ptrace_scope 和容器 seccompstrace: ptrace(PTRACE_TRACEME, ...): Operation not permitted启动跟踪模式时被内核拒绝通常被 seccomp 或 yama 限制调整策略或换宿主环境执行strace: Process ... detached目标进程已解除追踪这是正常信息进程会继续运行strace: Process ... killed by SIGKILL 目标进程被强制杀死区分是 strace 误操作还是业务自身崩溃千万不要再补一刀strace: lseek(...) -1 ESPIPE管道或终端上不支持 lseek常见于 socket 或 pipe大多只是噪音不必惊慌No space left on device输出文件写满磁盘换路径、压缩、加过滤条件或者用 -o /dev/null 练手这里特别提醒一句如果你 strace 一个 pid看到没有任何输出一直卡着先不要怀疑工具坏了很可能是目标进程的全部线程都阻塞在某个内核态等待上或者你忘了加 -f而业务逻辑全在子进程里执行。这时候按 Ctrl-C 退出重新调整过滤条件再追踪比干等着有营养得多。5.2 避坑清单我长期使用沉淀下来的几条经验第一条永远从 -c 或窄过滤开始。上来就全量 trace 高并发进程等于把排查现场变成数据倾倒现场磁盘写满、进程卡慢、排障节奏全被打乱。先统计后聚焦这套流程适应绝大多数场景。第二条-e trace 的过滤可以叠加但要注意使用方式。不同 -e trace 之间后面的会覆盖前面的比如同时写 -e traceopen,close 和 -e traceread最终只会追踪 read。如果你确实要同时追多类调用把它们写进同一个 trace 里或者使用 -e tracefile,network,desc 这种类别式写法清晰且不易出错。第三条-s 和 -o 是保护现场的两个朋友。-s 控制打印数据的长度-o 把输出写进文件。两者配合既能保留完整的十六进制协议内容又不会让终端被不可见字符刷爆。除非你只是临时快速看一眼否则我强烈建议任何追踪都使用 -o 参数。第四条追踪结束立刻检查一次被追踪进程的存活状态。strace 退出后目标进程应当继续运行但偶发情况下如果目标进程在 attach 前已经处于异常状态分离后可能仍然短时间无响应。不要理所当然地以为一切恢复如初顺手 curl 一下健康接口最稳妥。5.3 一个关于“什么时候不用 strace”的补充最后补充一个容易被忽略的判断标准。如果 strace 输出显示所有系统调用耗时都很短但业务整体还是很慢那么瓶颈一定出在用户态——要么是 CPU 密集计算要么是锁竞争导致的等待要么是垃圾回收频繁。此时继续延长追踪时间没有意义正确的下一步是 pstack 或 perf record 去抓用户态调用栈。反过来如果 strace 里某个系统调用耗时明显异常大那才是往内核态、网络、磁盘方向深挖的信号。这个判断规则能帮你避免在错误的方向上浪费几个小时。在排查过的那么多性能问题里strace 从来不是我拿出的第一把工具但它是我用来给结论盖章的那把工具。很多问题在没有系统调用证据之前都只是一堆猜测一旦 strace 把 open、read、connect 的时间点摆出来讨论通常就结束了。我个人的建议是把 strace 的常用参数组合写进自己的速查笔记尤其默记住 -c、-f -tt -T、-e tracefile/network 这三个组合下次线上告警响起来的时候你会感谢自己提前做过功课。如果你还想继续深入下一步可以把 perf 和 bpftrace 加入武器库用来解决 strace 本身开销带来的局限。祝你在排障路上一查一个准。