香港GPU服务器高负载排查：从CPU、内存、磁盘I/O、连接数到进程状态
本文介绍香港GPU服务器出现响应变慢、训练吞吐下降或SSH卡顿时的排查流程，依次分析CPU、内存与Swap、磁盘I/O、连接数、进程状态及GPU任务关联，并说明指标含义、处置原则和修复后的复测方法。
香港GPU服务器出现响应变慢、训练任务吞吐下降或SSH操作卡顿时，先确认影响范围：是整机都慢，还是单个容器、模型服务或训练进程异常；问题持续存在还是只在任务启动、数据加载、模型保存时发生。Linux中的高负载不等于CPU占用率高，处于可运行状态以及不可中断睡眠状态的任务，都会被计入负载，因此磁盘I/O阻塞、内存回收和进程锁等待也可能推高 Load Average。
建议按“记录现场 → CPU与负载性质 → 内存与Swap → 磁盘I/O → 连接数 → 进程状态 → GPU任务关联”的顺序检查。先执行只读命令保留基线，不要一看到高负载就重启或强制结束进程，否则容易丢失定位依据，也可能导致训练检查点、缓存或业务请求受损。
先记录故障现场与负载基线
以下命令适用于常见Linux发行版。执行前可通过 cat /etc/os-release 核对系统，部分命令来自 sysstat、procps 或 iproute2 软件包。
date
hostname
cat /etc/os-release
uptime
getconf _NPROCESSORS_ONLN
who
重点关注 uptime 中最近1、5、15分钟的平均负载，并结合逻辑CPU数量判断。负载值不能脱离CPU核心数单独比较：相同的 Load Average，在不同CPU规模下代表的排队程度不同。
继续查看整体资源快照：
top -b -n 1 | head -n 30
vmstat 1 5
free -h
df -hT
df -ih
vmstat 中几个关键字段的含义如下：
| 字段 | 含义 | 异常时优先排查 |
|---|---|---|
r |
等待CPU运行的任务数 | CPU计算压力、线程过多 |
b |
不可中断睡眠任务数 | 磁盘、网络存储或驱动等待 |
si/so |
Swap换入、换出 | 内存不足、工作集过大 |
us |
用户态CPU占用 | 训练预处理、推理或计算进程 |
sy |
内核态CPU占用 | 网络、驱动、系统调用压力 |
wa |
CPU等待I/O的时间 | 磁盘拥塞或存储响应慢 |
st |
虚拟化环境中被宿主机占用的时间 | 需要结合虚拟化环境进一步核查 |
如果 r 持续偏高而 b 较低，通常先查CPU；如果 b 和 wa 同时升高，则优先查I/O。单次采样可能受瞬时任务影响，应连续观察并与正常时段对比。
判断CPU是真的繁忙，还是任务在排队
在安装了 sysstat 的环境中，可查看各CPU核心和进程消耗：
mpstat -P ALL 1 5
pidstat -u -t 1 5
ps -eo pid,ppid,user,stat,psr,%cpu,%mem,etime,comm,args --sort=-%cpu | head -n 30
不同结果对应不同方向：
- 单个进程长期占用多个核心：检查其线程数、批处理并发和数据预处理配置。
- 某个核心接近满载、其他核心空闲：可能存在单线程瓶颈、CPU亲和性限制或中断集中。
sy较高：检查频繁系统调用、网络包处理、驱动或大量上下文切换。- Load Average很高，但CPU仍有较多空闲：不要继续按CPU不足处理，应转查I/O和D状态进程。
- 容器内看到的CPU数量与实际配额不一致：检查容器CPU限制，而不是仅依据宿主机核心数判断。
可通过以下命令查看上下文切换和中断变化：
pidstat -w 1 5
vmstat 1 5
线程数量失控也会造成调度压力：
ps -eLf | awk '{count[$2]++} END {for (pid in count) print count[pid], pid}' | sort -nr | head
该结果第一列为线程数、第二列为PID。若某进程线程数异常增长，应先检查应用线程池和并发设置，不要直接用 kill -9 处理。
检查内存、缓存与Swap压力
Linux会使用空闲内存作为文件缓存，因此不能只看 free 列。判断可用内存时应重点查看 available，同时结合Swap活动和内核日志。
free -h
vmstat 1 10
ps -eo pid,user,%mem,rss,vsz,stat,comm,args --sort=-rss | head -n 30
grep -E 'MemAvailable|SwapTotal|SwapFree|Dirty|Writeback' /proc/meminfo
常见判断包括：
available较低，但si/so长期为0：可能只是缓存较多，不能直接认定内存耗尽。si/so持续出现：说明活跃数据正在与Swap交换，延迟通常会明显增大。Dirty或Writeback长时间堆积：数据回写受阻，应继续检查磁盘。- 某个进程RSS不断增加：可能是缓存没有上限、任务数据集扩大或内存泄漏。
检查是否发生过OOM：
journalctl -k --since "-2 hours" | grep -Ei 'oom|out of memory|killed process'
如果系统没有使用 systemd，可改查 /var/log/messages 或 /var/log/kern.log，具体路径取决于发行版。OOM记录中的被终止进程不一定是根因，还要检查是谁长期占用了内存。
不建议把“清理缓存”作为常规修复方式。手动写入 drop_caches 会影响系统缓存命中率，也不能解决内存泄漏；生产环境应优先调整应用内存上限、批大小或并发量。
用I/O指标定位磁盘等待
数据集读取、日志集中写入、模型检查点保存都可能让GPU任务等待存储。安装了 sysstat 后可执行：
iostat -xz 1 5
pidstat -d 1 5
应结合多个指标判断：
await增大：I/O请求完成时间变长。avgqu-sz或对应队列字段持续增加：设备请求正在排队。%util较高：设备较忙，但在NVMe、阵列和不同版本的iostat中不能只凭该字段断定性能已经耗尽。pidstat -d中某进程读写量突出：进一步确认它是在正常加载数据，还是异常刷日志、频繁写临时文件。
同时检查容量、inode和内核错误：
df -hT
df -ih
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
journalctl -k --since "-2 hours" | grep -Ei 'i/o error|timeout|reset|nvme|ext4|xfs'
磁盘空间或inode耗尽也会让应用反复报错。发现文件系统错误、设备重置或I/O超时后，不要立即执行修复或格式化命令；应先备份关键数据，确认磁盘、挂载方式及文件系统类型，再安排维护窗口。
排除连接数与请求堆积
模型API、WebSocket或反向代理连接大量积压，会增加进程线程、文件描述符和内核网络处理压力。先查看汇总状态：
ss -s
ss -ant | awk 'NR>1 {count[$1]++} END {for (s in count) print s, count[s]}' | sort
ss -lntp
结果需要结合业务性质解释：
ESTAB增长：可能是正常长连接，也可能是请求处理速度下降导致堆积。SYN-RECV较多：检查入口流量、监听队列和应用接收能力。CLOSE-WAIT持续累积：通常表示本地应用没有及时关闭对端已关闭的连接。TIME-WAIT较多：常见于大量短连接，需结合连接创建速率和端口范围判断，不能仅凭数量判故障。
检查进程文件描述符时，将PID替换为实际值：
PID=1234
cat /proc/$PID/limits | grep -i 'open files'
find /proc/$PID/fd -maxdepth 1 -type l 2>/dev/null | wc -l
如果当前使用量接近进程限制，应先确认连接未释放的原因，再按服务管理方式调整限制。直接提高上限只能延后故障，无法修复连接泄漏。
从进程状态确认阻塞点
进程状态是区分“正在计算”和“正在等待”的关键证据：
ps -eo state,pid,ppid,wchan:32,%cpu,%mem,etime,comm,args --sort=state
常见状态包括：
R：正在运行或等待CPU，数量持续较多时关注CPU调度压力。S：可中断睡眠，通常是正常等待事件。D：不可中断睡眠，多与块设备、网络文件系统或驱动等待有关。Z：僵尸进程，本身几乎不消耗CPU，但大量出现说明父进程没有正确回收子进程。T：进程被暂停或正在被调试。
若发现D状态进程，可查看等待位置：
PID=1234
cat /proc/$PID/wchan
sudo cat /proc/$PID/stack
读取内核栈通常需要root权限，且受内核安全策略影响。若等待位置指向文件系统、块设备或驱动，应结合 iostat 和内核日志判断；D状态进程通常无法通过普通信号立即结束，强制重启前必须评估未写入数据和任务恢复能力。
把系统负载与GPU任务对应起来
对于使用NVIDIA驱动的香港GPU服务器，可补充检查GPU利用率、显存和关联进程：
nvidia-smi
nvidia-smi pmon -s um -c 5
如果GPU利用率低，而CPU、磁盘等待或内存换页明显升高，通常说明GPU正在等待数据准备或传输；如果GPU利用率和显存占用都高，但系统CPU与I/O正常，则可能只是任务本身处于高强度计算阶段。nvidia-smi 不适用于其他厂商GPU，命令不可用时应先核对硬件和驱动工具。
需要结束异常任务时，先确认PID所属用户、父进程、容器及任务保存机制，优先发送可被应用处理的终止信号：
kill -TERM <PID>
等待应用保存状态并退出后再复查。不要默认使用 kill -9，因为它不会给进程清理显存、写入检查点或关闭文件的机会。
修复后的验证步骤
完成并发限制、应用重启、存储处理或异常进程处置后，应使用与故障前相同的任务和观察窗口复测：
- 重新记录
uptime、vmstat 1 10、free -h和iostat -xz 1 10。 - 确认运行队列、D状态任务、Swap活动和I/O等待不再持续增长。
- 使用
ss -s检查连接状态是否稳定，确认CLOSE-WAIT、SYN-RECV等没有继续累积。 - 对照
ps、pidstat与nvidia-smi，确认CPU、存储和GPU之间不再存在明显等待链。 - 复测原有训练、推理或接口请求，核对吞吐、响应时间、错误日志和任务输出是否恢复。
- 保留修复前后的命令结果及时间点，继续观察至少一个完整业务周期，避免把短暂下降误判为故障已经解除。