1 XID 错误事件
XID 是 NVIDIA 的错误码，可以通过命令:
dmesg -T | grep -i "NVRM: Xid"根据 XID 可以定位故障，下面是一些常见的 XID 事件：
| XID | 说明 |
|---|---|
| 13 | Graphics Engine Exception。通常是数组越界、指令错误,小概率是硬件问题。 |
| 31 | GPU memory page fault。通常是应用程序的非法地址访问,极小概率是驱动或者硬件问题。 |
| 43 | GPU stopped processing。通常是用户应用自身错误而非硬件问题。 |
| 45 | Preemptive cleanup, due to previous errors – Most likely to see when running multiple cuda applications and hitting a DBE。通常是用户手动退出或者其他故障(硬件、资源限制等)导致 GPU 应用退出,Xid 45 只是一个结果,通常需要分析日志。 |
| 68 | NVDEC0 Exception。通常是硬件或驱动问题。 |
| 32 | Invalid or corrupted push buffer stream。事件由 PCIE 总线上管理 NVIDIA 驱动和 GPU 之间通信的 DMA 控制器上报,通常是 PCI 质量问题导致,而非用户程序产生。 |
| 38 | Driver firmware error。通常是驱动固件错误而非硬件问题。 |
| 48 | Double Bit ECC Error(DBE)。当 GPU 发生不可纠正的错误时,会上报 Xid48 事件。该错误也会同时反馈给用户的应用程序。通常需要重置 GPU 或重启节点来清除这个错误。 |
| 61 | Internal micro-controller breakpoint/warning。GPU 内部引擎停止工作,客户业务已经受到影响。 |
| 62 | Internal micro-controller halt。与 Xid61 的触发场景类似。 |
| 63 | ECC page retirement or row remapping recording event。当应用程序遭遇到 GPU 显存硬件错误时,NVIDIA 自纠错机制会将错误的内存区域 retire 或者 remap,retirement 和 remapped 信息需要记录到 infoROM 中才能永久生效。Volt 架构:记录 ECC page retirement 事件到 infoROM 成功。Ampere 架构:记录 row remapping 事件到 infoROM 成功 |
| 64 | ECC page retirement or row remapper recording failure。与 Xid63 的触发场景类似,只是 Xid63 代表 retirement 和 remapped 信息成功记录到了 infoROM,Xid64 代表该记录操作失败。 |
| 74 | NVLINK Error。NVLink 硬件错误产生的 Xid,收到此事件说明 GPU 已经出现严重硬件故障,需要下线维修。 |
| 79 | GPU has fallen off the bus。GPU 硬件检测到掉卡,无法从总线上检测到,收到此事件说明 GPU 已经出现严重硬件故障,需要下线维修。 |
| 92 | High single-bit ECC error rate。硬件或驱动故障。 |
| 94 | Contained ECC error。当应用程序遭遇到 GPU 不可纠正的显存 ECC 错误时,NVIDIA 错误抑制机制会尝试将错误抑制在踩到硬件故障的应用程序,而不会让错误导致 GPU 上的所有应用程序受到影响。当抑制机制成功抑制错误时,会产生 Xid 94 事件,仅影响遭遇了不可纠正 ECC 错误的应用程序。 |
| 95 | Uncontained ECC error。与 Xid94 的触发场景类似。只是 Xid94 代表抑制成功,而 Xid95 代表抑制失败,此时表明运行在该 GPU 上的所有应用程序都已受到影响。 |
详情参考 XID Errors :: GPU Deployment and Management Documentation
2 GPU 过高
通常 GPU 温度应该在 85°C 以下，超过时会出现锁频性能下降的问题。执行以下命令，能直接看到 GPU 编号及温度。
nvidia-smi --query-gpu=index,temperature.gpu --format=csv,noheader
0, 28
1, 40
2, 44
3, 30
4, 27
5, 27
6, 31
7, 32解决方案:
除了一些物理的方法，从纯软件层考虑，可以直接将温度超过阈值的 GPU 上面的应用程序杀掉，使其更换到其他的 GPU 上。
3 重启掉卡，nvswitch 报错
systemctl status nvidia-fabricmanager.service或者
less /var/log/fabricmanager.log | grep error看到有 NVlink、NVSwitch 报错，或者报nvidia-smi 找不到 device handle，Unknown Error 错误，或者重启之后少卡。
解决方案:
启用 nvidia-persistenced 持久模式，让驱动程序保持加载状态，可以很大幅度的缓解这个问题。
4 Pod 中 nvidia-smi 报错 Function not Found
在 Pod 中执行命令报错:
nvidia-smi
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.129.03 Driver Version: 535.129.03 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA TITAN X (Pascal) On | 00000000:03:00.0 Off | N/A |
| 23% 26C P8 8W / 250W | Function Not Found | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+因为 Pod 中的 cuda 版本过低，与节点上的 cuda 版本不匹配。
解决办法:
加上环境变量，重启应用：
LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib/x86_64-linux-gnu:/usr/local/nvidia/lib5 显存无法释放
执行命令：
nvidia-smi
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA A800-SXM4-80GB On | 00000000:10:00.0 Off | 0 |
| N/A 32C P0 68W / 400W | 42058MiB / 81920MiB | 0% Default |
| | | Disabled |
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
+---------------------------------------------------------------------------------------+
会看到没有进程使用显卡，但是显存依然被大量占用。
同时可以发现有一批杀不死的僵尸进程。
ps aux | grep -E '\<defunct\>'
root 966461 0.0 0.0 6432 2488 pts/0 S+ 11:30 0:00 grep --color=auto -E \<defunct\>
root 2215172 0.0 0.0 0 0 ? Zl Apr04 1:10 [python] <defunct>
root 2215428 0.0 0.0 0 0 ? Zl Apr04 0:00 [python] <defunct>
root 2215442 0.0 0.0 0 0 ? Zl Apr04 0:00 [python] <defunct>解决办法:
依次尝试重启 Kubelet、Docker、主机，即可释放显存资源。
6 Docker Hang 住，节点 NotReady
在 Kubelet 中看到 PLEG is not healthy 相关错误日志。在 Docker 中没有异常日志。
可能是 runc hang 住了，因为 pipe 默认大小只有 64 MB，对于高性能计算场景不够用。
解决办法：
设置为 1GB，这里设置的是 262144 * 4K = 1GB。
echo "fs.pipe-user-pages-soft=262144" >> /etc/sysctl.conf && sysctl -p7 df/ls命令hang 住, 无法响应
查看 hang 住的进程
strace df -h
stat("/data/kubelet/pods/af4c411c-bafa-4322-9a21-e5c60ab1658e/volumes/kubernetes.io~nfs/workspace-pv",找到相关的 mount point
mount | grep mmt-10289-v2-1-4
1.1.1.1:/cfs-fSfmHNQjNA/workspace on /data/kubelet/pods/af4c411c-bafa-4322-9a21-e5c60ab1658e/volumes/kubernetes.io~nfs/workspace-pv type nfs (ro,relatime,vers=3,rsize=131072,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.8.254.230,mountvers=3,mountport=300,mountproto=tcp,local_lock=none,addr=10.8.254.230)确认目录已经不可使用：
ls /data/kubelet/pods/af4c411c-bafa-4322-9a21-e5c60ab1658e/volumes/kubernetes.io~nfs/workspace-pv此时应该 hang 住无法响应。通常是远端服务 1.1.1.1 已经无法访问，但挂载的客户端未清理导致。
强行卸载目录：
umount -f /data/kubelet/pods/af4c411c-bafa-4322-9a21-e5c60ab1658e/volumes/kubernetes.io~nfs/workspace-pv
