美国服务器性能下降时，最容易造成二次故障的做法，是看到 CPU 使用率高就加核、看到磁盘忙就直接换盘。升级先后取决于哪个资源持续限制了业务请求，而不是哪项监控数字最大。如果业务进程受 CPU 配额限制，先提高配额或核对实例规格；如果可用内存不足并伴随持续换页、OOM，优先处理内存；如果请求主要在等磁盘读写，优先处理对应存储；只有确认服务器网卡、实例带宽或业务链路受限，才考虑网络升级。多项资源同时告急时，先排除容量耗尽、进程被杀等会直接中断服务的问题，再处理决定响应时间的主瓶颈。

开始检查前，准备同一业务的正常时段与故障时段监控、应用响应时间和错误率、实例当前资源配额，以及近期发布和定时任务记录。确认是否有维护窗口、可用备份和原规格恢复路径；尚未取得这些条件时，先做只读采样，不急于变更。以下命令适用于具备相应工具的 Linux 服务器；容器内看到的指标可能只覆盖容器，需同时核对宿主机和进程所在资源组。

先确定“需要升级”的判断标准

验收性能升级，不能只看资源利用率下降。应在相近的请求量、请求类型和测试来源下，同时看到业务响应时间、错误率改善，且原瓶颈指标不再持续恶化。单次峰值、开机以来的累计计数，或不同时间段的两张监控截图，都不足以决定升级方向。

这里的“持续”应由业务周期定义：至少覆盖问题出现前、出现时和恢复后的连续样本，并与正常时段对照。不同实例、存储和业务的上限并不相同，不宜套用一个通用利用率阈值。

按顺序采样，找出限制请求的环节

1. 固定测试口径，留下变更前基线

记录采样时间及其时区、美国服务器实例标识、操作系统、业务版本、流量规模、主要请求类型，以及监控来自宿主机、虚拟机还是容器。若问题只在访问端出现，还要记录测试节点所在网络、目标地址、测试方法和测试持续时间。高峰与低峰、不同访问节点的结果应分开保存，不混成一个平均值。

先在故障时段运行只读命令；正常时段用同一套命令再采一次。以下命令不会主动压测业务，iostat、mpstat 未安装时会跳过：

date -u '+%Y-%m-%dT%H:%M:%SZ'
uname -sr
nproc
free -h
vmstat 1 6
ps -eo pid,comm,%cpu,%mem,rss --sort=-%cpu | head -n 12
df -hT
df -i
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT
if command -v iostat >/dev/null 2>&1; then iostat -xz 1 6; fi
if command -v mpstat >/dev/null 2>&1; then mpstat -P ALL 1 6; fi
ip -s link
ss -s

vmstat、iostat、mpstat 的首行可能是开机以来的统计，判断当前状态时重点看后续采样。ip -s link 是累计计数，须间隔采样计算增量；ss -s 只提供连接状态线索，不能单独证明带宽不足。若命令未安装，不必为一次排障直接改变生产环境，可先使用已有监控取得同口径数据。

2. 先排除配额和应用自身限制，再判断 CPU

将业务响应变慢的时间点与 CPU 忙碌时间、每核利用率、运行队列对齐。若只有一个核心长期繁忙，而其他核心仍空闲，增加核心数未必能缩短单个请求；应先核对该请求是否由单线程、锁或固定数量的工作进程限制。若多个核心持续忙碌、业务请求排队，且磁盘等待、换页没有同步升高，CPU 扩容才更有针对性。

还要区分 CPU 忙碌、I/O 等待和虚拟化环境中的 CPU 等待。vmstat 中 wa 升高提示需要进一步查 I/O，不等于 CPU 算力不够；st 持续异常时，应结合实例监控和运行环境核实 CPU 资源是否如预期交付，不能认定多加虚拟 CPU 就一定有效。

关键配置包括实例的 CPU 规格、容器或进程资源组的 CPU 配额，以及应用工作进程数量。若进程先碰到配额，单纯升级宿主机 CPU 可能不会改变它实际可用的算力。调整前记录原配额和进程数，一次只改一项。

3. 用“可回收空间和实际换页”判断内存

free -h 中已使用内存较高，不一定表示缺内存：文件缓存可能在需要时回收。应同时看 available、vmstat 的 si/so、业务进程内存趋势、OOM 记录，以及进程是否在高峰反复重启。如果可用内存持续偏低，并伴随换页或 OOM，且这些现象与响应变慢吻合，增加内存或提高进程内存上限有明确依据。

若某个进程内存持续增长、不随负载回落，先查异常增长原因；扩容可能只是延后再次耗尽。若宿主机仍有余量，但容器达到自身内存上限，也应先核对对应资源组的限制与事件记录。变更时保存原内存限制、应用并发配置和进程重启记录，以便区分“内存不足”与“程序使用内存异常”。

