常用 GPU 运维及故障处理

处理故障时，参考或者记录下的内容，持续更新中

1. XID 错误事件

XID 是 NVIDIA 的错误码，可以通过命令:

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

详情参考 https://docs.nvidia.com/deploy/xid-errors/index.html

2. GPU 过高

通常 GPU 温度应该在 85°C 以下，超过时会出现锁频性能下降的问题。执行以下命令，能直接看到 GPU 编号及温度。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
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 报错

1
systemctl status nvidia-fabricmanager.service

或者

1
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 中执行命令报错:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
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 版本不匹配。

解决办法:

加上环境变量，重启应用。

1
LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib/x86_64-linux-gnu:/usr/local/nvidia/lib

5. 显存无法释放

执行命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
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      |
|=======================================================================================|
+---------------------------------------------------------------------------------------+

会看到没有进程使用显卡，但是显存依然被大量占用。

同时可以发现有一批杀不死的僵尸进程。

1
2
3
4
5
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

1
echo "fs.pipe-user-pages-soft=262144" >> /etc/sysctl.conf && sysctl -p

7. df\ls hang 住, 无法响应

查看 hang 住的进程

1
2
3
strace df -h

stat("/data/kubelet/pods/af4c411c-bafa-4322-9a21-e5c60ab1658e/volumes/kubernetes.io~nfs/workspace-pv",

找到相关的 mount point

1
2
3
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)

确认目录已经不可使用

1
ls /data/kubelet/pods/af4c411c-bafa-4322-9a21-e5c60ab1658e/volumes/kubernetes.io~nfs/workspace-pv

此时应该 hang 住无法响应。通常是远端服务 1.1.1.1 已经无法访问，但挂载的客户端未清理导致。

强行卸载目录

1
umount -f /data/kubelet/pods/af4c411c-bafa-4322-9a21-e5c60ab1658e/volumes/kubernetes.io~nfs/workspace-pv

8. 磁盘 df 与 du 数据严重不符

使用 df 查看发现 / 使用了 86%。

1
2
3
4
df -h

Filesystem               Size  Used Avail Use% Mounted on
/dev/sda3                435G  352G   62G  86% /

但使用 df 统计却只有很少使用量

1
2
3
du -h --max-depth=2 --exclude=/data --exclude=/data1 --exclude=/var/lib/juicefs/volume / | grep '[0-9.]\+G'

32G	/

原因是，删除大文件时，依然有程序占用文件，导致内核无法回收空间。

解决办法:

找出程序占用的文件

1
lsof -n | grep deleted

删除程序占用的文件

1
lsof -n | grep deleted | awk '{print $2}' | sort -u | xargs sudo kill -9

9. 使用 ipmitool 重启主机

使用 reboot 命令重启主机，只是系统层面，有些硬件故障不能恢复。

1
ipmitool chassis power cycle

相当于断电重启。

10. version mismatch

1
2
3
4
nvidia-smi

Failed to initialize NVML: Driver/library version mismatch
NVML library version: 535.129

1
2
3
4
5
modinfo nvidia | grep version

version:        535.183.01
srcversion:     E1D7E062E93D47A443165F6
vermagic:       5.4.0-1131-oracle SMP mod_unload modversions

解决办法：

卸载 nvidia driver 之后，重新安装

1
2
3
apt-get --purge remove "*cublas*" "cuda*"
apt-get --purge remove "*nvidia*"
apt autoremove

11. no free node

使用 https://github.com/tkestack/gpu-manager 对 GPU 进行管理，需要注意驱动的版本不能太高，比如 535.183 无法兼容。

我们测试的可兼容版本是 535.129。

使用高版本驱动时，显存分配之后，无法正常回收，导致第一次分配完成之后，新 Pod 创建时会报错 no free node。

根本原因在于，gpu-manager 没有兼容新版本的 nvml 无法获取到实时的显存信息。

12. 企业版 JuiceFS 速度剧烈波动

在预热之后，访问速度应该能够平稳、较快，但如果 P2P 缓存服务节点组中，有访问慢的节点，会导致访问速度局部下降，拉低整体的访问速度。

可以进入 fluid 的 worker pod。

1
2
3
ps aux | grep jfsmount

root         190 47.8  0.0 6160996 397776 ?      S<l  Sep13 673:59 /usr/local/juicefs/mount/jfsmount myjuicefs-storage /runtime-mnt/juicefs/mynamespace/myjuicefs-storage-fluid/juicefs-fuse -o cache-group=mynamespace-myjuicefs-storage-fluid,cache-size=5242880,free-space-ratio=0.1,cache-dir=/data1/jfs/cache:/data/jfs/cache,foreground,no-update

查看 P2P 缓存服务节点组之间的连接

1
lsof -p 190

排查是否有慢、不符合预期的节点，剔除相关节点即可恢复。

13. resolv.conf: no such file or directory

Pod 起不来，报错:

1
/run/systemd/resolve/resolv.conf: no such file or directory

解决办法:

1
vim /var/lib/kubelet/kubeadm-flags.env

在 KUBELET_KUBEADM_ARGS 中修改 --resolv-conf=/etc/resolv.conf。

然后重启 kubelet:

1
2
systemctl daemon-reload
systemctl restart kubelet

14. 升级节点 CPU 之后 kublet 起不来

报错信息

1
start cpu manager error: current set of available CPUs \"0-7\" doesn't match with CPUs in state \"0-3\"

解决办法:

1
2
3
rm /var/lib/kubelet/cpu_manager_state
systemctl daemon-reload
systemctl restart kubelet