日本CN2线路服务器延迟升高伴随高负载，如何联动CPU、磁盘I/O与连接数排查？

日本CN2线路的服务器国内访问延迟升高时，ping、CPU使用率或连接总数中的任何一个指标都可能造成误判。延迟可能来自访问路径，也可能来自服务器端请求排队、磁盘阻塞、内存换页或连接处理能力下降。判断高负载是否放大了网络请求等待，必须把外部响应时间与CPU、内存、磁盘I/O、连接状态和进程状态放在同一个时间窗口内观察。

建议按照“固定故障窗口—拆分请求耗时—检查CPU与内存—确认磁盘I/O—分析连接队列—定位具体进程—修复后复测”的顺序处理。先进行只读检查并保留证据，不要在原因未明时直接重启服务、清理日志、关闭交换分区或盲目提高连接上限。连接数也不能等同于每秒请求数：连接数表示某一时刻保持的会话数量，RPS（每秒请求数）还取决于连接复用、请求持续时间和业务处理速度。

先固定时间窗口，区分线路延迟与服务器排队

排查前记录延迟开始升高、达到峰值和恢复的大致时间，并统一以下信息：

• 测试域名、端口、URL、请求方式和协议。
• 国内不同访问节点的测试时间、响应时间、错误率和目标地址。
• 服务器所在时区、系统时间及近期发布、批处理或配置变更。
• 服务器的CPU、内存、磁盘吞吐、I/O等待、网络吞吐和连接状态曲线。
• 服务器本机访问同一接口时的结果。

如果条件允许，应从两个或以上国内访问节点重复测试，并在服务器本机发起同一接口请求。不同国内节点都变慢，且服务器本机的接口请求也变慢，优先检查服务器负载、应用排队和进程状态；外部节点变慢但服务器本机请求正常，则不能直接把问题归因于服务器高负载，应重点核对访问路径、端口连通性和线路侧表现。

常见Linux发行版，包括Debian、Ubuntu、CentOS和Rocky Linux，可以先执行以下只读命令：

date -Is
uptime
nproc
free -h
vmstat 1 5
ss -s

这些命令分别用于记录时间、查看平均负载、确认逻辑CPU数量、观察内存和交换分区、采样运行队列与I/O，以及查看连接总览。单次采样不足以说明问题，建议连续观察5～15分钟，并尽量让外部请求测试与服务器指标使用同一时间戳。

先拆分请求耗时，再判断是否由服务器拖慢

只看ping只能观察ICMP报文往返时间，不能代表HTTPS请求的完整耗时。应从国内测试节点执行与实际业务接近的请求：

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  --connect-timeout 5 \
  --max-time 15 \
  'https://业务域名/health'

各字段含义如下：

• dns：域名解析耗时。
• connect：TCP建连完成耗时。
• tls：TLS握手完成耗时，HTTP明文服务没有这一阶段。
• ttfb：收到首字节的时间，包含网络传输和服务端处理等待。
• total：完整请求耗时。

判断时要看字段的变化关系，而不是只看总耗时：

• connect明显升高，但服务器CPU、磁盘和连接队列稳定，服务器本机请求正常，访问路径、端口可达性或线路拥塞的可能性更高。
• connect基本稳定，而ttfb和total同步升高，通常应检查应用处理、CPU排队、内存压力或磁盘读取。
• ttfb升高，同时服务器错误率、请求队列或业务进程等待增加，说明服务端已经参与了延迟形成。
• total升高但ttfb变化不大，还要区分响应内容传输、客户端网络和服务端出口吞吐，不能只根据首字节时间判断应用计算变慢。

需要观察路径时，可从国内测试节点执行：

mtr -r -c 20 -w 业务域名

mtr适合观察一段时间内的路径变化，但部分中间设备会限制或丢弃探测报文。某一跳显示丢包，不等于业务流量实际丢包，应结合最终目标地址的丢包率、TCP建连耗时和应用请求结果判断。服务器本机正常、多个外部节点的connect同时升高时，应保存测试时间、目标地址、端口和结果，再进一步核对线路侧；不能仅凭某个中间节点的ICMP数据判定故障。

CPU和内存：看排队、换页与进程增长

CPU使用率接近100%不一定意味着所有请求都由CPU拖慢，可能只是后台任务占用计算资源；反过来，CPU使用率不高时，如果进程大量处于不可中断睡眠，也可能出现明显延迟。因此要同时观察运行队列、I/O等待和具体进程。

uptime
nproc
vmstat 1 5
ps -eo pid,ppid,stat,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 20

重点关注vmstat字段：

