Linux perf record 采样权限与调用栈配置

如果 perf record 报权限错误，或者生成的 perf.data 里调用栈只有一两层，先不要急着把权限改成最宽。更稳妥的处理顺序是：先确认要采样的是一个进程还是整台机器，再看 perf_event_paranoid 与能力控制，最后根据程序是否保留帧指针选择 fp 或 dwarf。

最小可用配置通常是“目标进程 + 现有权限 + 合适的调用栈方式”。只有在范围确实需要扩大时，才调整系统级权限；临时调整后要记录原值并恢复。

官方资料：https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html

命令参考：https://man7.org/linux/man-pages/man1/perf-record.1.html

先分清 perf 的采样权限边界

perf record 的职责是采集性能事件并写入 perf.data，它本身并不等于“可以读取机器上的所有执行信息”。权限问题通常来自采样范围和事件类型的组合：只分析当前用户启动的一个进程，和用 -a 观察所有 CPU 上的活动，所需权限并不相同。

可以先用下面的命令把当前配置和采样范围写进排查记录。它只读取配置，不会修改系统设置。

# 读取当前用户对 perf_events 的限制级别
sysctl -n kernel.perf_event_paranoid

# 只采样目标程序，先从最小范围开始
perf record --call-graph fp -- ./demo-app

# -a 表示系统范围采样；只有确认需要观察全机活动时再使用
perf record -a --call-graph fp -- sleep 10

内核文档对 perf_event_paranoid 的描述可以概括为：

• -1 几乎不限制 perf_events 的范围和资源限制，开放面最大。
• 0 允许进程和系统范围监控，但对原始 tracepoint、ftrace function tracepoint 等事件仍有限制。
• 1 主要保留进程级监控，系统范围采样会受到限制。
• 2 进一步收窄到进程级用户态事件，内核态采样可能被拒绝。

不同发行版可能通过能力、容器策略或内核配置叠加限制，因此不要只凭一个数值判断“肯定能采样”。如果命令只对单个进程工作，而加上 -a 后失败，优先把它看成范围扩大导致的权限差异，而不是调用栈参数错误。

按报错选择权限控制方式

权限控制的目标是让负责分析的人拿到必要的观测能力，同时不要把整台机器的性能事件都暴露给任意用户。较新的 Linux 内核和 perf 工具可以使用 CAP_PERFMON 表达“允许性能监控”的能力；这比长期把 perf_event_paranoid 调到最宽更容易审计。

先把失败命令、目标范围和原始配置记录下来，再由管理员决定是授予受控能力、加入专用组，还是只在一次维护窗口里临时调整：

# 记录失败前的权限状态，便于结束后恢复和审计
date -Is
id
sysctl -n kernel.perf_event_paranoid
perf record -v --call-graph fp -- ./demo-app

# 只把需要的采样命令和目标范围写入变更记录，不在脚本里永久放宽权限
# 管理员完成授权后，再用同一条目标进程命令重试
perf record -v --call-graph fp -- ./demo-app

如果错误明确指向“权限不足”或某个事件无法打开，排查顺序可以这样收敛：

1. 去掉 -a，先验证单进程采样是否可用。
2. 把复杂的原始事件换成常见软件事件，确认不是事件本身被策略禁止。
3. 确认目标进程、perf 和内核处在同一权限边界，尤其注意容器、虚拟机和受限服务账号。
4. 需要系统范围或内核态信息时，再让管理员配置 CAP_PERFMON 或调整 sysctl，并记录授权对象。

不要把 sudo perf record 当成通用修复。它可能改变目标程序的环境、符号搜索路径和文件权限，也会让“普通用户为什么失败”这个问题被掩盖。权限扩大应当服务于明确的采样范围，而不是用来跳过判断。

选择 fp 还是 DWARF 调用栈

-g 或 --call-graph 会让 perf 记录调用链。用户态常见的两种展开方式是 fp 和 dwarf：fp 依赖帧指针链，开销较小；dwarf 依据 DWARF 的 CFI 信息展开，对省略帧指针的程序更有机会得到完整调用栈，但采样成本和数据量通常更高。内核态调用栈还受内核使用的展开器影响，不能把用户态选项简单等同于内核态结果。

先用低成本的帧指针方式建立基线：

# fp 适合先确认热点函数和采样链路是否正常
perf record -F 99 --call-graph fp -- ./demo-app

# 以文本方式读取结果，便于保存到排查记录
perf report --stdio

如果报告里的用户态调用栈经常断在中间，且目标程序没有保留帧指针，可以切到 DWARF。下面的数值表示请求的用户栈转储大小，实际结果仍会受内核和 perf 版本限制：

