📚 课程目录第3章健康检查核心指标

3、健康检查核心指标：掌握CPU使用率、内存占用、温度、重启原因等关键指标的定义和意义

Edge AI设备的健康检查，本质上是对设备运行状态的一次系统性“体检”。与云端服务器不同，Edge设备往往部署在无人值守的机房、工厂产线、户外杆站或车载环境中，其计算资源受限、散热条件苛刻、供电环境复杂。因此，健康检查的核心指标必须围绕“计算负载、存储压力、热稳定性、异常恢复”四个维度展开。本章将深入剖析CPU使用率、内存占用、温度、重启原因这四类关键指标的定义、采集方法、判读标准及其在工程实践中的联动意义，帮助学员建立从“看到数字”到“读懂设备”的完整认知链路。

上图展示了Edge AI设备健康检查中四大核心指标的联动关系。在实际运维中，这些指标并非孤立存在，而是相互影响、互为因果。例如，CPU使用率长期过高会直接导致SoC温度上升，而温度超过阈值又可能触发内核热保护机制导致设备重启。因此，掌握单个指标的定义只是第一步，理解它们之间的耦合关系才是精准诊断的关键。

3.1 CPU使用率：计算负载的晴雨表

核心原理

CPU使用率反映的是处理器在单位时间内执行非空闲任务的时间占比。对于Edge AI设备而言，CPU负载主要来自推理计算（如TensorFlow Lite、ONNX Runtime）、图像预处理、传感器数据解析以及通信协议栈。与通用服务器不同，Edge设备的CPU往往采用大小核架构（如ARM big.LITTLE），且可能集成NPU（神经网络处理单元）或GPU。因此，单纯看整体CPU使用率会掩盖异构计算单元的真实负载。例如，一个视觉检测设备可能CPU整体使用率只有40%，但NPU已经满载，此时系统吞吐量依然受限。

判断方法与操作流程

在Linux系统下，推荐使用以下命令组合进行CPU健康检查：

# 实时查看CPU整体及每核使用率
top -d 2 -n 3

# 按CPU核心维度查看，识别单核过载
mpstat -P ALL 2 3

# 查看进程级CPU占用，定位异常进程
pidstat -u 2 5

# 查看上下文切换和运行队列长度（判断是否过载）
vmstat 2 5

判读标准建议如下表所示：

指标项	健康区间	警戒区间	危险区间
整体CPU使用率（持续5分钟）	< 50%	50% - 70%	> 70%
单核使用率峰值	< 80%	80% - 90%	> 90%
运行队列长度（r值）	< CPU核数	= CPU核数	> CPU核数×1.5
上下文切换次数/秒	< 5000	5000 - 10000	> 10000

经验提醒：对于Edge设备，建议采集CPU使用率时同时记录时间戳和对应的工作负载场景（如白天检测、夜间待机）。因为很多设备存在明显的潮汐负载特征，仅看平均值会掩盖高峰期的过载风险。

案例拆解：产线质检设备的CPU异常飙升

某汽车零部件产线部署了20台基于Jetson Nano的视觉质检设备，用于检测螺栓安装是否到位。某日运维人员发现其中3台设备CPU使用率从正常的35%飙升至95%，且持续不降。初步排查发现，这3台设备均运行着同一版本的推理模型。通过pidstat定位到是inference_engine进程占用CPU过高。进一步分析发现，该版本模型在输入图像分辨率从640×480升级到1280×720后，预处理阶段的OpenCV缩放操作变成了CPU密集型任务，而NPU并未参与该环节。解决方案是将图像缩放操作迁移到GPU上执行（通过CUDA加速），并将预处理线程优先级降低。调整后CPU使用率回落至42%，且检测节拍从原来的12帧/秒提升至18帧/秒。复盘经验：CPU使用率异常时，不仅要看占用率数字，还要区分是用户态计算、内核态中断还是IO等待，不同场景的优化方向截然不同。

3.2 内存占用：稳定性的隐形杀手

核心原理

内存占用指标包括物理内存使用量、Swap交换空间使用量以及内存页的分配速率。Edge设备通常采用LPDDR4或LPDDR5内存，容量从1GB到8GB不等，且没有像服务器那样充裕的磁盘Swap空间（很多嵌入式系统甚至关闭了Swap）。内存问题最典型的表现是“泄漏”——即进程申请内存后未正确释放，导致可用内存逐渐减少，最终触发OOM（Out Of Memory） Killer，系统随机杀死进程或直接重启。此外，内存碎片化也会导致大块连续内存分配失败，影响DMA（直接内存访问）操作。

