GPU的运维与管理

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 上的所有应用程序都已受到影响。

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/lib

5 显存无法释放

执行命令：

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 -p

7 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