外观
CPU 或负载居高不下
适用范围
- 仪表盘或性能统计里，CPU 或平均负载长时间很高。
- 在 shell 里
top、uptime显示负载很高，风扇一直在响，界面变得卡顿。 - 收到 OMV 的邮件告警：「监测 - 平均负载」「监测 - CPU 使用量」「监测 - 内存使用量」。
不适用：只是某次文件传输慢，见SMB 传输慢；硬盘一直在转，见硬盘不休眠。
开始排查前
先分清两个概念：
- CPU 使用率：CPU 有多少时间在干活。
- 平均负载（load average）：正在运行、或排队等待运行的任务数，也包括正在等磁盘 I/O 的任务。
所以：负载高但 CPU 其实空闲，多半是在等磁盘；负载高并且 CPU 也高，才是有进程在占 CPU。负载要和 CPU 核心数对比，负载在核数以内，通常说明机器没有排队。
OMV 默认的监控告警阈值（每 30 秒检查一次）：5 分钟平均负载大于核数持续 3 个周期，1 分钟平均负载大于核数的 2 倍持续 3 个周期，内存使用率超过 90%，CPU 的用户、系统或 I/O 等待占用超过 95% 连续 2 个周期。这些告警需要邮件通知可用，并且「监测」类的通知项是开启的（默认开启）。
短时间的高负载往往是正常的：刚开机、刚更新完、RAID 正在检查、媒体库在扫描。要关注的是长时间不降的情况。本页的检查都是只读的。
排查步骤
1. 在界面里看趋势
诊断 → 性能统计（Diagnostics → Performance Statistics）里有 CPU、平均负载、内存用量的历史图，前提是 系统 → 监测（System → Monitoring）是开着的（默认开启）。看高峰是不是总出现在固定的时间点，比如夜里，那往往是计划任务。
诊断 → 进程（Diagnostics → Processes）页面显示当前的负载、任务数、内存，以及按 CPU 排序的进程列表，每 5 秒刷新一次。
2. 在 shell 里看实时情况
sh
# 在 OMV 的 shell 里执行（只读）；top 看完按 q 退出
uptime
nproc
topuptime末尾的三个数字是 1、5、15 分钟平均负载，nproc是 CPU 核数。top里按P按 CPU 排序，按M按内存排序。顶部 CPU 一行里：us是用户程序，sy是内核，wa是等待 I/O，id是空闲。
3. 判断是哪一类
top 里看到 | 说明 | 下一步 |
|---|---|---|
us 高，某个进程的 CPU 很高 | 这个进程在占 CPU | 第 4 节 |
sy 高 | 内核在忙：网络、文件系统、加密 | 第 4、5 节 |
wa 高，负载高而 CPU 空闲 | 在等磁盘 | 第 5 节 |
内存几乎用满，kswapd0 占 CPU | 内存不足 | 第 6 节 |
| 各项都不高，但机器发热、风扇响 | 不是负载问题，是 CPU 频率策略或散热 | 见下面的说明 |
关于最后一种：先看 系统 → 电源管理 → 设置（System → Power Management → Settings）里的 CPU 频率调节（CPU frequency scaling）。选了 performance 时 CPU 会长期保持在高频，功耗和发热更大。8.1.0 起这一项就在界面里改，8.0.9 那时用的环境变量 OMV_CPUPOWER_GOVERNOR 已经不再生效。各调节器的区别见低功耗与静音。
4. 常见的 CPU 大户
| 进程 | 是什么 | 怎么处理 |
|---|---|---|
smbd | 正在传输文件，或开启了加密、审计 | 见SMB 传输慢 |
dockerd、容器里的进程（jellyfin、ffmpeg、postgres、各种 immich 组件等） | 容器在转码、做机器学习、跑数据库、扫描媒体库 | docker stats --no-stream，或 服务 → Compose → 统计（Stats）页；限制资源或错开时间 |
md0_resync 一类的 md* 进程 | 软件 RAID 在重建、同步或检查 | cat /proc/mdstat 看进度，等它完成。OMV 保留了 Debian 的定期阵列检查（AUTOCHECK=true） |
btrfs 相关进程 | Btrfs 在校验或整理 | 见Btrfs 维护：scrub、balance 与换盘 |
clamd、clamscan | ClamAV 在扫描 | 调整扫描计划，或关闭实时扫描 |
rsync、borg、restic | 备份任务 | 在 系统 → 计划任务（System → Scheduled Tasks）里看执行时间，见计划任务 |
systemd-journald、rsyslogd | 日志刷屏 | 用 journalctl -n 100 看是哪个服务在反复报错 |
php-fpm、omv-engined、nginx | OMV 自己的界面 | 平时很低。持续很高就看日志，并检查有没有浏览器标签页一直开着在自动刷新 |
5. 在等磁盘（wa 高）
sh
# 在 OMV 的 shell 里执行（只读）
ps -eo pid,stat,comm | awk '$2 ~ /^D/'
cat /proc/mdstat
dmesg -T | tail -n 30- 第一条列出处于
D状态（不可中断睡眠，通常就是在等 I/O）的进程。一直有进程停在D状态，就说明磁盘或存储路径有问题。 - 内核日志里有
I/O error、blocked for more than 120 seconds一类的信息：磁盘、数据线或阵列出了问题，见磁盘或文件系统不见了、RAID 降级，并检查 SMART。 - 远程挂载的 NFS、SMB 目录，对端不可达时，访问它的进程也会卡在
D状态。 - SMR 盘持续写入、阵列重建、Btrfs 校验，都会让磁盘长时间忙碌，见数据盘怎么选：CMR、SMR 与 NAS 盘。
6. 内存不足
sh
# 在 OMV 的 shell 里执行（只读）
free -h
journalctl -k -b --no-pager | grep -iE 'out of memory|oom'- 官方给出的最低内存是 1 GiB，新手建议至少 4 GiB。跑容器、用 ZFS 的机器需要更多。ZFS 会把大量内存当作 ARC 缓存，这是它的正常行为，见ZFS 插件。
- 日志里有
Out of memory的记录，说明系统已经杀过进程，被杀的常常是容器里的应用，对应容器的状态是Exited (137)。 - 用
docker stats --no-stream找出最吃内存的容器，调整它们，或者增加内存。
7. 处理原则
- 不要直接
kill -9系统进程。容器用 Compose 的停止，计划任务调整执行时间。 - RAID 重建、Btrfs 校验这类维护任务，让它跑完，中途打断通常要从头再来。
- 高峰来自备份或杀毒的，把计划错开，不要都挤在同一时间。
确认恢复
uptime里 5 分钟和 15 分钟平均负载回落到与核数相当的水平。诊断 → 性能统计的图表曲线回落，之前的高峰不再出现。- 没有新的 OMV 告警邮件，界面操作不再卡顿。
仍未解决
附上：uptime、nproc、top -b -n 1 | head -n 20、free -h、cat /proc/mdstat、docker stats --no-stream、dmesg -T | tail -n 50 的输出，性能统计图的截图，以及问题开始前做过的改动。读如何有效求助。
参考资料
- OMV 8 更新记录：8.0.9 的 CPU 调频策略默认值与 8.1.0 改为界面设置，见OMV 8.0 Synchrony与OMV 8.1–8.5 更新要点
- 本站：仪表盘、系统信息与性能统计、硬件要求：最低配置与推荐配置