性能监控与调优：tegrastats工具使用、NVIDIA Nsight Systems分析、Profiling最佳实践

做嵌入式开发，尤其是Jetson平台，性能调优是绕不开的坎。我见过太多人把模型部署上去，跑起来就完事了，结果发现帧率上不去、功耗爆表。说白了，没有数据支撑的优化都是瞎猜。

今天我们就来聊聊Jetson平台上的三板斧：tegrastats、Nsight Systems，以及我这些年总结的Profiling最佳实践。这三样东西用好了，你的板子能多榨出30%的性能。

一、tegrastats：最直接的性能仪表盘

tegrastats是JetPack自带的命令行工具，没有花里胡哨的界面，但信息量巨大。我个人习惯一开终端就先跑它，就像开车前先看仪表盘一样自然。

基本用法

# 启动监控，每秒刷新一次
sudo tegrastats

# 指定刷新间隔（毫秒）
sudo tegrastats --interval 500

# 输出到文件，方便后续分析
sudo tegrastats --interval 1000 --logfile perf_log.txt

输出内容长这样：

RAM 3947/7851MB (lfb 1902MB) 
CPU [4%@1536, 6%@1536, 3%@1536, 0%@1536, 2%@1536, 1%@1536]
GPU 45%@918
AO@42C CPU@54C GPU@52C Tboard@41C Tdiode@48C
VDD_IN 4523/4523 VDD_CPU 1234/1234 VDD_GPU 2345/2345

每一列都有讲究：

• RAM：总内存/已用内存，lfb是剩余可用。我遇到过模型加载失败，一看lfb只剩200MB，果断换小batch size。
• CPU：每个核心的占用率和当前频率。注意看，Jetson的CPU频率是动态调的，不是一直跑满。
• GPU：占用率和频率。这个值如果一直低于50%，说明你的模型没把GPU喂饱。
• 温度：AO、CPU、GPU、Tboard、Tdiode。温度超过85°C就要警惕降频了。
• 功耗：VDD_IN是整板功耗，VDD_CPU和VDD_GPU是子模块的。我曾经调一个模型，发现GPU功耗只有1W，CPU功耗却飙到3W，明显是数据预处理瓶颈。

实战：定位性能瓶颈

有一次我在做视频分析项目，帧率只有15fps，离目标30fps差一半。我打开tegrastats一看：

• GPU占用率只有35%
• CPU占用率却高达80%
• 内存用了不到一半

嗯，问题很明显——CPU成了瓶颈。后来我把图像预处理从CPU挪到GPU上用CUDA做，帧率直接翻倍。你看，没有tegrastats，我可能还在盲目调模型结构。

二、NVIDIA Nsight Systems：深入内核的火焰图

tegrastats只能看宏观指标，真要分析代码级别的性能问题，得请出Nsight Systems。这工具能告诉你：时间都去哪儿了。

安装与启动

Nsight Systems有桌面版和命令行版。在Jetson上，我一般用命令行版：

# 安装（JetPack自带，如果没有就手动装）
sudo apt install nvidia-nsight-systems-cli

# 启动采集
nsys profile -o my_profile --stats=true python my_app.py

# 或者采集已经运行的进程
nsys profile --attach-to-process PID

采集完成后会生成一个.nsys-rep文件，用桌面版Nsight Systems打开就能看到时间线。

看懂时间线

打开报告后，你会看到类似这样的视图：

• CUDA API：所有CUDA函数调用，比如cudaMemcpy、cudaLaunchKernel。如果这里出现大段空白，说明CPU在等GPU。
• CUDA HW：GPU硬件上的实际执行情况。这里能看到kernel的占用率、SM利用率。
• NVTX：你自己插入的标记。我习惯在关键代码段前后加nvtxRangePush("preprocess")和nvtxRangePop()，这样时间线上一目了然。
• OS Runtime：系统调用、线程调度。如果这里出现频繁的上下文切换，说明线程数太多了。

一个真实案例

我曾经优化一个目标检测模型，用Nsight Systems一看，发现cudaMemcpy占了总时间的40%。数据从CPU传到GPU花了太多时间。后来我改用cudaMallocManaged统一内存，配合cudaMemAdvise做预取，传输时间降到了15%。

你想想看，如果没有这个工具，我可能还在傻傻地调kernel launch参数。

三、Profiling最佳实践：我的三板斧

工具再好，不会用也是白搭。下面是我这些年总结的Profiling流程，你可以直接套用。

第一板斧：先看宏观，再抓微观

不要一上来就开Nsight Systems。先用tegrastats跑5分钟，确认瓶颈在CPU、GPU还是内存带宽。我见过有人花两天调GPU kernel，结果发现瓶颈在CPU端的图像解码。

tegrastats指标	可能瓶颈	下一步动作
GPU占用率低，CPU占用率高	CPU预处理瓶颈	用Nsight Systems分析CPU热点
GPU占用率高，但帧率低	GPU kernel效率低	用Nsight Compute分析kernel
内存占用高，lfb接近0	内存不足，触发swap	减小batch size或模型量化
温度持续>85°C	热降频	加强散热或降低功耗模式

第二板斧：用NVTX标记关键路径

在代码里插入NVTX标记，能让Nsight Systems的时间线变得清晰可读。我习惯这样写：

#include <nvtx3/nvToolsExt.h>

void process_frame(cv::Mat& frame) {
    nvtxRangePushA("decode");
    // 解码逻辑
    nvtxRangePop();

    nvtxRangePushA("preprocess");
    // 预处理逻辑
    nvtxRangePop();

    nvtxRangePushA("inference");
    // 推理逻辑
    nvtxRangePop();

    nvtxRangePushA("postprocess");
    // 后处理逻辑
    nvtxRangePop();
}

这样在时间线上，每个阶段都用不同颜色标出来。哪个阶段耗时最长，一眼就能看出来。

第三板斧：建立基线，对比优化

每次优化前，先跑一次完整的Profiling，把数据保存下来。优化后再跑一次，对比差异。我习惯用这样的表格记录：

优化项	优化前帧率	优化后帧率	提升比例
CPU预处理→GPU预处理	15fps	28fps	86%
FP32→FP16推理	28fps	42fps	50%
batch size 1→4	42fps	55fps	31%

这样做的好处是，你能清楚地知道每项优化的收益，而不是凭感觉说「好像快了一点」。

四、知识体系总览

下面这张图概括了本章的核心逻辑。你可以把它当作性能调优的路线图：

这张图把整个调优流程串起来了。从左到右，从上到下，你总能找到自己当前在哪个环节。

五、写在最后

性能调优不是一锤子买卖，而是一个持续迭代的过程。我刚开始做Jetson开发时，也走过不少弯路——比如花了一周调GPU kernel，结果发现是CPU端的图像格式转换没用好硬件加速。

所以我的建议是：先让数据说话。tegrastats告诉你「是什么」，Nsight Systems告诉你「为什么」，而最佳实践告诉你「怎么办」。这三者缺一不可。

嗯，今天就聊到这里。下次你在Jetson上跑应用觉得卡顿，不妨先打开tegrastats看看，说不定问题就迎刃而解了。

---

公众号:蓝海资料掘金营，微信deep3321