NPU开发中的资源监控：top与htop实战指南-嵌云网-嵌入式AI开发资源站

NPU开发中的资源监控：top与htop实战指南

唔叽哩

1. 理解资源监控在NPU开发中的核心价值

在嵌入式AI开发领域，我们常常过于关注算法精度和推理速度，却忽视了系统资源的合理分配。就像赛车手不能只盯着速度表，还需要时刻监控油压、水温等关键指标。对于NPU开发者而言，top和htop就是我们的"驾驶舱仪表盘"。

我曾参与过一个智能摄像头的项目，团队在NPU上实现了人脸检测算法后，发现虽然处理速度提升了3倍，但系统整体响应却变慢了。通过top工具排查，发现CPU负载长期维持在90%以上。原来NPU虽然承担了计算任务，但数据搬运和结果后处理仍然消耗了大量CPU资源。这个教训让我深刻认识到：真正的性能优化必须是端到端的。

2. 工具选型与基础配置

2.1 top与htop的对比选择

标准的top工具是Linux系统的"常驻居民"，无需额外安装。但如果你和我一样喜欢更直观的界面，htop绝对是更好的选择：

bash复制sudo apt install htop  # Debian/Ubuntu
sudo yum install htop  # CentOS/RHEL

两者的核心差异：

可视化：htop用彩色条形图显示CPU/内存占用，支持鼠标操作
交互性：htop可以直接杀死进程或调整进程优先级
信息密度：htop默认显示完整的命令行，方便识别进程

提示：在生产环境中，如果系统资源紧张，建议使用原生top，因为htop本身会消耗更多资源。

2.2 关键指标解读

第一次打开top时，那些跳动的数字可能会让人困惑。以下是需要特别关注的指标：

指标名称	含义	健康范围	NPU开发关注点
%CPU	进程CPU占用率	<70% (单核)	NPU程序应显著低于CPU版本
%MEM	内存占用比例	<80%	防止内存交换影响性能
RES	常驻内存大小	-	监控内存泄漏
SHR	共享内存大小	-	评估多进程效率
S	进程状态	R(运行)/S(睡眠)	检查是否阻塞

在NPU开发场景中，我们最关心的是%CPU变化。一个设计良好的NPU程序应该表现出"低CPU占用+高NPU利用率"的特征。

3. 实战：监控NPU边缘检测程序

3.1 基准测试准备

假设我们有一个Sobel边缘检测程序，分别实现了CPU和NPU版本。为了获得准确数据，我们需要：

关闭不必要的后台进程

设置性能模式（防止CPU降频）

bash复制sudo cpupower frequency-set -g performance

预热NPU（首次调用会有初始化开销）
准备测试图片集

3.2 监控CPU版本

在终端1运行CPU版本：

bash复制./sobel_cpu test_images/

在终端2启动htop，按F2进入设置，确保显示以下列：

PID
USER
PRI
NI
VIRT
RES
SHR
S
%CPU
%MEM
TIME+
COMMAND

观察到的典型现象：

单个进程CPU占用可能达到100%（单核满载）
多线程版本会分散到多个核心
内存占用相对稳定

3.3 监控NPU版本

在终端1运行NPU版本：

bash复制./sobel_npu test_images/

此时htop应该显示：

CPU占用显著下降（理想情况<10%）
出现NPU相关的内核进程（如kmd）
可能出现短暂的内存峰值（数据搬运）

注意：部分NPU SDK会创建守护进程，这些进程的CPU占用也应计入总成本。

3.4 数据记录技巧

为了量化对比，我习惯使用batch mode记录数据：

bash复制top -b -d 2 -n 5 > cpu_usage.log

参数说明：

-b：批处理模式
-d 2：每2秒采样一次
-n 5：共采样5次

然后用awk提取关键数据：

bash复制awk '/sobel_/ {print $1,$9,$10}' cpu_usage.log

4. 高级技巧与问题排查

4.1 线程级监控

默认top只显示进程信息。要查看线程：

在top运行时按H键
或使用-H参数：
```
bash复制top -H -p $(pgrep sobel_npu)
```

这对于分析多线程程序的负载均衡特别有用。我曾遇到过一个案例，由于任务划分不均，导致NPU的DMA线程长期阻塞，表面看CPU占用很低，实际性能却很差。

4.2 结合NPU利用率工具

各厂商NPU通常提供专用监控工具，如：

华为Ascend的npu-smi
瑞芯微的rknn_server
寒武纪的cnmon

需要将NPU利用率与CPU占用关联分析。一个健康的系统应该呈现：

code复制CPU占用: 10% | NPU利用率: 85% → 理想状态
CPU占用: 80% | NPU利用率: 20% → 可能存在瓶颈

4.3 常见问题排查

问题1：NPU程序CPU占用仍然很高

检查是否启用了硬件加速（有时链接错误会fallback到CPU）
分析调用栈（perf top -p <pid>）
确认数据预处理/后处理没有成为瓶颈

问题2：系统整体变卡顿

检查%sys是否过高（可能内核驱动有问题）
监控上下文切换次数（vmstat 1）
查看IO等待（%wa）

问题3：内存持续增长

使用smem工具分析内存分布
检查NPU是否缓存了过多中间结果
确认模型内存是否正确释放

5. 自动化监控方案

对于长期运行的应用，我推荐以下方案：

5.1 使用sar进行历史记录

bash复制sudo apt install sysstat
sudo sed -i 's/false/true/' /etc/default/sysstat
sudo systemctl restart sysstat

数据存储在/var/log/sysstat/，可以用sadf解析。

5.2 自定义监控脚本

bash复制#!/bin/bash
while true; do
    timestamp=$(date +%s)
    cpu_usage=$(top -b -n 1 -p $(pgrep sobel_npu) | awk '/sobel_npu/ {print $9}')
    npu_usage=$(npu-smi info | awk '/Utilization/ {print $3}')
    echo "$timestamp,$cpu_usage,$npu_usage" >> monitor.csv
    sleep 5
done

5.3 可视化分析

将数据导入Grafana或Excel，绘制CPU/NPU利用率曲线，可以清晰看到：

负载均衡情况
突发流量处理能力
长期运行稳定性

我在一个智慧交通项目中，通过这种可视化发现了NPU利用率夜间异常升高的问题，最终定位到是路灯切换导致的图像亮度变化，触发了不同的计算路径。