3、基础命令与监控：dmesg、top、free、vmstat、iostat 等系统监控命令的使用与解读
做瑞芯微平台稳定性测试，说白了就是跟这几个命令打交道。我刚开始接触RK3588时，总觉得压力测试就是跑个分，后来发现真正的问题往往藏在系统日志和资源监控里。今天咱们就把这几个看家本领捋一遍。
3.1 dmesg：系统日志的“第一现场”
dmesg 命令，我个人习惯叫它“系统日记本”。内核启动、驱动加载、硬件报错，全记在这里。做压力测试时，这是第一个要盯住的窗口。
核心用法：
# 查看所有内核日志
dmesg
# 实时监控新日志（类似 tail -f）
dmesg -w
# 只看错误和警告
dmesg -l err,warn
# 清空日志（测试前建议做一次）
dmesg -c我在项目中遇到过一件事：RK3566 跑 4K 视频解码，半小时后画面卡死。用 dmesg -w 实时盯着，发现每隔几分钟就蹦出一条 vpu: firmware timeout。嗯，这就是 VPU 固件超时了，后来调整了电压才解决。
我的习惯：每次开始压力测试前，先执行 dmesg -c 清空日志。这样测试过程中出现的新问题一目了然，不会被旧日志淹没。
3.2 top：进程的“实时体检报告”
top 命令，说白了就是看哪个进程在“吃”CPU。在瑞芯微平台上，我特别关注 %CPU 和 %MEM 这两列。
常用操作：
# 启动 top
top
# 按 CPU 使用率排序（默认就是）
# 按内存使用率排序
M
# 显示每个 CPU 核心的负载
1
# 只看某个进程
top -p PID你想想看，如果某个进程的 CPU 占用率一直 100%，而它又不是你的测试程序，那八成是驱动有问题。我曾经在 RK3399 上遇到 irq/142-mmc0 这个内核线程吃掉 30% CPU，查了半天发现是 SD 卡驱动的中断处理写得有问题。
注意：top 显示的 CPU 占用率是累加值。多核处理器上，一个进程占满一个核，显示的是 100%。如果 8 个核全占满，显示 800%。别被数字吓到。
3.3 free：内存的“水位线”
内存泄漏是嵌入式系统的常见病。free 命令能快速告诉你内存还剩多少。但要注意，Linux 的内存管理机制会让“可用内存”看起来比实际少。
关键参数：
# 以 MB 为单位显示
free -m
# 以 GB 为单位显示
free -g
# 持续监控（每 2 秒刷新一次）
free -s 2看输出时，我主要关注 available 这一列。它才是真正可用的内存，包括可以回收的缓存和缓冲区。举个例子：
total used free shared buff/cache available
Mem: 7825 3200 800 200 3825 4200这里 free 只有 800MB，但 available 有 4200MB。嗯，别慌，系统只是把内存拿去当缓存了，需要时会释放出来。
避坑指南：我曾经在 RK3288 上做 72 小时压力测试，每隔 1 小时记录一次 free -m 的 available 值。如果这个值持续下降且不反弹，基本可以断定有内存泄漏。用脚本自动记录，省心省力。
3.4 vmstat：系统瓶颈的“X光机”
vmstat 能同时看 CPU、内存、IO 三个维度的数据。我个人觉得它是性价比最高的监控命令——一行输出，信息量巨大。
标准用法：
# 每 2 秒输出一次，共输出 5 次
vmstat 2 5输出示例：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 420000 12000 380000 0 0 10 20 100 200 5 3 90 2 0我重点看这几列：
- r（运行队列）：如果这个值长期大于 CPU 核心数，说明 CPU 不够用了。
- si/so（swap in/out）：这两个值不为 0，说明内存不够，在频繁换页。嵌入式设备上出现这个，基本可以判死刑了。
- wa（IO等待）：超过 30% 就要警惕，可能是存储性能瓶颈。
我记得有一次调试 RK3588 的 NVMe 驱动，wa 值飙到 60%，系统卡得不行。后来发现是 PCIe 链路协商出了问题，速率只有 Gen1。
3.5 iostat：存储性能的“秒表”
做压力测试时，存储往往是第一个扛不住的。iostat 能精确告诉你磁盘的读写速度、IOPS 和等待时间。
常用参数：
# 安装（Debian/Ubuntu）
apt install sysstat
# 每 2 秒输出一次，只看设备信息
iostat -x 2
# 只看某个设备
iostat -x sda 2输出中我重点关注：
- %util：磁盘利用率。接近 100% 说明磁盘已经满负荷了。
- await：平均 IO 等待时间（毫秒）。超过 100ms 就太慢了。
- svctm：服务时间。如果这个值远小于 await，说明 IO 在排队。
注意：eMMC 和 NVMe 的 IO 特性完全不同。eMMC 的随机写性能很差，iostat 上会看到 await 很高。这不是故障，是硬件特性。做压力测试时，要针对不同存储介质设置不同的阈值。
3.6 实战：组合监控脚本
光会单个命令不够，得把它们串起来用。我写了个简单的监控脚本，做压力测试时必开：
#!/bin/bash
# 瑞芯微平台压力测试监控脚本
# 保存为 monitor.sh
LOG_DIR="/data/monitor_logs"
mkdir -p $LOG_DIR
# 记录开始时间
echo "=== 监控开始：$(date) ===" >> $LOG_DIR/summary.log
# 后台启动各个监控
dmesg -w >> $LOG_DIR/dmesg.log &
DMESG_PID=$!
# 每 5 秒记录一次系统状态
while true; do
echo "=== $(date) ===" >> $LOG_DIR/top.log
top -b -n 1 | head -20 >> $LOG_DIR/top.log
echo "=== $(date) ===" >> $LOG_DIR/memory.log
free -m >> $LOG_DIR/memory.log
echo "=== $(date) ===" >> $LOG_DIR/vmstat.log
vmstat 1 1 | tail -1 >> $LOG_DIR/vmstat.log
echo "=== $(date) ===" >> $LOG_DIR/iostat.log
iostat -x 1 1 | tail -3 >> $LOG_DIR/iostat.log
sleep 5
done
# 测试结束后，清理后台进程
kill $DMESG_PID使用建议：把这个脚本放在后台运行，然后开始你的压力测试。测试结束后，查看 dmesg.log 里有没有错误，memory.log 里内存有没有持续下降。我曾经用这个脚本抓到过一个很隐蔽的 DMA 内存泄漏，驱动每次申请 4KB 但只释放 2KB，跑了 12 小时才暴露出来。
3.7 总结
这几个命令，说白了就是你的“五感”。dmesg 是耳朵，听系统有没有报错；top 是眼睛，看谁在吃资源；free 是体温计，量内存够不够；vmstat 是 X 光，看内部瓶颈；iostat 是秒表，测存储性能。
做瑞芯微平台稳定性测试，别一上来就跑分。先开监控，再跑压力。发现问题，定位问题，解决问题——这才是实战该有的节奏。