发布日期：2026 年 9 月 26 日 · RootGS 技术指南
网站打开变慢，监控里的 Load Average 同时升高，是否应该立刻增加 CPU？先确认等待发生在哪里。Linux 负载既可能来自计算任务排队，也可能来自不可中断等待；数据库存储变慢、内存回收或后台备份，都可能让负载升高。一次有效排查，应把业务延迟、系统指标和具体进程放在同一时间线上，再决定调整应用、错开任务还是升级资源。
本文适用于具备系统查看权限的 Linux 云服务器或物理服务器使用者。命令以常见 procps-ng、sysstat 工具为例，均用于观察；示例数据是教学场景，不是 RootGS 套餐性能测试，也不代表当前服务器状态。
一、先确认业务受影响，再解读负载
排查开始时，记录异常出现的时间、受影响的接口、请求量、错误率和响应时间。如果已有监控，比较同一业务平时相同时段的表现。P95 响应时间表示约 95% 请求不超过该耗时，比只看平均值更容易发现一部分用户正在等待；请求量很小时，应同时查看原始请求样本。
uptime 显示的三个负载数值对应约 1、5、15 分钟尺度；它们不是 CPU 使用率。Linux 的统计包含可运行任务以及不可中断等待任务。负载要结合可用 CPU 和任务状态理解，不能把“负载大于 1”作为通用故障线。参见 Linux loadavg 手册。
例如，4 个可用逻辑 CPU 的机器出现负载 8，只能提示需要继续调查：若大量任务等待计算，增加算力可能有帮助；若任务在等磁盘，同样的负载值对应另一种处理方向。容器或受配额约束的服务，还应核对部署平台给它的实际 CPU 配额，不能直接拿整台宿主机核心数作分母。
二、用一组只读命令建立现场快照
date -Is
uptime
nproc
free -h
vmstat 1 6
ps -eo pid,comm,stat,pcpu,pmem --sort=-pcpu | head -n 16
df -h
df -i这些命令依次记录时间、负载、可用处理器数量、内存、短时系统变化、进程排序和文件系统空间。df -i 用于检查 inode；大量小文件可能耗尽 inode，即使容量仍有余量。进程列表只展示程序名，不需要把完整启动参数复制到公开工单。
vmstat 1 6 的首行 CPU、I/O 等速率通常是自启动以来的平均值，后续才是每秒采样；不要拿首行当作异常瞬间。重点看 r（可运行任务）、b（阻塞等待 I/O）、si/so（换入换出）、wa（I/O 等待）和 st（虚拟机被占用的 CPU 时间）。字段定义见 vmstat 手册。
六次采样只是起点。若问题每晚才出现，应在对应时间段连续观察，并和备份、定时任务、部署记录对齐。采样工具尚未安装时，先利用已有监控，不必为了这一步临时更改生产软件环境。
三、用指标组合缩小范围
| 同时出现的现象 | 优先调查 | 下一步证据 |
|---|---|---|
| 可运行队列持续增长，CPU 忙，业务延迟上升 | 计算并发是否超过有效算力 | 每核使用情况、热点进程、请求量与任务并发 |
| 负载高，CPU 并不忙，阻塞任务和 I/O 延迟同步上升 | 存储等待、批处理与在线业务争用 | 设备延迟、进程读写、备份及数据库任务时间 |
| 可用内存下降，换页持续发生，接口越来越慢 | 工作集超出内存预算或异常内存增长 | 进程内存趋势、容器限额、内存压力 |
| 虚拟机 st 持续偏高，业务执行时间拉长 | 虚拟化层资源调度影响 | 跨时间段重复采样、实例规格与平台侧排查 |
| 系统指标平稳，个别接口仍很慢 | 应用锁、连接池、外部依赖或网络路径 | 慢请求追踪、连接等待、下游服务耗时 |
这张表的使用方法是先寻找同时变化的指标，再用进程或应用证据验证。某项数值升高和故障同一时间出现，仍不等于已经找到了原因；例如重试流量既可能放大原有问题，也可能只是下游异常造成的结果。
四、CPU 不高时，重点补看存储和内存
如果已安装 sysstat，可以运行：
iostat -xz -y 1 5-y 跳过自启动以来的首份报告，await 反映请求平均等待与服务耗时。把它和设备吞吐、队列变化放在一起看，并和该业务健康时的基线比较。对于能并行处理请求的 SSD 或 RAID，%util 不能单独表示性能上限；低吞吐也不能排除小块随机 I/O 或同步写入的延迟瓶颈。定义与局限见 iostat 手册。
内存方面，free -h 的 available 比单看 free 更适合判断还能支撑多少新工作。Linux 会使用内存缓存文件；available 是考虑可回收内存后的估计值，不是保证。已有 Swap 占用不等于此刻正在频繁换页。相关口径见 free 手册。
实际处理时，先检查应用工作进程、数据库缓存和后台任务是否共享了过大的内存预算。增加工作进程可能暂时缩短排队，也可能让每个进程的内存叠加，最终把压力转移到存储。应先写出各服务的预算，再选择并发调整或内存扩容，不要把清理缓存当作长期性能方案。
五、用 PSI 验证任务是否真的在等待资源
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io内核启用 PSI 时，这些文件提供资源压力信息。some 表示至少有任务因该资源而停顿的时间比例；avg10、avg60、avg300 对应不同时间窗口。它衡量任务受阻程度，不是资源使用率，也不是请求失败率。系统级 CPU 的 full 不应拿来判断整机算力是否耗尽。容器还可结合自身 cgroup 压力数据。详见 Linux 内核 PSI 文档。
PSI 文件不存在或不可读时，不能据此判断“没有压力”，应退回已有系统和应用监控。告警阈值需要从自己的健康基线和业务延迟目标建立；不同请求类型、并发水平与后台任务组合，没有一个通用百分比可以替代验收。
六、一个完整示例：夜间备份与订单接口争用
以下为假设场景：某台 4 vCPU 云服务器的订单接口 P95 平时为 200 毫秒，每晚备份开始后上升到 2 秒；负载从约 2 上升到约 9，但 CPU 仍有较多空闲。排查时发现阻塞任务增加、存储延迟高于平时，I/O PSI 也同步上升。
这组现象支持“存储争用值得优先验证”，还不足以证明磁盘损坏或实例性能不足。先核对备份起止时间、备份进程读写量和数据库慢请求，并排除同一时段发布、日志归档与流量突增。若条件允许，在维护窗口调整一个变量，例如将备份移到较空闲时段，再比较相近请求量下的延迟。
调整前要确认备份完成时限和恢复要求。若错峰后在线延迟恢复、备份仍按期完成，就有理由保留这个调度方案；若压力持续，再评估存储性能、读写模式或数据服务拆分。无论最终选择哪条路径，复盘都应保存“发生时间—采样指标—采取动作—结果”四项记录，避免下次只剩一个负载截图。
验证调整效果时，至少覆盖一次原先容易出问题的高峰或备份周期，并记录请求量是否相近。若改动后负载下降，但请求量也大幅减少，不能据此认定问题已解决。每轮只调整一个主要因素，提前约定恢复原配置的条件，能减少多项改动相互掩盖的情况。
七、什么时候才应该扩容？
扩容的依据应是可复现的资源瓶颈和业务目标。计算任务持续排队，且应用能利用更多并行度时，评估增加 vCPU；工作集持续超过内存预算时，评估内存；存储等待影响关键请求时，核对存储延迟、IOPS、吞吐与套餐限制。单线程热点、应用锁或外部接口变慢，需要分别处理，增加核心数未必改善响应时间。
准备选型时，列出日常与峰值请求量、可接受延迟、数据增长、备份窗口和预计扩容方式，再对照 RootGS 香港云服务器 或 香港物理服务器 的当前产品信息。本文不承诺某个套餐可承载固定访问量；上线验收应使用自己的应用、数据规模和访问模型。
一次排查完成的标志，是业务延迟和错误率回到目标范围，关键资源在高峰仍有余量，后台任务也能按时完成。把这组结果写入运行记录，后续选型和扩容才有可比较的依据。