4. 把业务文件定位到设备，再判断磁盘

先用 df -hT、df -i 检查业务所在文件系统的空间与 inode，再用 lsblk 对照设备和挂载点。空间耗尽、inode 耗尽属于容量问题；空间充足但请求持续等待读写，则要看对应设备的 iostat 等待时间、队列和吞吐，并与应用慢请求对齐。

磁盘平均等待时间上升只是线索，不能脱离读写类型和正常时段比较。%util 对不同存储实现的含义也不完全相同，不能单凭它达到某个数值就认定必须换盘。若多个业务共享设备，要查是谁产生了读写；若存储本身存在独立的性能配额，应核对当前配额和限流记录。最终升级项可能是容量，也可能是读写性能，两者不可互代。

容量接近耗尽时，应先采取已审批、可确认影响范围的空间处置方案并保护数据，再安排扩容。不要在尚未核实文件归属、备份和恢复方式时，直接删除日志或业务文件。

5. 分开验证服务器出口与实际访问路径

网络问题要至少分三处看：美国服务器网卡的收发及错误计数、实例或服务已知的网络配额、业务访问端的真实请求表现。若服务器端传输量持续触及已知上限，并与排队、超时同步，才有理由优先提高网络资源；若服务器端仍有余量，而某一访问节点变慢，应继续核对该节点到服务的路径，不能把路径问题直接归因于服务器带宽。

测试记录必须写清测试节点、时间及时间段、服务器与客户端环境、目标业务地址、请求类型、并发方式、样本数量。例如，比较同一节点在正常时段和故障时段访问同一业务接口的连接时间、首字节时间、总耗时与错误率；再与其他实际访问节点对照。单次请求、单个节点或仅测大文件下载，只能说明该样本下的表现，不能代表所有用户和所有业务。需要主动产生测试流量时，应取得授权，控制测试时长和并发，避免让测试本身挤占生产带宽。

按结果确定一次变更，以及如何验收

确定主瓶颈后，先核对拟升级的资源是否真的作用于受限对象：加 CPU 是否会提高业务进程可用配额；加内存是否会提高进程上限；扩盘是否覆盖发生等待或空间不足的文件系统；提高网络规格是否改变已确认触及的上限。还要核对变更是否需要重启、是否影响现有连接，以及费用和交付时间应以实际可选规格和确认结果为准。

建议一次只变更一个主要变量，并为变更设置清晰的验收与退出条件：

1. 变更前留存：保存实例与应用配置、关键监控、错误日志和可验证的业务备份；记录原规格、原配额及恢复所需权限。涉及存储调整时，先确认备份可读取、恢复步骤可执行，而不是只确认“备份任务完成”。
2. 执行变更：在约定窗口内调整已确认的瓶颈项，记录操作时间与实际生效值。若同时修改规格、工作进程数和应用版本，后续将难以判断哪项起作用。
3. 按原口径验收：在相近负载下，复测同一业务、同一监控指标和同一访问节点。检查响应时间、错误率是否改善，原有排队、换页、磁盘等待或网络限流是否缓解；同时观察是否产生新的瓶颈。
4. 不达标则停止叠加扩容：若资源已增加而业务指标未改善，先复查变更是否生效、业务进程是否仍受配额限制、采样负载是否可比，以及瓶颈是否已转移。不要在原因未明时继续购买或反复加配。

回滚方式必须与变更类型对应。CPU、内存或网络配置如允许恢复原规格，应事先确认恢复所需窗口及对业务连接的影响；应用并发和资源配额应保存原值，必要时按原值恢复。存储扩容通常不能假定可以无损缩回原大小，若变更后出现文件系统或业务异常，应按事先验证的备份与恢复方案处置，并明确恢复点之后的数据如何核对。

异常留证与再次复核

若检查结果互相矛盾，保留“业务症状—资源指标—变更时间”的原始时间线，再解释差异。例如，CPU 高但业务请求没有排队，可能只是后台任务占用；磁盘忙但慢请求不访问该设备，两者未必存在因果关系；网络测速变慢而实际业务稳定，也不足以单独触发升级。此时补采进程、文件系统或访问节点的数据，比立即更换规格更可靠。

完成验收后，至少保留变更前后同口径的业务指标、系统采样、实例配额、测试节点与方法、异常日志及回滚记录。下一轮业务高峰仍需复核：如果原瓶颈消失，但单线程、共享存储或集中式服务成为新的上限，后续应评估应用并发与架构调整，而不是沿着第一次有效的资源项无限扩容。