Linux perf record 采样频率过高时如何调整

我第一次把 Linux 性能采样开得很激进，是为了抓一个只在高并发时出现的短热点。结果 perf.data 膨胀得很快，业务进程的 CPU 曲线也被采样动作抬高了。这个场景里，最先该改的是 perf record 的 -F/--freq，例如从每秒数千次降到 99 或 199，再观察热点是否仍然稳定；不要一上来就把内核限制调到更高。

官方地址：https://docs.kernel.org/

先分清三个采样频率控制层

这三个名字很容易混在一起。-F 99 表达“希望按约 99 Hz 采样”；kernel.perf_event_max_sample_rate 表达“系统最多允许多快”；而 perf_cpu_time_max_percent 是内核在采样处理过重时的保护提示。前者是命令级选择，后两者属于系统级约束。

用 -F 从低频率开始采样

我的习惯是先用低频率建立基线，再逐步增加。对短命令或热点明显的任务，99、199 可以作为起点；需要更细的调用栈时再尝试 499 或更高。频率没有脱离工作负载的“标准答案”，同一个数值放在空闲机器和满载机器上，代价并不一样。

# 先读取系统上限，避免把目标频率和内核上限混为一谈
cat /proc/sys/kernel/perf_event_max_sample_rate

# 用较低目标频率采集一次，-g 用于保留调用链，-o 固定输出文件
perf record -F 99 -g -o perf.data -- ./server --profile-case

# 采集结束后只读分析结果，不重复启动被测任务
perf report -i perf.data

如果命令输出提示目标频率被限制，先接受这个限制并记录实际结果。-c/--count 是按事件计数周期采样，和频率模式不是同一个调节入口；排查“频率过高”时不要把两个参数混写成一回事。

什么时候需要看内核上限和自动降频

当 -F 已经很低但仍看到采样过重，或者多个事件叠加后频率被压低，就要看系统级设置。Linux 文档说明，perf_event_max_sample_rate 过高可能影响整机性能；它更像安全上限。只有经过压测、确认权限和机器余量后，才考虑调整它。

# 读取两个系统级保护项，先留档再做任何修改
cat /proc/sys/kernel/perf_event_max_sample_rate
cat /proc/sys/kernel/perf_cpu_time_max_percent

# 例：临时把系统最大采样率收紧到 2000，数值应按环境评估
sudo sysctl -w kernel.perf_event_max_sample_rate=2000

perf_cpu_time_max_percent 非零时，内核会在判断采样处理超出提示比例后尝试降低采样频率；它不是让 -F 变快的开关。除非明确知道自己愿意承担额外 CPU 风险，否则不要把它设为 0 来“解决”降频提示。

调整后用三项指标复查

频率降低后，最容易犯的错是只看 perf.data 变小就宣布成功。我会重复同一工作负载至少两次，对比前三个热点的排序、调用链是否足够完整，以及被测任务的 CPU 开销。如果热点排序大幅漂移，说明频率可能降过头，也可能工作负载本身不稳定。

• 数据量：文件增长是否回到可管理范围，是否仍能打开并分析。
• 覆盖效果：perf report 中的主要热点和调用链是否在重复采样中稳定。
• 业务代价：采样期间被测任务的吞吐、延迟或 CPU 占用是否发生不可接受的变化。

实践中可以按 99 → 199 → 499 的阶梯逐次增加，每次只改变频率并保留记录。若一次采样的目的只是找大热点，低频往往已经够用；若要分析很短的函数或调用链细节，才值得支付更高采样成本。

常见问题

把 perf_event_max_sample_rate 调高就能得到更精确结果吗？

不一定。它只是允许更高上限，真正是否值得还要看 -F、事件数量、调用链开销和被测任务余量。

为什么我设置了 -F 1000，实际频率却更低？

可能触发了系统上限或内核的采样开销保护。先读取两个 sysctl，再看 perf 的提示，不要仅凭文件大小猜原因。

只采用户态能减少开销吗？

在问题允许时可以用用户态事件范围减少无关样本，但这会丢掉内核路径信息。先明确要回答的是应用热点还是系统调用路径。