Linux 故障排除中的 strace 和 perf

当 Linux 服务器运行缓慢、频繁崩溃或 CPU 负载过高，而应用程序日志无法解释原因时，有两款工具能填补大部分信息空白。 strace strace 会告诉你进程正在向内核请求什么。 perf 它能告诉你 CPU 的时间都花在了哪里。二者结合，能解答“为什么卡住”和“正在做什么”这两个问题，而其他任何工具都无法以如此低廉的代价做到这一点。

本文将介绍何时使用这两款工具、如何安装它们、实际需要执行的命令，以及如何在运行中的服务器上控制开销。

何时使用 strace 与 perf

区分很简单。当 perf 当 CPU 负载较高且需要查明具体哪个函数导致该情况时。使用 strace perf

perf perf以可配置的频率采样内核的硬件计数器，因此开销通常低于1%，在生产环境中运行是安全的。 strace 则通过 ptrace，这可能会使目标进程的速度降低 10 到 100 倍。在运行中的系统上请谨慎使用，并且务必配合过滤器使用。

安装 strace 和 perf

这两个工具均位于标准软件仓库中。strace 依赖于 ptrace syscall，该功能多年来一直是所有现代内核的组成部分。perf 使用 perf_events 接口，并需要与您当前运行的内核版本相匹配的软件包。

在 Ubuntu 或 Debian 上：

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

在 RHEL、AlmaLinux 或 Fedora 上：

sudo dnf install strace perf

该 $(uname -r) 位数至关重要。针对不同内核版本构建的 perf 二进制文件会产生令人困惑的输出，并可能无声地丢弃事件。请通过 perf --version 和 strace -V 进行验证。

若要让 perf 显示函数名而非十六进制地址，您需要调试符号。请安装相应的 -dbg 或 -debuginfo （例如， libc6-dbg 在 Debian 上），并使用 -g 在 GCC 中编译您自己的二进制文件。

在容器内部， strace 需要 --cap-add=SYS_PTRACE 和 perf 需要 --cap-add=SYS_ADMIN 。若缺少这些权限，工具会以看似程序错误的方式失败。

使用 strace 追踪系统调用

运行 strace command 可从进程启动时开始对其进行跟踪。若要附加到正在运行的进程，请使用 strace -p PID。对于任何多线程或会分叉的进程，请添加 -f 来跟踪子进程，否则您将错过大部分活动。

输出行以返回值结尾。 -1 ENOENT 表示进程请求的文件不存在。 -1 EACCES 表示权限问题。仅这两类错误就占了生产环境中 bug 的相当大比例。

最有用的标志是 -e trace=GROUP，它将输出限制在指定的系统调用类别内，使冗余信息保持在可控范围内。

在繁忙的服务器上，建议先运行 strace -c -p PID 运行十到二十秒。 -c 标志会在您断开连接时打印系统调用计数、总耗时和错误的摘要。这能让您在不淹没终端的情况下，快速判断哪些类别值得深入检查。随后使用窄范围过滤器重新连接。

其他值得了解的标志： -T 记录每次调用所花费的时间， -Z 仅显示失败的调用，以及 -o file 将输出写入日志文件而非终端，对于嘈杂的进程而言，这种方式速度更快。

使用 perf 分析 CPU

perf 有四个您最常使用的命令。

从 perf stat -p PID 快速概览。需关注的数值：

• IPC（每周期指令数）低于 1.0：CPU 处于停滞状态，通常是由于内存访问导致的。
• LLC 负载缺失率过高：工作集无法完全放入缓存，因此 CPU 正在等待 RAM 响应。
• 高上下文切换次数：这是 I/O 受限工作负载的典型特征，此时线程会因磁盘或网络而持续阻塞。

如果发现异常，请进一步查看 perf record -F 99 -g -p PID -- sleep 30。 -F 99 采样频率为 99 Hz，这足以找出热点函数，并避免在 100 Hz 这样的整数频率上与内核计时器同步。 -g 标志会捕获调用图，因此 perf report 可以向您展示导致该问题的函数入口路径。

在 perf report中，“开销”列表示占总采样数的百分比。若 _int_malloc 或 memcpy 表示大量内存分配。若您自己的某个函数开销较高，那就是您要寻找的热点。

如果您看到的是十六进制地址而非函数名称，说明二进制文件已被剥离或缺少调试符号。请安装对应的 -dbg 包，或使用 -g.

生产环境服务器上的实际操作流程

针对繁忙服务器上的实际故障，处理流程如下：

1. 首先使用简易工具确认故障症状： top, vmstat, iostat. 若在虚拟机上，请检查 st （steal）列。若数值超过5%，则说明虚拟机管理程序是瓶颈，而非你的代码。
2. 如果 CPU 占用率很高，运行 perf top 几秒钟，然后 perf record -F 99 -g -p PID -- sleep 30 针对问题进程运行。以 99 Hz 采样率捕获 30 秒的数据，大约会产生 1.7 MB 的数据。
3. 如果进程卡死、运行缓慢或返回错误，请运行 strace -c -p PID 并运行十秒钟，然后查看摘要。如果某个系统调用类别占主导地位，请使用 strace -e trace=GROUP -T -p PID.
4. 当您找到可疑的系统调用或函数后，请断开连接。切勿让任何工具在生产环境中运行超过必要的时间。

两点注意事项。 strace 输出可能包含环境变量、文件路径以及从套接字读取的字节，因此在将日志分享给团队外部之前请进行数据脱敏。此外，如果您计划定期执行此类操作，建议将 bpftrace 以及更全面的 eBPF 工具集：提供同类可视化能力，开销低于 1%，且从设计之初就面向生产环境。

若您运行的工作负载需要深度诊断访问权限，且无法使用共享基础设施，请了解我们的专用服务器。