perf 主要设计用于 CPU 性能分析，定位 Rust 程序内存占用高时，perf 适合分析频繁内存分配导致的 CPU 开销，而非直接展示堆内存快照。若需查看具体内存泄漏或堆布局，建议配合 jemalloc profiler 或 heaptrack 使用。
先说结论：perf 可通过追踪内存分配系统调用定位高频分配热点，但不能直接显示内存泄漏详情，需结合 RSS 监控验证。
- 先定位：确认是内存泄漏导致持续增长，还是高频分配导致 CPU 占用高。
- 先做：使用 perf record 记录 mmap 或 kmem 相关迹点，配合调试符号分析调用栈。
- 再验证：观察优化后 VmRSS 变化及分配频率是否下降，避免引入过高采样开销。
命令速用版
以下命令用于记录内存分配相关的系统调用和内核事件，需 root 权限或 perf_event_paranoid 配置允许。
# 记录内存映射系统调用，-g 开启调用栈，-p 指定进程 ID
perf record -e syscalls:sys_enter_mmap -g -p <PID> `--sleep-time` 1000
# 记录内核内存页分配事件，需内核支持 tracepoints
perf record -e kmem:mm_page_alloc -g -p <PID> `--sleep-time` 1000
# 查看热点函数分布
perf report `--stdio`为什么会这样
perf 基于硬件事件计数器和内核迹点工作，能捕捉分配动作但无法直接统计剩余内存。Rust 程序内存占用高通常由两种情况引起：一是存在长期存活的对象未释放（泄漏），二是短期对象分配频率过高导致分配器压力大。perf 擅长发现第二种情况中的热点调用路径，因为每次分配都会触发系统调用或内核事件，从而在 perf 报告中形成热点。
分步处理
步骤 1：准备环境
确保系统已安装 perf 工具，Rust 程序编译时保留调试信息以便符号解析。在 Cargo.toml 中确认 release 模式下 debug = true 或单独构建带调试信息的二进制。
步骤 2：确认进程 ID
使用 pgrep 或 ps 命令找到目标 Rust 进程的 PID，确保进程处于负载较高状态以便捕捉有效数据。
步骤 3：执行采样
运行 perf record 命令，建议限制采样时间避免磁盘占用过大。若关注堆分配，可优先使用 syscalls:sys_enter_mmap 事件。
步骤 4：分析报告
使用 perf report 查看调用栈，找到分配频率最高的函数。注意区分标准库分配调用与业务逻辑代码。
步骤 5：回滚提醒
若修改代码后性能未改善，保留原始二进制以便对比，避免盲目优化导致逻辑错误。
怎么验证是否生效
优化后需监控进程内存指标和分配频率。使用 watch 命令配合 proc 文件系统查看 VmRSS 变化，确认内存增长趋势是否减缓。同时再次运行 perf record，对比优化前后同一函数的采样次数是否减少。公开资料中没有看到可靠的量化数据表明具体降低比例，需以实际业务监控为准。
常见坑
1. 缺少调试符号：release 模式默认剥离符号，perf report 会显示地址而非函数名，需在 Cargo.toml 中开启 debug 信息。
2. 采样开销过大：高频事件采样可能影响程序运行速度，导致数据失真，建议先小范围测试。
3. 误判泄漏：perf 显示分配多不代表泄漏，可能是缓存策略，需结合内存总量趋势判断。
4. 权限不足：默认内核配置可能禁止用户态 perf 采集，需调整 /proc/sys/kernel/perf_event_paranoid 值。
常见问题
perf 能直接找到内存泄漏吗？
不能，perf 主要记录事件频率，无法判断内存是否被释放，需配合 valgrind 或 heaptrack 使用。
Rust 程序必须用 jemalloc 吗？
不是必须，但 jemalloc 提供内置 profiling 功能，对分析内存占用比 perf 更直接，适合生产环境。
perf 记录的数据文件太大怎么办？
使用 `--count` 参数限制采样次数，或仅针对特定线程采集，避免全系统长时间记录。
参考来源
- Linux perf wiki, "perf record", https://perf.wiki.kernel.org/
- Brendan Gregg, "Linux Perf Examples", http://www.brendangregg.com/perf.html
- The Rust Programming Language, "Profiling", https://doc.rust-lang.org/book/