选香港CN2优化线路服务器遇到高负载，如何排查连接数与磁盘I/O

香港 CN2 优化线路服务器出现高负载时，用户感知通常不止一种：网页打开变慢、接口超时、SSH 登录卡顿、连接数突然增加，或者磁盘读写延迟升高。此时不能仅凭“负载高”判断是线路问题，也不能因为延迟升高就直接更换服务器。网络路径、CPU、内存、连接状态、磁盘 I/O 和具体进程，可能分别造成相似的“变慢”现象，必须先确认影响范围，再定位最先出现异常的指标。

建议按“外部连通性 → 系统总览 → CPU 与内存 → 连接数 → 磁盘 I/O → 进程和应用 → 修复后验证”的顺序排查。先采集数据，不要一开始就重启服务、批量关闭连接或删除日志；这些操作可能暂时掩盖根因，也可能丢失故障证据。

先区分线路延迟与服务器高负载

多大延迟可以作为正常参考

“多大延迟算正常”没有脱离访问地点、运营商、测试协议和业务类型的统一答案。延迟应该结合目标用户所在地、测试时间段、丢包率、TCP 建连时间和应用响应时间一起判断。

以下是排查时可以使用的参考区间，不代表某条线路的官方承诺或当前实测结果：

可以从访问端执行基础测试。下面命令适用于常见 Linux、macOS 或安装了相应工具的环境，server.example.com 应替换为实际业务域名或服务器地址：

ping -c 20 server.example.com

如果系统安装了 mtr，可以进一步观察路由中的延迟和丢包变化：

mtr -rwzc 20 server.example.com

对于 HTTP 或 HTTPS 业务，建议把连接建立、首字节和总耗时拆开看：

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

这里需要注意：

• connect 较高，可能与网络路径、监听队列或连接资源有关。
• ttfb 较高而 connect 正常，通常更应该检查服务器进程、应用处理和磁盘等待。
• total 较高但 ttfb 正常，可能是响应体传输、带宽使用或客户端侧因素。
• ping 使用的是 ICMP，不等同于业务端口的真实响应时间。

因此，选择香港 CN2 优化线路服务器时，不应只看线路名称或一次测试的平均延迟。更可靠的判断方式是，在目标用户网络环境下分时段观察延迟、丢包、TCP 建连和实际接口响应；服务器已经高负载时，还要先排除资源瓶颈，否则线路测试结果也可能被服务端处理延迟干扰。

建立高负载原因树

可以把问题拆成五个相互关联的分支：

1. 网络分支：延迟、丢包、TCP 建连、监听队列异常。
2. 系统资源分支：CPU 使用率、运行队列、内存余量、交换分区。
3. 连接分支：ESTABLISHED、TIME_WAIT、SYN-RECV 数量，文件描述符和端口资源。
4. 磁盘分支：I/O 利用率、等待时间、队列长度、磁盘空间和 inode。
5. 进程与应用分支：哪个进程消耗 CPU、内存或 I/O，是否出现大量阻塞进程和错误日志。

同一现象可能对应不同原因。例如，网页慢并不一定是带宽不足；如果 curl 的 TCP 建连时间正常，但 ttfb 很高，同时 iowait 和磁盘 await 升高，优先级就应放在磁盘和应用处理，而不是更换线路。

第一步：保留现场并查看系统总览

以下命令主要用于读取状态，适合在 Linux 服务器上执行。部分命令需要普通用户权限即可，查看其他用户进程或详细连接归属时可能需要 sudo。

date
uptime
nproc
free -h
df -h
df -ih

重点记录：

• uptime 中的 1 分钟、5 分钟和 15 分钟负载。
• nproc 返回的逻辑 CPU 数量。
• free -h 中的 available，不要只看 used。
• df -h 的磁盘空间使用率。
• df -ih 的 inode 使用率。