# dwarf 通过调试展开信息补足省略帧指针的用户态栈
perf record -F 99 --call-graph dwarf,16384 -- ./demo-app

# children 视图把子调用的样本归并到父函数，适合观察累计热点
perf report --stdio --children

选择原则可以压缩成一张表：

控制调用栈深度与采样频率

权限和调用栈都正确时，仍可能因为采样频率、栈深度或缓冲区压力让结果难以使用。频率越高，样本越密集；栈越深，单个样本携带的数据越多。不要同时把多个参数调到最大，否则很难知道是哪项造成了开销或丢样本。

# 先使用适中的频率与帧指针深度，保留可比较的基线
perf record -F 99 --call-graph fp,32 -- ./demo-app

# 只有调用层级确实较深时，再增加 mmap 缓冲区页面
# 页面数必须按 perf 的要求设置，并在记录中说明变更原因
perf record -F 99 -m 256 --call-graph fp,64 -- ./demo-app

--call-graph fp,32 中的 32 是用户态调用链深度请求；系统还会受 /proc/sys/kernel/perf_event_max_stack 等上限影响。若指定的深度超过内核上限，优先查看上限和报告中的实际栈深度，不要只重复增加命令参数。

# 读取内核对调用链深度的限制，命令失败时允许文件不存在
if [ -r /proc/sys/kernel/perf_event_max_stack ]; then
  # 这个值决定单个调用链最多复制多少层
  cat /proc/sys/kernel/perf_event_max_stack
else
  # 老内核没有该入口时，使用 perf --help 和发行版文档确认默认值
  echo "未找到 perf_event_max_stack"
fi

用 perf report 判断结果是否可读

正式分析前，先区分“没有采到样本”和“采到了但符号或调用栈不可读”。perf.data 能生成，只说明采样文件被写出；它不保证二进制、调试信息和内核符号都能被正确解析。

# 先查看报告摘要，确认是否存在样本和主要符号
perf report --stdio

# 需要原始事件、时间戳或调用链细节时，再增加输出范围
perf report --stdio --sort comm,dso,symbol

# 记录文件的元信息，便于确认报告与采样命令属于同一次分析
perf report --header-only

结果可以按下面三类判断：

• 没有 perf.data 或文件为空：先回到事件打开、目标进程和权限范围。
• 有样本但调用栈很浅：检查 fp 是否被省略，必要时换 DWARF，同时确认调试展开信息可用。
• 调用栈存在但函数显示为地址或未知符号：检查二进制是否被替换、符号是否可访问，以及分析环境是否匹配采样环境。

这一步不要把报告中的热点函数当成“已经证明的根因”。采样结果说明的是样本集中出现的位置，还需要结合程序版本、输入负载和调用关系做工程判断。

留下可复用的审计记录

性能采样通常涉及权限扩大、目标进程参数和可能包含路径或符号信息的结果文件。结束后应留下最小记录：谁执行了命令、采样的对象和范围、原始 perf_event_paranoid 值、是否使用能力授权、调用栈模式、采样频率，以及 perf.data 的保存位置。

# 保存本次采样的关键元数据，不把敏感业务输出混进文章或工单
{
  echo "time=$(date -Is)"
  echo "user=$(id -un)"
  echo "paranoid=$(sysctl -n kernel.perf_event_paranoid)"
  echo "command=perf record -F 99 --call-graph fp -- ./demo-app"
} > perf-capture-notes.txt

# 如果本次维护临时修改过 sysctl，按变更记录恢复原值
# 这里的值只是示例，实际恢复必须使用记录的原始值
# sudo sysctl -w kernel.perf_event_paranoid=

常见问题

为什么单进程能采样，加上 -a 就失败？

-a 将目标从一个进程扩大到系统范围，权限和资源限制都会不同。先确认是否真的需要全机采样，再由管理员配置对应能力。

fp 和 dwarf 哪个一定更准确？

没有脱离程序构建方式的绝对答案。保留帧指针时 fp 通常足够；省略帧指针导致调用链断裂时，DWARF 更适合作为补充，但它需要可用的展开信息并可能增加开销。

perf.data 生成了，为什么报告还是看不懂？

采样文件生成与符号解析是两件事。检查二进制和调试信息是否对应同一构建，再看调用栈模式、内核上限和报告排序方式。

总结

处理 Linux perf record 时，先把采样范围收窄到目标进程，再根据权限报错选择受控授权；调用栈优先用 fp 建立基线，出现断栈且具备展开信息时再使用 dwarf。最后用 perf report 区分权限失败、调用栈缺失和符号不可读，并记录临时权限变更与回退动作，这样得到的性能数据才便于复盘。