利用ms-swift监控系统PID列表识别异常训练进程-育师

利用 ms-swift 监控系统 PID 列表识别异常训练进程

在大规模模型训练的日常运维中，最令人头疼的问题之一就是“任务看似还在跑，但其实早已卡死”。日志不再更新、GPU 利用率归零、显存却迟迟不释放——这类“假死”现象往往不会触发程序崩溃，也不会立即被监控系统捕获，等到发现时可能已经浪费了数小时甚至数天的计算资源。

尤其是在使用分布式训练框架进行大模型微调时，一个子进程的阻塞可能导致整个训练作业停滞。而传统的日志轮询或指标上报机制常常滞后，难以及时响应这种低层次的系统级异常。于是，我们不得不把目光从应用层下探到操作系统层面：有没有一种方式，可以在不侵入代码的前提下，快速识别出那些“活着但已无用”的训练进程？

答案是肯定的——通过监控ms-swift框架启动的训练任务所对应的系统 PID，并结合 Linux 原生工具链进行状态分析，我们可以构建一套轻量、高效且通用的异常检测机制。

为什么选择 ms-swift？

ms-swift 并非只是一个简单的训练脚手架，它本质上是一个深度集成操作系统行为的大模型工程化平台。它的设计哲学决定了其具备天然的“可观测性优势”：每一个训练任务都会在系统中留下清晰的痕迹——主进程 PID、子进程树结构、命令行参数特征以及与 GPU 的绑定关系。

当你执行如下命令启动一次 Qwen3 模型的微调任务时：

python -m swift.train --model qwen/Qwen3-7B --dataset alpaca-en --output_dir ./ckpt

ms-swift 实际上会做几件事：
1. 创建一个 Python 主进程；
2. 根据配置派生多个子进程（如 DataLoader Worker、分布式通信线程）；
3. 在内部注册当前os.getpid()并关联任务元数据；
4. 启动 PyTorch 或 DeepSpeed 训练循环。

这个主进程的 PID 成为了整个训练作业的“根节点”，所有后续资源消耗都可以通过进程父子关系追溯至此。更重要的是，ms-swift 对启动命令有较强的规范性，比如通常包含swift.train、python和模型名称等关键字，这为我们后期通过ps进行模式匹配提供了便利。

如何利用 PID 实现异常检测？

Linux 系统为每个运行中的进程分配唯一的 PID，并通过/proc/[pid]/提供实时的运行时信息。这意味着我们不需要依赖任何第三方库或修改模型代码，就能获取以下关键指标：

CPU 使用率（%CPU）
内存占用（RSS / VSZ）
进程状态（Running, Sleeping, Zombie）
打开文件描述符数量
GPU 占用情况（配合nvidia-smi）

从一条命令开始：定位你的训练进程

最基础的操作是从终端查看当前是否存在预期的训练任务：

ps aux | grep -E 'swift|train|qwen'

这条命令会列出所有可能相关的进程。你可能会看到类似输出：

aiuser 12345 85.2 12.1 15.6g 4.2g TTY Sl+ 10:30 2:15 python -m swift.train --model qwen/Qwen3-7B ... aiuser 12346 0.0 0.1 0 0 ? Z 10:30 0:00 [python] <defunct> aiuser 12347 3.1 1.2 2.1g 800m TTY S+ 10:30 0:02 python data_loader.py

注意第二行的状态Z——这是一个典型的僵尸进程，说明某个子进程退出后父进程未正确回收。虽然它本身不消耗资源，但大量积累会影响系统稳定性。

再看第一行的%CPU达到了 85%，表明该进程正在活跃工作；但如果某次巡检中发现该值长期低于 1%，而训练尚未结束，则极有可能发生了卡顿。

结合 GPU 监控，精准定位问题源头

很多时候，训练卡顿并非 CPU 或内存导致，而是 GPU 上下文异常或显存泄漏。此时nvidia-smi是不可或缺的工具：

nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

输出示例：

pid, process_name, used_memory [MiB] 12345, python, 16280

现在你可以将这里的 PID12345回代到ps命令中，确认其命令行是否仍属于正常任务：

ps -p 12345 -o pid,ppid,%cpu,%mem,cmd --no-headers

如果结果显示%CPU < 1%但显存仍然高达 16GB，那基本可以断定：这个进程已经失去计算能力，但仍霸占着宝贵的 GPU 资源。

构建自动化监控脚本

手动检查适用于临时排查，但在多节点集群环境中必须实现自动化。下面是一个实用的 Bash 脚本，可用于定时巡检并记录可疑进程：