• r：等待运行的任务数。持续高于逻辑CPU数量时，说明存在运行排队的可能。
• us：用户态CPU使用率，常见于应用计算、脚本和业务处理。
• sy：内核态CPU使用率，可能与网络包处理、系统调用或内核任务有关。
• wa：等待I/O的时间比例。该值较高时，不能简单归类为CPU不足。
• st：虚拟化环境中被宿主机占用的CPU时间。持续升高时，需要核对实例所在宿主资源状况。
• si、so：从交换分区换入、换出的数据量。

平均负载必须结合CPU数量理解。8个逻辑CPU上的负载为8，与2个逻辑CPU上的负载为8，排队程度并不相同；即使负载高于CPU数量，也还要结合r、wa和进程状态形成判断。

内存方面，Linux会将空闲内存用于文件缓存，free较小并不代表内存耗尽。可以执行：

free -h
vmstat 1 5
ps -eo pid,ppid,stat,%cpu,%mem,rss,etime,cmd --sort=-%mem | head -n 20

更有参考价值的是：

• available是否在延迟升高期间持续下降。
• si、so是否持续出现。
• 单个进程RSS是否持续增长。
• 是否伴随进程被系统终止、服务重启或错误日志。
• 内存压力消失后，响应时间是否同步恢复。

例如一组用于说明机制的监控数据中，CPU使用率只有45%，但available从3GB降至300MB，vmstat的si/so持续有数据，接口ttfb从200ms升至1.5s。这种组合仍然属于服务器侧高负载线索，因为内存回收和交换分区读写会让进程等待，CPU不高不能排除内存造成的延迟。

不要在未确认原因时直接清理缓存、关闭交换分区或强制结束占用内存的进程。这些操作可能触发更多I/O、造成服务中断或数据丢失。应先保存进程列表、内存曲线和服务日志，再根据影响范围决定是否在维护窗口内优雅重启，并准备配置备份和回滚方案。

磁盘I/O：把wa、队列和应用延迟对齐

当vmstat中的wa升高，或者进程状态中出现大量D，应进一步确认设备等待和具体读写进程。先确认工具是否已安装：

command -v iostat
command -v pidstat

如果服务器已经安装sysstat，可执行：

iostat -xz 1 6
pidstat -d 1 5

带间隔参数时，iostat第一组数据可能是系统启动以来的累计值，通常应重点查看后续时间间隔。常见字段含义如下：

• %util：设备忙碌程度。
• r/s、w/s：每秒读写请求数。
• await：请求从提交到完成的平均等待时间，包括排队和设备处理时间。
• aqu-sz：平均请求队列长度。
• rkB/s、wkB/s：读写吞吐量。

不要用一个固定的await数值判断所有磁盘类型。应比较正常基线与故障期间的变化，并确认%util、aqu-sz、wa及应用ttfb是否同步升高。例如平时await约为5ms，故障期间升至80ms，同时队列长度和wa增加，且接口ttfb同步变慢，这比单看磁盘吞吐量更能说明请求正在等待存储完成。

pidstat可以帮助定位产生读写的进程：

pidstat -d -p ALL 1 5

某个进程持续有较高写入，可能与日志、临时文件、缓存落盘、批处理或数据库请求有关；多个业务进程同时进入D状态，则更像是共享存储设备或文件系统层面的等待。

还应检查容量和inode：

df -hT
df -ih

磁盘空间或inode接近耗尽时，可能出现日志无法写入、临时文件创建失败和应用报错。清理文件属于有风险操作，不能直接使用通配符删除。删除前要确认文件用途、保留周期、备份状态、影响范围和回滚方式；优先通过应用或日志管理机制归档，避免在故障高峰期手工删除正在使用的文件。

连接数不能代替请求量，要结合队列和状态判断

连接数增加可能表示访问量上升，也可能是请求处理变慢后形成堆积。并发连接数是某一时刻保持的连接数量，不等于每秒请求数。对于复用连接的业务，一个连接可能承载多个请求；对于短连接业务，较高RPS也可能只对应较低的同时连接数。因此应同时查看连接状态、监听队列、响应时间和错误率。

执行以下只读命令：

ss -s
ss -lnt
ss -lntp
ss -ant state syn-recv | wc -l
ss -ant state established | wc -l
ss -ant state time-wait | wc -l
ss -ant state close-wait | wc -l

ss -lntp查看监听端口及关联进程时，部分进程信息可能需要root权限；命令本身不会修改连接或防火墙配置。各状态可按以下方式解释：

• SYN-RECV持续较高：握手请求正在等待处理，可能是短时连接突增、应用接受连接变慢或监听队列不足，也要结合安全日志核对异常流量。
• ESTABLISHED持续增长：可能是长连接正常增加，也可能是请求处理变慢，导致连接迟迟不释放。
• TIME-WAIT较多：短连接创建和关闭频繁，常见于连接复用不足或请求模式变化。
• CLOSE-WAIT持续增长：对端已关闭连接，但本地应用没有及时释放，通常应检查应用关闭连接的逻辑。
• 监听socket的Recv-Q持续接近Send-Q：等待被应用接受的连接可能正在排队。

