perf是唯一能兼顾实时性、精度和历史趋势的工具，通过perf record抓带时间戳的调用流、perf script提取并聚合，可生成调用频率走势曲线；ftrace function_graph提供微秒级时序但需手动统计，其他工具仅输出总量或快照。
直接看函数调用频率的「走势」，perf 是唯一能兼顾实时性、精度和历史趋势的工具；ftrace 可以抓细粒度调用序列但难自动绘图；gprof 和 syscount 只给总量或快照，没法反映随时间变化的趋势。
用 perf record + perf script 抓带时间戳的调用流
这是最贴近「走势」需求的做法：不是只统计总数，而是记录每次调用发生的时间点，后续可按秒/毫秒聚合出频率曲线。
-
perf record -e probe:do_sys_open -a -- sleep 10：全局捕获do_sys_open调用（需内核开启CONFIG_KPROBES），持续 10 秒 -
perf script | awk '{print int($4/1000000000)}' | sort -n | uniq -c：提取秒级时间戳，统计每秒调用次数 - 注意：
probe:do_sys_open是 kprobe 事件，不是所有函数都支持；用户态函数要用-e 'probe:my_func'并提前用perf probe添加探针 - 输出类似
123 1720522440（123 次调用发生在 Unix 时间戳 1720522440 秒），导入 Excel 或 gnuplot 就能画折线图
用 ftrace 的 function_graph tracer 输出调用时序
ftrace 不直接输出频率数字，但它的 function_graph 模式会记录每个函数的进入/退出时间差，天然适合观察「某段时间内调用是否密集」。
宝塔Linux面板11.8.1
下载
宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。
echo function_graph > /sys/kernel/debug/tracing/current_tracer-
echo 1 > /sys/kernel/debug/tracing/tracing_on，跑目标负载，再echo 0 > /sys/kernel/debug/tracing/tracing_on -
cat /sys/kernel/debug/tracing/trace | grep -E "(entry|exit)" | head -50：看到类似<...>-1234 [001] d..2 12345.678901: func_entry: do_sys_open</...> - 关键点：时间戳精确到微秒，连续多行 entry 出现在同一毫秒内，就说明该函数正在高频被调；但得手动数或写脚本统计单位时间内的 entry 行数
- 别用
functiontracer——它只记入口，没出口时间，无法判断是单次长耗时还是多次短调用
避免误把「CPU 占用率」当「调用频率」
很多用户看到 top 或 perf top 里某个函数排第一，就以为它调用最频繁——这是错的。高 CPU 占用可能是单次调用耗时长（比如 memcpy 大块内存），而不是调用次数多。
-
perf record -g -e cycles,instructions能同时采集周期数和指令数，配合perf report --sort=symbol,comm看「每调用平均耗时」 - 真正高频函数（如
spin_lock、__kmalloc）往往单次极快，perf默认采样间隔（~1ms）可能漏掉它们；得加-F 9999提高采样频率，但会增大开销 -
syscount输出的是总次数，perf stat -e syscalls:sys_enter_read -p PID sleep 1才能拿到 1 秒内 read 系统调用次数——但它仍是标量，不是走势
要真看出走势，核心就一条：必须拿到带高精度时间戳的原始事件流，然后自己按时间窗聚合。任何只给汇总数字的工具，都只是快照，不是趋势。