判断方法与操作流程

# 查看内存总量、已用、可用及Swap
free -h

# 查看进程级内存占用TOP10
top -o %MEM -n 1

# 监控内存增长趋势（每10秒采样，持续1小时）
for i in $(seq 1 360); do free -m | grep Mem | awk '{print strftime("%H:%M:%S"), $3}' >> mem_log.txt; sleep 10; done

# 查看OOM事件记录
dmesg | grep -i "out of memory"

内存健康判读要点：

可用内存比例：建议始终保留至少20%的可用物理内存，低于此值系统开始出现性能抖动。
Swap使用率：如果Swap使用率持续大于0且不断增长，说明物理内存已不足，必须介入。
内存增长斜率：在固定负载下，如果内存占用每小时增长超过2%，则高度怀疑存在泄漏。
OOM Killer触发频率：任何一次OOM事件都应视为严重事故，需要立即定位。

风险提示：很多Edge设备使用overlayfs或tmpfs作为日志存储，这些文件系统会占用内存空间。如果日志量过大，会导致可用内存急剧减少，且不易被常规内存监控发现。建议将日志目录挂载到外部存储或设置logrotate轮转策略。

案例拆解：智能门禁设备的内存泄漏排查

某智慧社区部署了500台人脸识别门禁机，设备内存为2GB。运行约3周后，部分设备出现响应缓慢、人脸识别失败率升高的问题。远程SSH登录后执行free -h发现可用内存仅剩120MB，Swap使用率高达85%。通过top -o %MEM定位到face_algorithm进程占用内存1.2GB。进一步使用valgrind --leak-check=full（在测试环境复现）发现，算法库在每次人脸特征提取时都会分配一个2MB的临时缓冲区，但仅在识别成功时才释放，识别失败时（如光线不佳）则跳过释放逻辑。修复该问题后，设备连续运行60天内存占用稳定在800MB左右。复盘经验：内存泄漏的排查必须结合业务场景（识别失败路径）进行压力测试，单纯的功能测试很难暴露此类问题。

3.3 温度：硬件寿命的“折寿因子”

核心原理

温度是影响半导体器件可靠性的首要物理因素。根据阿伦尼乌斯方程，温度每升高10°C，电子迁移率加快，电迁移失效概率约翻倍。Edge设备的温度监测点通常包括：SoC内部结温（Tj）、外壳表面温度、环境温度以及关键电源芯片温度。Linux内核通过thermal_zone接口暴露温度值，用户空间可通过sysfs读取。温度过高会触发降频（Throttling）、风扇加速或直接热关机。对于无风扇的被动散热设备，温度管理更为关键。

判断方法与操作流程

# 查看所有thermal zone温度
cat /sys/class/thermal/thermal_zone*/temp

# 查看当前CPU频率及调频策略
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# 持续监控温度变化曲线（每5秒采样）
while true; do cat /sys/class/thermal/thermal_zone0/temp; sleep 5; done

温度判读标准（以典型工业级SoC为例）：

温度区间	状态	建议动作
< 60°C	健康	无需干预
60°C - 75°C	关注	检查散热风道、环境温度
75°C - 85°C	警戒	检查是否降频，评估负载是否合理
> 85°C	危险	立即降载或停机，防止永久损伤

关键认知：温度指标必须结合“温升速率”和“稳态温度”两个维度分析。如果设备在30秒内温度上升20°C，即使当前温度只有70°C，也说明散热系统存在严重问题（如风扇停转、导热硅脂干涸）。

案例拆解：户外广告机夏季高温重启

某户外广告机采用RK3588平台，外壳为铝合金密闭结构，被动散热。夏季中午阳光直射时，设备频繁重启。通过日志发现重启前SoC温度达到92°C，触发了内核热保护。现场实测环境温度45°C，外壳表面温度高达68°C。分析发现，设备虽然设计了散热鳍片，但安装位置处于广告牌背面，空气流通极差。解决方案分三步：第一，在散热鳍片外侧增加遮阳罩，避免阳光直射；第二，在设备底部增加两个5V/0.2A的微型风扇，强制对流；第三，在软件层面将CPU最高频率从1.8GHz限制到1.5GHz，并开启GPU的DVFS（动态电压频率调整）。改造后，在同样环境温度下，SoC温度稳定在78°C，不再触发重启。复盘经验：温度问题的解决不能只靠软件降频，必须从热设计源头（散热路径、风道、辐射面积）进行系统性优化。