Linux 的 load average 不等同于 CPU 使用率。它通常包含正在运行或等待运行的任务，也可能包含处于不可中断睡眠状态的 I/O 任务。比如一台 4 vCPU 服务器的负载长期在 1～2，通常不必立即判定为异常；如果负载持续超过 CPU 数量，并且运行队列、响应时间和错误率同时升高，就需要深入排查。对于磁盘 I/O 密集型业务，即使 CPU 使用率不高，负载也可能因为大量 I/O 等待而升高。

可以使用 vmstat 快速观察 CPU、内存和系统等待：

vmstat 1 5

常见字段可以这样理解：

• r：等待运行的任务数量。持续明显高于 CPU 数量，说明 CPU 竞争可能存在。
• si、so：交换分区换入、换出。持续增长通常说明内存压力较大。
• bi、bo：块设备读写活动，可作为 I/O 线索。
• us：用户态 CPU。
• sy：内核态 CPU。
• wa：I/O 等待时间占比。
• st：虚拟化环境中被宿主机“偷走”的 CPU 时间。

如果 us 很高，优先寻找消耗 CPU 的进程；如果 wa 很高，转向磁盘 I/O；如果 st 明显升高且业务进程并不繁忙，则应记录时段和趋势，进一步与服务商确认宿主机资源争用。

第二步：判断 CPU 和内存是否真正成为瓶颈

使用 top 查看实时状态，下面命令适合一次性采集当前快照：

top -b -n 1 | head -n 25

也可以按 CPU 和内存分别查看进程排行：

ps -eo pid,ppid,user,stat,pcpu,pmem,rss,etime,cmd --sort=-pcpu | head -n 15
ps -eo pid,ppid,user,stat,pcpu,pmem,rss,etime,cmd --sort=-pmem | head -n 15

判断时不要只看单个百分比：

• 单个进程 CPU 长时间接近一个核心的 100%，可能只是单线程任务繁忙；需要结合服务器核心数和业务并发判断。
• 多个工作进程同时占满 CPU，常见于请求量增加、循环任务、压缩计算或应用处理变慢。
• sy 较高，可能与系统调用、网络包处理、文件操作或连接压力有关。
• wa 较高时，CPU 空闲不代表服务器轻松，进程可能正在等待磁盘。
• free 很低不一定异常，Linux 会把空闲内存用于文件缓存；更应该看 available、swap 和回收压力。

查看交换分区状态：

swapon --show
free -h

如果内存不足并持续发生 swap，处理方向应是找出占用内存的进程、检查工作进程数量和缓存规模，而不是简单扩大 swap。swap 可以缓解短时内存峰值，但会把部分内存访问转化为磁盘访问，可能进一步放大 I/O 等待。

如果要确认是否是某个进程持续消耗资源，可先记录 PID、命令行、启动时间和资源曲线，不要在证据不足时直接执行 kill -9。强制终止可能造成请求中断、临时文件残留或数据写入不完整；如确需重启，应先确认服务的优雅停止方式、配置备份和回滚方案。

第三步：检查连接数、连接状态和文件描述符

连接总数升高不一定是异常。长连接、连接池、健康检查和高并发访问都会增加 ESTABLISHED 数量。真正有价值的是观察连接状态、监听端口、来源分布和增长速度。

先查看整体连接摘要：

ss -s

再分别统计常见状态：

ss -Htan state established | wc -l
ss -Htan state time-wait | wc -l
ss -Htan state syn-recv | wc -l

按状态汇总：

ss -Htan | awk '{print $1}' | sort | uniq -c | sort -nr

各状态通常有不同含义：

查看监听端口及关联进程：

ss -lntp

如果只想观察特定业务端口，可以先确认实际监听端口，再执行类似命令：

ss -Htan '( sport = :80 or sport = :443 )'

上面的端口仅适用于业务确实监听 80 或 443 的情况；如果应用使用其他端口，应替换为实际值。对于 IPv6、容器端口映射或前端负载均衡环境，不能仅根据一台服务器看到的连接数推断全部访问量。

还要确认文件描述符是否接近上限：