如果业务使用443端口，可分别统计连接状态：

ss -Hant state established '( sport = :443 )' | wc -l
ss -Hant state syn-recv '( sport = :443 )' | wc -l

ESTABLISHED很高但CPU、磁盘和内存都正常时，应查看是否属于长轮询、长连接或未及时释放的业务请求。CLOSE-WAIT持续增长时，应优先修复应用资源释放、连接池和超时逻辑，而不是简单提高系统连接上限。

如果SYN-RECV、监听队列和错误率同时升高，不能直接通过增大backlog掩盖问题。提高队列参数只能延后溢出时间；如果应用本身无法及时接受和处理连接，延迟仍会继续上升。应先确认监听进程、线程数、连接处理能力和访问来源变化。

用进程状态把资源异常落到具体服务

资源指标说明“哪里拥堵”，进程状态帮助判断“谁在制造拥堵”。可以执行：

ps -eo pid,ppid,stat,wchan:24,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 20
ps -eo pid,ppid,stat,wchan:24,%cpu,%mem,etime,cmd | awk '$3 ~ /D|Z/'

常见状态包括：

• R：正在运行或等待CPU，应结合r和%CPU判断计算排队。
• D：不可中断睡眠，常见于等待磁盘或其他内核I/O。
• S：可中断睡眠，单独出现通常不代表故障。
• Z：僵尸进程，表示子进程已退出但父进程尚未回收；数量持续增加时应检查父进程。

确定PID后，可进一步观察短时间内的CPU、内存和磁盘活动：

pidstat -u -r -d -p PID 1 5

如果系统使用systemd，可以先确认运行中的服务，再读取近期日志：

systemctl list-units --type=service --state=running
journalctl -u 服务名 --since "10 minutes ago" --no-pager

日志读取是只读操作，但不要在没有确认服务名称、依赖关系和影响范围时直接重启服务。必须重启时，应先备份配置和关键日志，确认维护窗口、回滚方式及业务影响，并优先使用服务支持的优雅重载或重启机制。

按指标组合形成判断

下表中的关系用于排查方向，不是脱离业务基线的固定阈值：

例如一组用于解释机制的监控数据中，延迟从180ms升至900ms，CPU从35%升至92%，r从2增至14，wa保持在3%左右，磁盘await没有明显变化。这种组合更接近CPU运行排队。

另一组数据中，CPU只有48%，但wa从4%升至30%，await从6ms升至90ms，多个业务进程进入D状态，接口ttfb同步增加，则应优先处理磁盘I/O，而不是继续增加CPU或调整网络参数。上述数值用于说明判断关系，不代表本站实测、当前监控或某个具体服务器的性能结论。

修复后用相同条件验证

修复前尽量保留故障期间的证据：

• 外部节点的connect、ttfb、total和错误率。
• uptime、vmstat、free、iostat采样结果。
• SYN-RECV、ESTABLISHED、TIME-WAIT、CLOSE-WAIT数量和监听队列。
• 高占用进程列表、PID及对应日志时间段。

处理方式应与判断结果对应：CPU排队时先确认异常进程和请求来源；内存压力时定位持续增长的进程和请求类型；磁盘拥塞时确认具体读写进程并降低突发写入；连接堆积时检查连接复用、超时、释放逻辑和应用接受连接能力。若更像访问路径问题，应使用多个国内节点在相同时间段重复测试，并保留服务器本机结果，避免用单个ICMP丢包点直接判定线路故障。

修复后不要只执行一次ping，应使用相同URL、相同测试节点和接近的请求间隔重复验证。例如进行10次低频请求：

for i in $(seq 1 10); do
  date -Is
  curl -sS -o /dev/null \
    -w 'connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
    --connect-timeout 5 \
    --max-time 15 \
    'https://业务域名/health'
  sleep 1
done

同时观察：

vmstat 1 5
iostat -xz 1 5
ss -s

验证有效不只表现为一次请求变快，而应同时满足：响应时间回到接近故障前的基线，错误率不再升高；CPU运行队列、磁盘等待、内存换页和异常连接状态不再持续增长。如果延迟短暂恢复后又逐步升高，说明触发源可能仍在，应继续观察进程增长、连接累积和磁盘队列，不能把一次恢复当成问题已经解决。

后续告警最好在同一时间序列中同时保留外部请求的connect、ttfb、总耗时和错误率，CPU的使用率、平均负载、运行队列、wa与st，内存的available、RSS和交换分区读写，磁盘的吞吐、await、队列长度与%util，以及SYN-RECV、ESTABLISHED、TIME-WAIT、CLOSE-WAIT和异常进程状态。这样日本CN2线路的服务器国内访问延迟再次升高时，才能在同一时间窗口内区分连接路径变慢与服务器内部高负载排队。