3.4 重启原因：异常事件的“黑匣子”

核心原理

重启原因分析是健康检查中最具诊断价值的一环。Edge设备的重启可分为三类：主动重启（如OTA升级、运维人员手动reboot）、被动重启（如看门狗超时、内核Panic、硬件看门狗触发）、异常断电重启（如供电不稳、电池耗尽）。Linux系统通过多种机制记录重启原因：last reboot记录系统启动时间；dmesg或pstore（持久化存储）保存内核Panic信息；systemd的journalctl --list-boots可查看每次启动的日志边界。对于嵌入式设备，还需要检查PMIC（电源管理芯片）的中断寄存器，以区分是软件复位还是电源复位。

判断方法与操作流程

# 查看系统启动历史记录
last reboot | head -20

# 查看内核环形缓冲区中的重启前日志（需pstore支持）
ls /sys/fs/pstore/
cat /sys/fs/pstore/console-ramoops*

# 查看systemd管理的启动记录
journalctl --list-boots --no-pager

# 查看硬件看门狗状态（如果有）
ls /dev/watchdog*
cat /proc/sys/kernel/watchdog

重启原因分类判断表：

现象特征	可能原因	确认方法
重启前无任何日志，时间戳跳变	硬件看门狗复位或电源瞬断	检查PMIC寄存器、电源输入波形
dmesg中有“Kernel panic - not syncing”	内核致命错误	分析panic调用栈，定位驱动或文件系统
重启前温度日志显示超过阈值	热保护触发	确认thermal_zone的trip_point设置
重启时间固定（如每天凌晨3点）	定时任务或RTC唤醒异常	检查crontab、systemd timer
重启后文件系统损坏	异常断电导致数据未同步	检查ext4/f2fs日志，启用journal

重要提醒：很多Edge设备默认未开启pstore（持久化ramoops），导致内核Panic信息在重启后丢失。建议在bootloader（如U-Boot）中预留内存区域，并在内核cmdline中添加ramoops.mem_address=0x... ramoops.mem_size=0x10000，确保异常信息可追溯。

案例拆解：充电桩控制器的神秘重启

某电动汽车充电桩控制器（基于i.MX6ULL）在充电过程中偶发重启，每天约1-2次，无固定规律。通过last reboot发现重启时间与充电开始时间高度相关。检查dmesg未发现Panic信息，但发现重启前有“Under-voltage detected”警告。进一步使用示波器监测12V输入电源，发现当充电枪插入瞬间，由于继电器吸合，电源电压跌落至9.8V，持续约80ms，超出了PMIC的欠压复位阈值。解决方案是在电源输入端增加一个4700μF的电解电容和TVS管，同时将PMIC的欠压复位阈值从10.5V调整到9.0V（通过配置PMIC寄存器）。改造后连续运行30天无重启。复盘经验：对于涉及大功率负载切换的Edge设备，电源跌落是重启的首要嫌疑，必须用示波器实测电源波形，而不能仅依赖软件日志。

3.5 指标联动与综合判读

在实际运维中，单一指标异常往往不足以定位根因，需要将四类指标进行时间对齐和关联分析。以下是一个典型的联动判读流程：

时间对齐：将CPU、内存、温度、重启事件统一到同一时间轴，以秒级精度对齐。
因果链分析：例如“CPU高→温度高→重启”，还是“内存泄漏→OOM→重启”，还是“电源跌落→重启→文件系统损坏→CPU高（恢复时）”。
趋势对比：对比设备正常运行时段的基线数据，识别偏离程度。
跨设备横向对比：同型号设备在相同负载下，如果某台设备温度明显偏高，则大概率存在个体散热装配问题。

核心总结：CPU使用率回答“设备是否在忙”，内存占用回答“设备是否还有余量”，温度回答“设备是否在安全边界内”，重启原因回答“设备是否经历过异常”。四者结合，才能完整刻画一台Edge AI设备的健康画像。建议运维团队建立“指标基线库”，在设备上线初期记录正常负载下的各项指标范围，后续健康检查以此基线为参照，偏差超过20%即触发预警。

最后需要强调的是，健康检查不是一次性的动作，而是持续性的闭环过程。每次检查后应更新基线数据，将异常事件的处理经验沉淀为规则库，逐步实现从“人工巡检”到“智能预警”的演进。本章所讲的四个核心指标，正是构建这一闭环的基石。