ulimit -n
cat /proc/sys/fs/file-nr

查看某个进程打开的文件描述符数量时，将 PID 替换为实际进程号：

ls -1 /proc/PID/fd | wc -l

如果连接数持续上升，同时文件描述符接近进程限制，应用可能出现“无法建立新连接”“打开文件过多”等错误。此时不能盲目把限制调得很大，应该先确认：

• 应用是否存在连接泄漏。
• 长连接是否有合理的空闲超时。
• 上游连接是否及时归还连接池。
• 单进程工作模型是否与并发量匹配。
• 系统级和进程级限制是否同时满足。

如果只是 TIME_WAIT 较高，但业务成功率、CPU、内存和磁盘都正常，不宜仅凭这个指标进行激进调整。先确认短连接比例和实际请求失败情况，再决定是否优化连接复用。

第四步：定位磁盘 I/O 瓶颈

磁盘问题常见的表现包括：负载升高但 CPU 利用率不高、应用接口的首字节时间变长、日志写入延迟、进程大量处于 D 状态，以及数据库或文件服务出现超时。

如果系统已安装 iostat，使用扩展统计查看设备状态：

iostat -xz 1 5

常见字段含义如下：

• %util：设备忙碌程度。持续接近 100% 说明设备可能已经成为瓶颈，但不能单独作为结论。
• await：I/O 请求从提交到完成的平均等待时间。
• aqu-sz：设备请求队列长度。
• r/s、w/s：每秒读写请求数量。
• rkB/s、wkB/s：每秒读写吞吐量。

没有 iostat 时，可以先使用：

vmstat 1 5

若需要按进程观察磁盘读写，且系统安装了 pidstat，可以执行：

pidstat -d 1 5

这些工具在不同发行版中可能由不同系统软件包提供。生产高峰期不建议为了安装工具临时进行大范围软件包升级；可以先使用已有的 vmstat、top 和日志，待业务稳定后再补充监控工具。

判断磁盘 I/O 时要同时看三类指标：

1. 设备是否忙：%util 是否持续很高。
2. 请求是否排队：await 和 aqu-sz 是否明显上升。
3. 谁在读写：是否有明确的日志、临时文件、备份或应用进程产生大量 I/O。

查看空间和 inode：

df -h
df -ih

磁盘空间没有写满，并不代表 I/O 正常；设备可能因大量小文件写入、随机读写或同步写入而出现高等待。反过来，空间使用率接近 100% 或 inode 耗尽，也可能让日志、临时文件和应用写入失败。

查看目录占用时，du 会遍历文件系统，可能产生额外读取压力。建议在业务低峰执行，并限制在目标文件系统内：

du -xhd1 /var 2>/dev/null | sort -h

常见根因及处理方向包括：

• 日志量突然增加：先确认是否出现错误循环或重复请求，再调整日志级别和轮转策略。
• 临时文件快速增长：查明生成者和清理逻辑，不要直接删除正在使用的文件。
• 备份或压缩任务占用设备：核对任务时间和资源限制，必要时调整到业务低峰。
• 应用频繁写小文件：检查缓存、会话、上传临时文件和任务队列设计。
• 磁盘空间或 inode 耗尽：先备份重要日志和配置，再按文件归属制定清理方案。

删除日志、清空文件、修改挂载或调整存储配置都可能造成数据丢失或服务异常。执行前应确认备份、文件是否仍被进程使用、影响哪个服务，并保留可回滚副本；不要把“删除占用最大的文件”当作通用修复方式。

第五步：结合进程状态锁定根因

查看进程状态和资源排行：

ps -eo pid,ppid,user,stat,pcpu,pmem,rss,etime,cmd --sort=-pcpu | head -n 20

STAT 字段是重要线索：

• R：正在运行或等待运行，结合 CPU 使用率判断是否存在 CPU 竞争。
• S：可中断睡眠，常见于等待事件或网络请求，本身不代表故障。
• D：不可中断睡眠，常见于等待 I/O。大量进程处于 D 状态时，应优先回到磁盘和底层设备排查。
• Z：僵尸进程，说明子进程已经结束但父进程尚未回收，需要检查父进程处理逻辑。