#!/bin/bash LOG_FILE="/var/log/ms-swift-monitor.log" echo "$(date): 开始检测 ms-swift 训练进程" >> "$LOG_FILE" # 查找所有疑似 ms-swift 训练主进程 PIDS=$(ps aux | grep 'swift.train' | grep -v grep | awk '{print $2}') if [ -z "$PIDS" ]; then echo "WARNING: 未检测到 ms-swift 训练进程，可能存在中断！" >> "$LOG_FILE" exit 0 fi for pid in $PIDS; do # 检查进程是否存在 if ! kill -0 "$pid" 2>/dev/null; then echo "ALERT: PID $pid 已不存在，可能已被强制终止。" >> "$LOG_FILE" continue fi # 获取进程状态 state=$(cat /proc/$pid/status 2>/dev/null | grep State | awk '{print $2}') cpu=$(ps -p "$pid" -o %cpu --no-headers | xargs) mem=$(ps -p "$pid" -o %mem --no-headers | xargs) cmd=$(ps -p "$pid" -o args --no-headers) # 判断是否为僵尸进程 if [[ "$state" == "Z" ]]; then echo "CRITICAL: PID $pid 已变为僵尸进程！需手动清理：$cmd" >> "$LOG_FILE" continue fi # 判断 CPU 使用率过低 if (( $(echo "$cpu < 1.0" | bc -l) )); then gpu_mem=$(nvidia-smi --query-compute-apps=pid,used_memory --format=csv,noheader | grep "^$pid," | cut -d',' -f2 | tr -d ' MiB') if [ -n "$gpu_mem" ] && [ "$gpu_mem" -gt 1000 ]; then echo "ALERT: PID $pid CPU 使用率过低 ($cpu%) 但显存占用高 ($gpu_mem MiB)，疑似卡死：$cmd" >> "$LOG_FILE" fi fi done

你可以将此脚本加入 cron 定时任务，例如每 5 分钟运行一次：

*/5 * * * * /path/to/monitor_swift_pids.sh

进一步地，还可以接入钉钉、企业微信或 Prometheus 推送告警，实现闭环运维。

典型故障场景与应对策略

场景一：AllReduce 死锁导致进程挂起

现象：训练日志停止输出，nvidia-smi显示 GPU 利用率为 0%，但显存未释放。

诊断步骤：
1. 使用ps找到对应 PID；
2. 执行gdb attach [pid]查看调用栈：
bash gdb -p 12345 -ex "thread apply all bt" -ex "detach" -ex "quit"
3. 若发现多个线程阻塞在ncclAllReduce或torch.distributed.reduce，则基本可判定为通信死锁。

建议处理方式：
- 检查网络带宽和 RDMA 配置；
- 升级 NCCL 版本；
- 设置超时机制（如torch.distributed.init_process_group(timeout=...)）；
- 自动重启策略中增加重试次数限制，避免无限循环。

场景二：数据加载器引发资源泄漏

现象：RSS 内存持续增长，最终触发 OOM Killer 杀死进程。

原因分析：PyTorch 的DataLoader若设置过大的num_workers，且数据预处理函数存在引用循环或全局缓存泄露，会导致子进程无法正常退出。

解决方案：
- 将num_workers控制在合理范围（一般 ≤ CPU 核心数）；
- 在 Dataset 中避免使用类变量存储大数据；
- 启用worker_init_fn清理随机种子或临时状态；
- 使用tracemalloc或memray进行内存剖析。

同时可通过监控/proc/[pid]/smaps文件来观察内存段变化趋势。

场景三：训练结束后残留僵尸进程

现象：任务已结束，但ps仍显示[python] <defunct>。

根本原因：父进程未调用wait()回收子进程退出状态。

修复方向：
- 在训练脚本末尾显式调用torch.multiprocessing.cleanup()；
- 使用上下文管理器确保子进程正确关闭；
- 部署时启用systemd服务单元自动清理孤儿进程组。

最佳实践建议

为了让 PID 监控更有效，我们在设计和部署训练任务时应遵循以下原则：

1. 统一命名与标签化启动

建议在启动命令中加入可识别的任务标签：

python -m swift.train --model qwen/Qwen3-7B --task sft-chat --tag projA-v1

这样在ps输出中就能一眼识别任务归属，便于过滤和聚合。

2. 使用 cgroups 限制资源上限

防止单个任务失控影响整机性能：

cgcreate -g memory:/swift-task-1 echo $((20 << 30)) > /sys/fs/cgroup/memory/swift-task-1/memory.limit_in_bytes cgexec -g memory:swift-task-1 python -m swift.train ...