2. Linux基础回顾
核心原理：一切皆文件与命令行哲学
Linux运维的底层逻辑建立在“一切皆文件”的设计思想上。无论是普通数据、磁盘分区、硬件设备、进程间通信管道，还是网络套接字，都被抽象为文件或类文件对象。这意味着我们可以用统一的 open/read/write/close 语义去操作几乎所有系统资源。对于GPU集群运维而言，理解这一原理至关重要：nvidia-smi 读取的是 /dev/nvidia* 设备文件与内核驱动接口，而GPU进程的显存占用则体现在 /proc 虚拟文件系统中。
命令行操作遵循“组合小工具完成复杂任务”的哲学。每个命令只做一件事，通过管道 |、重定向 >、>> 和命令替换 $(...) 将多个工具串联成强大的处理流水线。在GPU集群场景中，我们经常需要将 nvidia-smi 的输出与 awk、grep 结合，快速提取显存使用率或GPU温度等关键指标。
核心命令速查清单
- 文件系统：
ls、cd、pwd、mkdir、rm、cp、mv、ln、df、du、mount - 权限管理：
chmod、chown、chgrp、umask、setfacl、getfacl - 进程管理：
ps、top、htop、kill、pkill、jobs、fg、bg、nohup、systemctl - 网络配置：
ip、ss、ping、traceroute、curl、scp、rsync、ethtool
方法流程：从查看到定位再到修复
在GPU集群运维中，命令操作遵循“查看→定位→修复”的三步流程。以最常见的“GPU显存不足”问题为例：首先使用 nvidia-smi 查看整体显存占用，然后通过 ps -ef | grep python 定位占用显存的进程PID，最后使用 kill -9 PID 或 kill -15 PID 结束异常进程。这一流程贯穿所有运维场景。
文件系统操作是第一步。GPU节点通常挂载共享存储（如NFS、Lustre），用于存放训练数据集和模型权重。使用 df -h 查看磁盘空间，du --max-depth=1 /data 分析目录占用，mount | grep nfs 确认远程挂载状态。当训练中断报“No space left on device”时，往往不是本地磁盘满，而是共享存储的inode耗尽，此时需要 df -i 查看inode使用率。
权限管理是GPU集群最常见的故障源。GPU设备文件 /dev/nvidia* 默认属于 root:root，普通用户无法直接访问。容器运行时（如Docker、Singularity）通过设备cgroup和用户命名空间映射权限。当用户报“CUDA error: no kernel image available”时，除了驱动不匹配，更常见的是设备文件权限错误。使用 ls -l /dev/nvidia* 检查权限位，chmod 666 /dev/nvidia* 临时开放（不推荐生产环境），正确做法是配置udev规则或使用ACL。
# 查看GPU设备文件权限
ls -l /dev/nvidia*
# crw-rw-rw- 1 root root 195, 0 2月 28 10:00 /dev/nvidia0
# 查看当前用户是否在video组（通常GPU设备属于该组）
groups $USER
# 若不在，添加用户到video组
sudo usermod -aG video $USER
# 使用ACL精细控制（推荐）
sudo setfacl -m u:training_user:rw /dev/nvidia0
getfacl /dev/nvidia0案例实战：多用户GPU节点权限配置
某AI实验室有一台8卡A100节点，20名研究员共享使用。初期所有用户都能访问全部GPU，导致资源争抢严重。管理员决定按项目组划分GPU权限：A组使用GPU 0-3，B组使用GPU 4-7。
实施步骤如下：
- 创建用户组
groupadd gpu_a和groupadd gpu_b，将对应用户加入组。 - 编写udev规则，为不同GPU设备设置不同的组所有权：
# /etc/udev/rules.d/99-gpu-permissions.rules
# GPU 0-3 属于 gpu_a 组
KERNEL=="nvidia[0-3]", MODE="0660", GROUP="gpu_a"
# GPU 4-7 属于 gpu_b 组
KERNEL=="nvidia[4-7]", MODE="0660", GROUP="gpu_b"
# 控制设备（/dev/nvidiactl）所有组可读
KERNEL=="nvidiactl", MODE="0660", GROUP="video"
# 重新加载udev规则
sudo udevadm control --reload-rules
sudo udevadm trigger同时，管理员通过 systemd-run 为每个用户的训练任务设置CPU和内存限制，防止单用户耗尽节点资源。进程管理方面，使用 ps -eo pid,user,pcpu,pmem,comm --sort=-pcpu | head -20 定期检查资源占用，发现异常进程立即处理。
进程管理黄金法则：在GPU节点上，永远不要使用 kill -9 结束训练进程，除非确认该进程已无响应。正确顺序是：先 kill -15（SIGTERM）让进程有机会保存模型checkpoint，等待5秒后若仍未退出，再使用 kill -9。对于PyTorch分布式训练，还需注意结束所有关联进程（pkill -f "python.*distributed"），否则会残留GPU显存占用。
网络配置与多节点通信
GPU集群的网络配置直接影响分布式训练效率。现代GPU服务器通常配备多个网络接口：管理网口（1GbE）、数据网口（10/25/100GbE）、以及GPU直连的RDMA网卡（如InfiniBand或RoCE）。使用 ip link show 查看所有接口，ethtool eth0 检查链路速率和协商状态。
分布式训练（如NCCL）依赖高带宽低延迟网络。当NCCL通信超时或报错时，首先检查 ibstat（InfiniBand状态）或 rdma link show（RoCE状态），确认RDMA链路正常。然后使用 ping -M do -s 8972 测试大包连通性（MTU 9000），因为NCCL默认使用大包传输。
# 查看所有网络接口和IP
ip addr show
# 查看TCP连接状态（排查NCCL通信端口）
ss -tunlp | grep -E "29500|24000"
# 测试GPU节点间RDMA带宽（需安装perftest）
ib_write_bw -d mlx5_0 -F 192.168.1.101
# 查看路由表确认流量走向
ip route show| 命令 | 用途 | GPU运维场景 |
|---|---|---|
nvidia-smi | 查看GPU状态 | 显存、温度、利用率监控 |
ps -ef | 查看进程 | 定位占用GPU的PID |
lsof /dev/nvidia* | 查看文件占用 | 找出哪个进程打开了GPU设备 |
ip -s link | 接口统计 | 检查网卡丢包和错误计数 |
ss -s | 套接字汇总 | 排查端口耗尽问题 |
dmesg | grep -i nvidia | 内核日志 | 查看驱动加载和GPU错误 |
误区与复盘：常见操作陷阱
高频误区一：盲目使用 chmod 777。在GPU节点上开放所有设备文件权限，虽然解决了眼前访问问题，但任何用户都能直接操作GPU，包括重置GPU（nvidia-smi --gpu-reset）或读取他人显存数据（通过CUDA peer-to-peer）。正确做法是使用udev规则或ACL实现最小权限分配。
高频误区二：混淆 kill 与 pkill 的匹配范围。pkill -f python 会匹配命令行中包含“python”的所有进程，可能误杀系统服务。在GPU集群中，建议先 pgrep -af python 查看完整匹配列表，确认无误后再执行终止。
高频误区三：忽略 /proc 虚拟文件系统。GPU进程的显存占用、打开的文件描述符、环境变量等关键信息都可通过 /proc/<PID>/ 查看。例如 cat /proc/<PID>/status | grep VmRSS 可查看进程实际物理内存，ls -l /proc/<PID>/fd | grep nvidia 可确认进程是否已正确打开GPU设备。
复盘一次真实故障：某节点重启后，所有用户报“CUDA initialization failed”。管理员执行 dmesg | grep -i nvidia 发现驱动加载失败，原因是内核升级后NVIDIA驱动模块未重新编译。解决方法是重新安装匹配内核版本的驱动，或使用 dkms 自动重建模块。这一案例说明，GPU集群运维不仅是命令操作，更需要理解驱动、内核、设备文件之间的依赖关系。
最后，建立运维命令速查手册和定期巡检脚本是提升效率的关键。将常用检查命令封装为 gpu_health.sh 脚本，定时执行并输出JSON格式结果，便于接入监控系统。Linux命令本身是工具，真正的价值在于理解系统运行机制后，用正确的工具解决正确的问题。