将进程 PID 与连接、日志和资源变化对应起来。例如某个应用进程 CPU 不高，但大量线程处于 D 状态，同时 iostat 的 await 明显升高，这比单看 load average 更能说明磁盘等待是主要瓶颈。

如果使用 systemd 管理服务，可以先读取状态和近期日志，不要未经确认就重启：

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

将 服务名 替换为实际服务名称。若服务不是由 systemd 管理，应根据实际启动方式查找日志。重点关注：

• 连接池耗尽。
• 文件描述符不足。
• 请求超时和上游超时。
• 反复崩溃、自动拉起。
• 磁盘写入失败。
• 大量重试或异常循环。
• 工作进程数量与请求量不匹配。

如果确认配置变更是必要的，先备份配置并执行语法检查，再采用平滑加载；变更前应记录原配置，出现错误时按备份回滚。重启属于有中断风险的操作，应在明确影响范围、确认业务允许并保留现场后进行。

按现象选择处理方向

可以用下面的对应关系缩小范围：

不要根据一个指标直接采取动作。例如连接数高时，如果 ESTABLISHED 主要是正常长连接，增加服务器规格未必解决问题；如果 CLOSE-WAIT 持续积累，真正需要修复的是应用释放连接的逻辑。又如磁盘空间不足时，直接删除日志可能让正在写入的服务继续异常，应该先保留必要证据并按照日志轮转或备份流程处理。

修复后如何验证已经恢复

修复完成后，至少做一次“前后对照”，而不是只看页面是否暂时恢复。建议重复采集以下数据：

uptime
vmstat 1 5
free -h
ss -s
df -h
df -ih

如果有磁盘统计工具，再次执行：

iostat -xz 1 5

同时从实际访问端重复测试：

curl -sS -o /dev/null \
  -w 'connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://server.example.com/

验证重点包括：

• load average 是否回落，并且不再持续上升。
• CPU 高占用进程是否消失或恢复到可接受范围。
• wa、磁盘 await 和队列是否下降。
• 连接状态是否回到业务平时的变化范围。
• 文件描述符是否停止增长。
• 内存是否稳定，swap 是否继续发生。
• 接口错误率、超时率和日志异常是否恢复。
• 延迟是否稳定，是否仍有明显抖动或丢包。

不要只观察几秒钟。至少覆盖一次业务高峰或持续观察一段时间，确认连接数没有再次爬升、磁盘队列没有重新积压。若调整了连接超时、工作进程、日志级别或缓存参数，还要检查资源是否从一个瓶颈转移到另一个瓶颈，例如 CPU 下降后内存耗尽，或者连接减少后单次请求处理时间变长。

需要持续监控的复发信号

为了避免下次只能依靠人工登录服务器，建议为以下指标设置趋势监控和告警：

• 1 分钟、5 分钟、15 分钟负载与 vCPU 数量的比例。
• CPU 用户态、内核态、I/O 等待和虚拟化等待。
• available 内存、swap 换入换出。
• ESTABLISHED、TIME-WAIT、SYN-RECV、CLOSE-WAIT 数量。
• 文件描述符使用量和进程打开文件数。
• 磁盘 %util、await、队列长度和读写吞吐。
• 磁盘空间与 inode 使用率。
• 接口 TCP 建连时间、首字节时间、总响应时间和错误率。
• 高 CPU、高内存和高 I/O 进程的变化趋势。

这样在选择或评估香港 CN2 优化线路服务器时，就能把“线路延迟是否正常”和“服务器是否高负载”分开判断：延迟需要看访问路径与业务端口，高负载需要看系统资源、连接状态、磁盘 I/O 和进程行为。只有先确认瓶颈所在，再决定优化配置、调整业务任务或更换服务器，排查结果才具有可复现性。