一次页面访问从客户端发起后，会依次经过域名解析、网络连接、服务器接收请求、应用处理和磁盘读写。用户看到的响应变慢，可能是其中一层排队，也可能是多个环节叠加；服务器上的负载数值只能说明资源状态，不能单独证明故障原因。

排查美国服务器高负载，可先确认请求是否普遍变慢，再依次检查网络连接、CPU、内存、磁盘 I/O 和进程状态，最后把指标变化与具体请求、日志时间对应起来。以下命令适用于常见 Linux 系统；部分工具需要安装 sysstat，如果命令不存在，先按当前发行版的软件包管理方式核实安装包，不要直接套用其他系统的安装命令。检查期间先保留现有配置，不要因单个指标偏高就重启或结束进程。

先沿请求路径确认故障范围

先区分“所有访问都慢”“只有特定接口慢”还是“服务器本机也慢”。如果只有某个页面或操作受影响，应优先对照该接口的应用日志、数据库调用和请求量；如果多个服务同时变慢，再重点查看共享的 CPU、内存、磁盘和连接状态。

从可正常访问业务的客户端执行一次请求计时。将示例中的域名替换为实际业务域名，并确保测试请求不会触发写入、扣款等业务操作：

curl -o /dev/null -sS \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  'https://example.com/health'

这些时间点是累计阶段值，不能简单相加。time_namelookup 偏高时，先核对域名解析；time_connect 明显增加，说明建立连接阶段耗时较多；time_appconnect 增加，表示安全连接协商阶段耗时较多；time_starttransfer 与前序阶段相比增加较多，通常需要继续查服务器接收请求后的处理；time_total 高而首字节较快，则检查响应体生成或传输是否缓慢。单次结果可能受客户端网络和瞬时负载影响，应在相近条件下重复几次，并与业务监控、访问日志的时间点对照。

随后在服务器本机对同一业务做对照测试。若本机访问明显快于外部，而外部请求慢，优先检查服务器外部的网络路径、连接建立和入口侧记录；若本机也慢，则继续检查服务器资源和应用处理。若本机请求绕过了业务实际使用的入口或访问路径，它只能作为对照，不能代表完整访问结果。

第一优先级：看整体负载和 CPU

登录服务器后先记录当前时间和系统运行概况：

date
uptime
top

uptime 显示的 load average 是一段时间内处于可运行状态或不可中断等待状态的任务负载，不等同于 CPU 使用率。它需要结合 CPU 核心数、top 中的 CPU 状态以及任务状态判断：负载持续高于可用处理能力且 CPU 长时间繁忙，才更支持 CPU 计算资源不足的判断；负载较高但 CPU 空闲，可能是任务在等待磁盘等资源，不能据此直接增加计算资源。

在 top 中观察 %us、%sy、%id、%wa 和进程列表：

• %us 高，表示用户态程序消耗较多 CPU，继续找出具体进程和线程。
• %sy 高，表示内核态开销偏高，可结合连接数、系统调用相关日志和进程变化进一步分析。
• %wa 高，表示 CPU 有时间在等待 I/O；这不等于磁盘一定损坏，应继续检查磁盘延迟和队列。
• %id 长时间较低且主要进程持续占用 CPU，才更符合 CPU 瓶颈特征。

按 CPU 使用率查看进程：

ps -eo pid,ppid,stat,%cpu,%mem,comm --sort=-%cpu | head -n 20

如果进程列表变化快，可用 top 持续观察，或在系统已安装 sysstat 时执行：

pidstat -u -p ALL 1 5

pidstat 每秒采样一次，便于区分持续占用和短暂峰值。若某个业务进程长期占用较高，需结合其请求量、线程数、应用日志和发布变更检查：可能是流量增加、计算逻辑变慢、循环或重试异常，也可能是请求集中到单个工作进程。若 CPU 使用率不高但请求积压，转查内存、磁盘等待、连接和应用线程是否阻塞。

在虚拟化环境中，如果工具显示 %steal，该值反映虚拟机等待宿主机调度的时间。它持续偏高时，不能只从业务进程本身推断原因，应将采样时间和实例运行环境一并提供给运维支持人员核验。

第二优先级：区分内存紧张与缓存占用

执行：

free -h
vmstat 1 5

Linux 会利用空闲内存做缓存，因此 free 中的 free 较低不一定代表内存不足。应关注 available，并结合 vmstat 的 si、so（交换空间读写）以及内核是否发生内存回收或进程被终止来判断。若可用内存持续下降，同时交换空间读写持续发生，且应用响应变慢，内存压力的可能性较高；若缓存占用较多但 available 仍充足，通常不应仅凭缓存数值采取清理操作。

查看占用较多的进程：

ps -eo pid,ppid,stat,%mem,rss,comm --sort=-%mem | head -n 20

RSS 是进程当前驻留在内存中的近似量，不等于该进程独占的全部物理内存；共享库等资源会造成统计口径上的重叠。发现某个进程内存持续增长时，应在多个时间点记录 PID、RSS 和业务负载，结合应用自身的内存指标、日志及最近变更判断是否存在泄漏、缓存失控或并发上升。

如果出现交换空间持续读写，先确认是哪个进程、何时开始，以及是否与流量峰值或任务批次重合。不要把清空系统缓存或直接调整交换空间当作首选处理方式：前者可能造成后续 I/O 增多，后者也不能代替查明内存为何持续不足。内存调整或应用重启会影响现有业务，应先确认可用维护窗口、服务恢复方式和配置备份，再执行变更。

第三优先级：用磁盘延迟和进程等待定位 I/O

