2. nvidia-smi 指标异常与进程残留定位

为什么 nvidia-smi 的“异常”需要交叉验证

单看 nvidia-smi 默认表格，很容易把三类不同问题混为一谈：显存被真实计算任务占满、显存被已退出但未释放上下文的进程“挂住”、以及 GPU 利用率高但实际没有有效计算（空转）。定位的关键不是看一个数字，而是把 显存占用、进程列表、利用率、进程树、日志 五条线索对齐到同一个 PID 上。

下面这张图给出本节的核心判读结构：从 nvidia-smi 的三种查询模式出发，分别暴露显存、进程、利用率信号，再汇入“PID 对齐”这一判断枢纽，最终分流到三种典型结论与对应处置。

用查询模式把“异常”变成可判读的数据

默认表格适合人眼扫一眼，但排障需要可比较、可留存的数值。下面三条命令分别对应显存、利用率、进程三个维度，建议在排障时按顺序执行并记录输出。

# 1) 显存与利用率快照（单位 MB / %，便于脚本比对）
nvidia-smi --query-gpu=index,name,memory.total,memory.used,utilization.gpu \
           --format=csv,noheader,nounits

# 2) 占用 GPU 的计算进程（PID 是主键）
nvidia-smi --query-compute-apps=gpu_uuid,pid,process_name,used_memory \
           --format=csv,noheader,nounits

# 3) 连续采样，观察利用率是否“假高”
for i in $(seq 1 10); do
  nvidia-smi --query-gpu=timestamp,utilization.gpu,memory.used \
             --format=csv,noheader,nounits
  sleep 1
done

判读要点：第 2 条命令返回的 PID 必须能在 ps 中找到。如果显存显示被占用，但 --query-compute-apps 返回空列表，或返回的 PID 在 ps -p <pid> 中已不存在，就属于典型的残留上下文——显存由驱动侧持有，进程实体已消失。

进程树与日志：确认“谁留下的”

拿到可疑 PID 后，不要直接 kill。先用进程树确认它是否还有存活的父/子进程，避免只杀掉子进程而父进程继续拉起新任务。

# 查看可疑 PID 的完整命令行与父子关系
ps -o pid,ppid,stat,etime,cmd -p <pid>
pstree -p <ppid> 2>/dev/null || ps --forest -o pid,ppid,cmd -g $(ps -o sid= -p <pid>)

# 若 PID 已不存在，从日志反查残留任务
grep -n "<pid>" /var/log/syslog 2>/dev/null | tail -20
journalctl -k --since "2 hours ago" | grep -i -E "nvrm|xid|oom"

判断依据：STAT 列出现 Z 表示僵尸进程（已退出但父进程未回收）；etime 很长而利用率长期为 0，说明任务卡死或空转；日志中出现 Xid 错误码则说明 GPU 侧发生过异常，残留上下文往往与此相关。

安全清理的判定与执行

清理必须满足两个前提：确认该 PID 不属于他人正在运行的有效任务，且相关 checkpoint 已落盘或可接受丢失。满足后按“先软后硬”的顺序处理：

1. 对残留进程发送 SIGTERM：kill -TERM <pid>，等待 5–10 秒。
2. 重新执行 nvidia-smi --query-gpu=memory.used --format=csv,noheader，确认显存是否回落。
3. 若显存未释放且进程已不存在，说明是驱动侧残留上下文，此时单纯 kill 无效，需要重置对应 GPU 或重启相关服务；多卡环境可用 nvidia-smi -i <index> --gpu-reset（需无进程占用且具备权限）。
4. 清理后再次采样利用率与显存，确认回到基线值，并记录本次 PID、命令行、日志片段作为复盘依据。