CPU 占用 100%

“概览”标签页中 CPU 图表出现平台期本身并不是紧急情况：构建项目或创建压缩包确实会占满所有核心，随后再释放。真正值得警惕的是平台期持续数小时，且机器不再响应。下面我们来排查问题根源。

第 1 步：查看是什么在占用资源

“屏幕”（VNC）标签页适合操作全屏程序：

btop
htop

串口控制台不传递窗口尺寸，始终为 80×24，因此界面会被截断。对于文本控制台，请使用标准命令：

top -b -n1 | head -20
ps aux --sort=-%cpu | head -10

请记住换算关系：%CPU 按单个核心计算。VDS-3 上的 400% 表示全部四个核心，而 VDS-4 上的 100% 只是六个核心中的一个。

第 2 步：区分 CPU 与磁盘

平均负载（load average）不仅会因计算而升高，也会因 I/O 等待而升高：

uptime
vmstat 1 5

在 vmstat 输出中，请关注 us（用户代码）、sy（内核）、wa（磁盘等待）和 st（被抢占时间）这几列。wa 数值较大说明 CPU 在空等磁盘——瓶颈是写入速度，而不是计算。我们各档位的磁盘平台期由一条规则决定：每核心写入 60 MB/s，不低于 60 且不高于 400 MB/s，读取速度为其两倍，超出平台期三倍的突发可持续 30 秒。如果任务持续写入，突发额度用完后就会触及平台期。

第 3 步：排查具体进程

pidstat -p <pid> 1 5
cat /proc/<pid>/status
journalctl -u <service> -n 100 --no-pager

常见情况：

• Web 应用在请求失败后陷入死循环；
• 数据库正在执行没有索引的查询——请查看其自身的慢查询日志；
• cron 任务的启动频率高于其完成速度，导致实例不断累积：ps aux | grep <name> 会显示十几个副本；
• 挖矿程序通过弱 root 密码进入了机器。其特征是以非标准用户身份运行、名称毫无意义的进程，以及较高的出站带宽。这种情况下，从“访问”标签页重装机器比清理更省事。

第 4 步：限制，而不是杀死

如果进程是必需的，但不该干扰其他任务：

renice -n 15 -p <pid>
systemctl set-property myapp.service CPUQuota=200%

CPUQuota=200% 表示两个完整核心。systemd 的限制在服务重启后依然有效；renice 则不会。

在用 kill -9 杀死进程之前，请先尝试常规的 systemctl stop。强制杀死数据库会导致文件损坏，并在下次启动时耗费漫长的恢复时间。

当问题不在代码时

如果负载是合理且持续的，说明 Ryzen 9 7950X CPU 已在全力工作——只是核心数量不足以完成任务。档位只能向上变更，并需为已付费周期的剩余天数补差价：请参阅文章升级套餐并支付差价。不支持降回原档位，因此请先通过周和月图表确认平台期并非一次性现象。