若 CPU 的 %wa 偏高、应用日志显示读写变慢，或进程处于不可中断等待状态，检查磁盘 I/O。安装了 sysstat 的 Linux 系统可执行：

iostat -xz 1 5

重点看设备的 await、aqu-sz、读写速率和 %util，并观察它们是否在业务变慢时同步变化。await 反映 I/O 请求等待和服务的平均耗时，aqu-sz 可辅助观察队列情况；%util 表示设备忙碌时间比例，但在多队列设备等环境中，不能把它单独当作“设备已满”的结论。应结合设备类型、业务读写模式、系统基线和连续采样判断。若高延迟只出现在某个时间段，进一步核对备份、日志轮转、批处理或大文件读写是否同时发生。

用 vmstat 的 b 列观察处于不可中断等待的任务，并查看具体进程状态：

ps -eo state,pid,ppid,comm,wchan:24 --sort=state | head -n 30

状态为 D 的进程通常正在等待内核资源，I/O 等待是常见原因，但仍需结合 wchan、磁盘指标和进程日志确认。状态为 Z 表示进程已退出但尚未被父进程回收，通常需要检查父进程管理逻辑；僵尸进程本身一般不消耗明显 CPU。大量处于 R 状态的任务则可与 CPU 使用率、运行队列一起判断是否存在计算排队。

若系统允许且已安装相关工具，可用 pidstat 观察进程 I/O：

pidstat -d -p ALL 1 5

如果磁盘指标没有同步升高，而请求依旧慢，应继续看应用是否在等待数据库、外部服务或锁。磁盘忙碌也可能是应用日志写入量突然增加，而不是业务数据读写本身变慢。不要在未确认路径和业务影响前删除日志、临时文件或数据文件；若需要清理，先确认文件用途、保留要求和备份，并制定可恢复方案。

第四优先级：核对连接数和连接状态

连接总数高不必然等于故障，关键是状态分布、变化趋势和具体端口。先查看连接概况及监听端口：

ss -s
ss -lnt

如需观察已建立的 TCP 连接数量：

ss -tan state established | wc -l

连接数持续增加时，按服务端口检查来源和状态分布，并与业务请求量、应用工作进程数及系统资源对照。大量 ESTAB 可能是正常并发，也可能意味着请求未及时结束或连接复用策略异常；较多 TIME-WAIT 常与短连接建立和关闭频繁有关，单独出现并不能证明连接故障；SYN-RECV 突增则应结合入口访问量、系统日志和网络监控核实连接建立是否异常。不要仅根据某一状态计数调整系统参数，错误调整可能影响正常连接。

检查连接数时还要区分“网络连接已经建立”和“应用已经处理请求”。连接正常但请求长时间没有响应，可能是应用线程池、数据库连接池或下游依赖等待；连接建立失败或耗时变长，则更应检查入口路径和服务器监听状态。可将 ss 采样时间与请求计时、应用日志时间戳对齐，以判断连接变化是否与故障同步。

第五优先级：把资源现象对应到应用进程

资源指标说明“哪里在忙或在等”，应用日志和进程信息才能帮助回答“为什么”。先确认进程是否存在、运行状态是否变化，再检查服务日志。服务名称需替换为系统中实际配置的单元名称：

systemctl status 服务名
journalctl -u 服务名 --since "30 minutes ago"

若服务由其他方式管理，先查明实际启动方式和日志位置，不要假设所有程序都由同名系统服务托管。对照故障时间，重点寻找请求超时、重试增多、工作进程退出、连接池耗尽、任务积压和频繁错误等迹象。若 CPU、内存和磁盘均未呈现明显压力，但应用仍变慢，应检查应用内部队列、锁等待、数据库调用耗时及下游服务响应时间；这类等待不会总是表现为高 CPU。

也要核对问题是否只落在单个进程或单个请求类型上。某个任务占用 CPU，可能是正常的批处理；如果它与在线请求争用资源，才需要进一步调整任务时间或并发策略。调整前先确认该任务能否暂停、是否支持续跑、会影响哪些业务，并保存原配置。不要用强制结束进程作为常规排查动作：它可能造成请求中断、数据未完成写入或任务状态不一致。确需重启时，应先按应用支持的正常停止流程执行，记录变更并确认回滚办法。

按结果分支确定下一步

表中是排查方向而非单项指标的定论。比如 CPU 不忙并不能排除应用阻塞，连接数量多也不能直接证明网络异常。判断成立的条件，是相关指标与实际变慢在时间上吻合，并且能由日志、进程或请求耗时进一步支持。

修复后按同一路径复测

定位到可验证的原因后，一次只改一个主要因素，记录变更前的配置和指标，并明确影响范围。若调整应用并发、任务计划或资源配置，应先确认服务支持的变更方式；需要重启或可能中断请求时，安排可接受的操作窗口，并保留原配置以便恢复。不要通过无差别重启来掩盖持续存在的瓶颈。

修复后从与故障相同的客户端和入口重复请求计时，并在服务器侧同步观察 top、free、vmstat、iostat、ss 和应用日志。检查响应时间是否改善，CPU、可用内存、交换空间读写、磁盘延迟、连接状态和错误日志是否恢复到适合当前业务的范围。随后再覆盖受影响的接口或任务，并在相近流量条件下观察一段时间；如果只在低负载时变快，仍需继续验证峰值请求下是否出现新的排队。

如果变更后出现错误增加、连接失败或资源指标进一步恶化，应按预先记录的步骤恢复原配置或停止新增任务，再重新对照指标。最终应能把瓶颈描述为具体环节，例如“某进程持续消耗 CPU，并与某类请求变慢同步”或“磁盘等待与任务批次重合”，而不是只留下“服务器负载高”的结论。