常见GPU故障类型与解决方案

在Kubernetes环境中,GPU资源的管理复杂度高、故障诊断和恢复难度大,且宕机成本高。出现故障时,您需要正确识别问题(硬件、驱动、配置等问题),快速采取恰当的恢复措施,以最小化对终端用户的影响。本文介绍常见的GPU故障类型及对应解决方案,以便您快速响应故障,最大限度地减少宕机时间,保障业务应用的连续性和高性能。

GPU资源管理面临的挑战

  • 管理复杂:相较于常规的CPU和内存资源,在Kubernetes环境中,GPU资源不能通过简单的原生Kubernetes API进行管理,通常需要集成额外的设备插件,管理复杂度高。

  • 故障诊断和恢复难度大:相较于传统硬件设备,由于GPU本身的特殊性和复杂的依赖关系(例如对驱动程序和库版本的依赖),GPU资源的故障诊断和恢复工作难度更大。

  • 宕机成本高:相较于普通ECS实例,GPU实例单价通常较高且库存供应更为有限。任何与GPU相关的故障均可能引发高昂的系统宕机成本。

GPU故障类型

在Kubernetes集群环境中,GPU故障大致分为如下几类。

故障类型

说明

硬件故障

GPU物理组件发生的故障,可能涉及GPU芯片、显存、风扇、电源或其他硬件部位。包括:

驱动故障

GPU驱动程序问题,包括安装错误、版本不兼容(操作系统版本,内核版本、容器运行时等)、驱动本身缺陷等。包括:

容器化环境故障

包括NVIDIA Container Runtime、Device Plugin等组件出现问题。包括:

应用故障

GPU应用引起的故障,例如GPU越界内存访问、Pod配置出错等。包括:

cGPU故障

cGPU模块出现的问题,例如内核升级导致的编译版本过期等。其中包括内核升级导致的编译版本过期

说明

本文部分故障来自于XID错误报告。

展开查看XID介绍

NVIDIA GPU的XID(X Display Identification)机制是一种错误报告协议,用于诊断和报告GPU在运行时遇到的不同类型的错误。当GPU检测到潜在的硬件、软件或驱动程序问题时,会生成一个XID错误消息,并将信息保存在系统日志中(例如,在Linux系统中路径通常为/var/log/messages或/var/log/syslog)。

每个XID错误消息都包括一个唯一的数字代码,代表了不同故障类型,包括内存错误、热量或功率异常、驱动程序故障、PCI总线错误、视频输出问题等等。NVIDIA提供了XID错误代码列表,帮助终端用户和开发者快速定位问题并采取适当的故障排除步骤。关于XID的更多信息,请参见XID Errors

硬件故障

GPU硬件故障指由于设备损坏、老化或者其他物理原因而导致的GPU工作异常或者完全失效的情况。硬件故障可能会导致算力下降、系统崩溃、图形输出错误等问题。在ACK集群中,尤其在执行深度学习、科学计算或任何高性能并行计算任务时,GPU硬件故障会对依赖GPU资源的应用产生重大的影响。

XID错误表明的硬件故障

故障描述

以下列举一些较为常见的XID的错误以及其错误原因。关于XID的更多信息,请参见XID Errors

XID

错误说明

32

Invalid or corrupted push buffer stream. 事件由PCIe总线上管理NVIDIA驱动和GPU之间通信的DMA控制器上报。通常是PCI质量问题导致,而非应用程序导致。

61

Internal micro-controller breakpoint/warning. GPU内部引擎已停止工作,业务已经受到影响。

62

Internal micro-controller halt. 与XID 61的触发场景类似。

63

ECC page retirement or row remapping recording event. 当应用程序遭遇GPU显存硬件错误时,NVIDIA自纠错机制会将错误的内存区域retire(系统不再使用这部分内存)或者remap(将数据从发生错误的内存位置移动到一个健康的内存位置)。

Retirement和Remapped信息需要记录到infoROM(信息只读存储器)中才能永久生效。

  • Volt架构:成功记录ECC page retirement事件到infoROM时,NVIDIA的自纠错机制被视为成功执行。

  • Ampere架构:成功记录row remapping事件到infoROM时,NVIDIA的自纠错机制被视为成功执行。

64

ECC page retirement or row remapper recording failure. 与XID 63的触发场景类似,只是XID 63代表Retirement和Remapped信息成功记录到了 infoROM,XID 64代表该记录操作失败。

74

NVLINK Error. 由NVLink硬件错误导致的问题,说明GPU已经出现严重的硬件故障,需要下线维修。

79

GPU has fallen off the bus. GPU硬件检测到掉卡,即从PCIe总线上断开连接,导致系统无法检测此GPU卡。收到此事件说明GPU已经出现严重硬件故障,需要下线维修。

如需检查节点上是否产生XID错误,您需要登录该节点,然后执行如下命令。

grep "NVRM: Xid" -B 1 /var/log/messages

如果没有内容输出,则表明没有XID错误。

如果有内容输出,则表明有XID错误产生。示例如下。

[…] NVRM: GPU at 0000:03:00: GPU-b850f46d-d5ea-c752-ddf3-c4453e44d3f7 
[…] NVRM: Xid (PCI:0000:03:00): 14, Channel 00000001 

预期输出表明,GPU产生XID为14的错误,其BUS ID为0000:03:00,其GPU ID为GPU-b850f46d-d5ea-c752-ddf3-c4453e44d3f7。

解决方案

提交工单联系容器服务技术支持。

GPU设备无法识别

故障描述

GPU设备无法识别指在PCIe总线上无法识别某GPU设备,或者识别到的状态有误。

您可以在节点上利用lspci命令的输出来确保所有GPU设备的识别正常。如果每个GPU末尾标识为(rev a1),则表明该设备可以正常被PCIe识别;如果输出信息末尾为(rev ff),则表明GPU设备在总线上的识别异常。

设备识别异常的示例如下。

$ lspci | grep NVIDIA

00:07.0 3D controller: NVIDIA Corporation GV100GL [Tesla V100 SXM2 32GB] (rev ff)

解决方案

提交工单联系容器服务技术支持。

GPU设备带宽异常

故障描述

在GPU节点上,需要确保GPU对当前带宽与额定带宽一致且为x16。您可以使用lspci命令进行检测。当前带宽和额定带宽的检测命令分别为:

  • 额定带宽:lspci -vvd 10de: | grep -i Lnkcap:

  • 当前带宽:lspci -vvd 10de: | grep -i Lnksta:

示例如下。

# 额定带宽
$ lspci -vvd 10de: | grep -i Lnkcap:
		LnkCap:	Port # 8, Speed 8GT/s, Width x16, ASPM not supported

# 当前带宽
$ lspci -vvd 10de: | grep -i Lnksta:
		LnkSta:	Speed 8GT/s (ok), Width x16 (ok)

解决方案

提交工单联系容器服务技术支持。

NVIDIA-SMI发现的硬件问题

故障描述

如果在节点上执行nvidia-smi的结果中发现Fan ERR或Power Usage ERR,表明GPU出现了硬件故障。

  • Fan ERR:GPU的风扇出现了故障,可能会进一步导致GPU温度过高甚至GPU设备出现问题。

  • Power Usage ERR:GPU的电源供应可能存在问题,可能是因为电源线未连接好、电源适配器故障、电源输出不稳定或电源容量不足等原因。如果GPU无法获得足够的电源供应,可能会导致系统不稳定,显卡可能会频繁重置、性能下降,或者在高负载情况下完全停止工作。

执行nvidia-smi出现Fan ERR错误的示例如下。

$ nvidia-smi

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 418.67       Driver Version: 418.67       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM3...  On   | 00000000:3E:00.0 Off |                    0 |
| ERR!  44C     P0   ERR!/ 350W |      0MiB / 32480MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

解决方案

某些情况下,可以通过重启节点解决Fan ERR或者Power Usage ERR错误。推荐流程如下。

  1. 重启节点,尝试恢复该GPU状态。如果执行nvidia-smi命令后,显示问题未出现,则表明问题已解决。

  2. 如果重启无法解决问题,则表明硬件出现问题。提交工单联系容器服务技术支持。

GPU设备的infoROM损坏

InfoROM是显卡上的一个存储区域,用于存放固件和重要的配置数据。如果InfoROM损坏,可能会影响显卡正常运行,甚至无法使用。

故障描述

当执行nvidia-smi命令时,预期输出中出现infoROM is corrupted,表明NVIDIA GPU的InfoROM损坏。

执行nvidia-smi出现InfoROM损坏的示例如下。

+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.54.03              Driver Version: 535.54.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  Tesla V100-SXM2-32GB           On  | 00000000:00:07.0 Off |                    0 |
| N/A   31C    P0              22W / 300W |      0MiB / 32768MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+
WARNING: infoROM is corrupted at gpu 0000:07.0

解决方案

提交工单联系容器服务技术支持。

驱动故障

GPU驱动故障指由于GPU的软件驱动程序出现问题而导致的一系列故障和异常行为,可能表现为系统崩溃、性能下降、图形显示错误、功能失效或其他不稳定的行为。驱动程序是操作系统用来与硬件设备通信的软件,负责告诉操作系统如何控制GPU并与GPU交互。驱动程序的正确性对于确保GPU的正常工作至关重要。

驱动版本与GPU设备不匹配

故障描述

每个版本的驱动都有其适用的GPU设备,如果安装的驱动版本和目标节点上的GPU设备不匹配,会出现一些预期外的问题,例如驱动安装失败等。当节点安装的驱动版本与硬件不匹配时(例如非vGPU机型安装了GRID驱动),系统日志中会上报一个NVRM事件。

您可以执行以下命令获取NVRM事件的详细内容。

dmesg | grep -i nvrm

如果预期输出中存在类似not supported的字段,则表明驱动版本和设备不匹配。

Nov 30 20:56:46 NEV000GPUD03 kernel: [ 1680.567330] NVRM: The NVIDIA GPU 0000:00:06.0 (PCI ID: 10de:1db6)
Nov 30 20:56:46 NEV000GPUD03 kernel: [ 1680.567330] NVRM: installed in this system is not supported by the
Nov 30 20:56:46 NEV000GPUD03 kernel: [ 1680.567330] NVRM: NVIDIA 515.65.01 driver release.

解决方案

  1. NVIDIA官方网站寻找GPU设备对应的驱动版本。

  2. 卸载旧驱动,并重启机器。

  3. 安装新的驱动。

驱动无法连接

故障描述

当执行nvidia-smi命令或者使用NVML库获取GPU设备信息时,出现类似couldn't communicate with the NVIDIA driver的错误,表明驱动存在问题,无法连接。

执行nvidia-smi出现驱动无法连接的示例如下。

nvidia-smi

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver

解决方案

一般是驱动本身出现问题,需要重新安装驱动。

  1. 卸载旧驱动,并重启机器。

  2. 重新安装该版本驱动。

内核升级导致的编译版本过期

故障描述

NVIDIA GPU驱动程序的安装不是单纯的文件复制过程,而是“半编译包”,即驱动的一部分为预先编译,而另一部分则需要基于系统的内核开发包(kernel-devel)进行现场编译。编译模块是针对特定内核版本的。如果在安装GPU驱动后进行了内核升级,可能会导致现有的GPU驱动模块不可用。

升级内核版本后,重启机器,然后执行nvidia-smi,若出现如下错误,则表明内核升级导致编译版本过期。

nvidia-smi

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver

故障定位方案如下:

  1. 执行uname -r,输出当前内核版本。

    uname -r
    
    5.10.134-16.1.al8.x86_64
  2. 执行如下命令,确认nvidia.ko模块是否在当前内核版本目录下。

    find /usr/lib -name nvidia.ko
    
    /usr/lib/modules/5.10.134-16.1.al8.x86_64/kernel/drivers/video/nvidia.ko

    如果路径中显示的内核版本与执行uname -r获取到的内核版本不一致,表明驱动异常是由升级内核导致的。

解决方案

重新安装驱动。

NVIDIA-SMI的驱动故障

故障描述

可以根据执行nvidia-smi获取的状态码来判断驱动是否存在问题。例如下表所示。

nvidia-smi状态码

说明

3

请求的操作在目标设备上不可用。可能是目标节点上的设备不支持nvidia-smi,或者是驱动问题。

6

查找GPU设备的查询失败,驱动问题。

9

未加载NVIDIA驱动,驱动问题。

展开查看更多返回代码与描述

| 返回代码 | 描述 |
|----------|----------------------------------------------------|
| 0        | 成功 (Success) |
| 2        | 提供的参数或标志无效 (A supplied argument or flag is invalid) |
| 3        | 目标设备上不可用的请求操作 (The requested operation is not available on target device) |
| 4        | 当前用户没有权限访问此设备或执行此操作 (The current user does not have permission to access this device or perform this operation) |
| 6        | 查找对象的查询不成功 (A query to find an object was unsuccessful) |
| 8        | 设备的外部电源线未正确连接 (A device’s external power cables are not properly attached) |
| 9        | NVIDIA驱动程序未加载 (NVIDIA driver is not loaded) |
| 10       | NVIDIA内核检测到GPU的中断问题 (NVIDIA Kernel detected an interrupt issue with a GPU) |
| 12       | 未能找到或加载NVML共享库 (NVML Shared Library couldn’t be found or loaded) |
| 13       | NVML的本地版本不实现此功能 (Local version of NVML doesn’t implement this function) |
| 14       | infoROM已损坏 (infoROM is corrupted) |
| 15       | GPU已从总线上脱落或无法访问 (The GPU has fallen off the bus or has otherwise become inaccessible) |
| 255      | 发生了其他错误或内部驱动错误 (Other error or internal driver error occurred) |

容器化环境故障

容器化环境故障主要指NVIDIA Container Runtime以及Device Plugin等组件出现故障,导致在ACK集群中无法使用节点GPU资源。

NVIDIA Container Runtime故障

NVIDIA Container Runtime是NVIDIA推出的一种容器运行时包装器(Wrapper),以便在容器化环境中更好地支持GPU设备。它允许用户在Docker或containerd容器中快速部署GPU应用,无需进行复杂的配置和设置。

Container Runtime配置文件不正确

故障描述

当一个容器设置环境变量NVIDIA_VISIBLE_DEVICES后,容器内部并未发现GPU设备,执行nvidia-smi也出现报错。

nvidia-smi

bash: nvidia-smi: command not found

在容器查看/dev目录下的设备文件,并未出现GPU设备。

ls /dev/nvidia*
 
ls: cannot access '/dev/nvidia*': No such file or directory

此问题可能是因为节点上的Container Runtime配置文件并未生效(或者没有配置)。

containerd

在containerd中,Container Runtime配置文件位于/etc/containerd/config.toml。下方示例中,第4~12行为NVIDIA Container Runtime的配置。

containerd:

      ...... # 省略其他
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
          runtime_type = "io.containerd.runc.v2"
          privileged_without_host_devices = false
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            BinaryName = "nvidia-container-runtime" # 配置nvidia container runtime
            NoPivotRoot = false
            NoNewKeyring = false
            SystemdCgroup = true
        ..... # 省略其他

Docker

在Docker中,Container Runtime配置文件位于/etc/docker/daemon.json。下方示例中,第2~8行为NVIDIA Container Runtime的配置。

{
    "default-runtime": "nvidia",
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "exec-opts": ["native.cgroupdriver=systemd"],
    "log-driver": "json-file",
    "log-opts": {
        "max-size": "100m",
        "max-file": "10"
    },
    "bip": "169.254.123.1/24",
    "oom-score-adjust": -1000,
    "registry-mirrors": ["https://pqbap4ya.mirror.aliyuncs.com"],
    "storage-driver": "overlay2",
    "storage-opts":["overlay2.override_kernel_check=true"],
    "live-restore": true
}

默认情况下,ACK的GPU节点会自动在Container Runtime配置文件中完成NVIDIA Container Runtime相关配置。但在某些情况下,Container Runtime被修改后可能会导致NVIDIA Container Runtime配置丢失,NVIDIA Container Runtime无法正常工作。

解决方案

在Container Runtime配置文件中,手动添加NVIDIA Container Runtime的配置,然后重启Container Runtime。

NVIDIA Device Plugin故障

Device Plugin与kubelet gRPC连接中断

故障描述

Device Plugin启动时,正常上报节点GPU资源,但在运行一段随机时间后,节点GPU资源数变成0,而此时Device Plugin仍在正常运行。

查看节点上报GPU资源数为0的示例如下。

kubectl get nodes cn-beijing.192.168.2.180 -oyaml | grep nvidia.com
          f:nvidia.com/gpu: {}
          f:nvidia.com/gpu: {}
    nvidia.com/gpu: "0"
    nvidia.com/gpu: "0"

同时查看Device Plugin状态,其正常运行,日志显示也正常。

kubectl get po -n kube-system nvidia-device-plugin-cn-beijing.192.168.2.180

NAME                                            READY   STATUS    RESTARTS   AGE
nvidia-device-plugin-cn-beijing.192.168.2.180   1/1     Running   0          4h12m

此问题可能是因为Device Plugin与kubelet之间gRPC连接由于某些原因意外中断,导致节点上报GPU资源数为0,调度器不会在该节点上调度并运行GPU任务,造成节点GPU资源的浪费。

解决方案

重新创建Device Plugin Pod,并参见GPU Device-Plugin重启重启Device Plugin。

应用故障

某些时候,应用的运行失败有可能是由于应用本身代码存在缺陷或者配置有问题。

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只是一个结果,底层原因通常需要日志分析。

解决方案

尝试重置正在运行的应用程序或修复代码错误。

容器对CUDA版本的限制

故障描述

在GPU容器启动时,有时会遇到类似于Fails with CUDA driver version is insufficient for CUDA runtime version的错误。这是因为宿主机上的NVIDIA驱动版本无法满足业务容器依赖的CUDA版本,且在业务容器中存在类似NVIDIA_REQUIRE_CUDA="cuda>=11.1 driver>=450.80.02"的环境变量。NVIDIA Container Runtime会在启动容器时校验CUDA版本的兼容性,不满足条件则拒绝启动容器。

解决方案

修改业务容器中对应的限制校验,也可以变更业务容器中的CUDA版本依赖或者调整宿主机上的NVIDIA驱动版本。

NCCL Hang问题

NCCL(NVIDIA Collective Communications Library)是NVIDIA的一个集合通信库,旨在提高多GPU和多节点环境中的集合数据通信效率。上层应用程序在使用NCCL的过程中会遇到一些错误,最常见的是NCCL Hang的问题,即在执行集合通信操作时,通信进程无法继续或无法完成,导致应用程序无法继续执行。

故障描述

应用了NCCL的应用程序在运行过程中有可能遇到由于IO阻塞或通信异常而导致的NCCL阻塞的问题。表现为GPU进程中的一个或多个线程已停止在用户态运行,也无法自行终止,整个进程处于Z状态,成为僵尸进程(Zombie State)。

解决方案

重启节点,强制结束该进程。

GPU容器运行一段时间后设备无法访问

故障描述

某些场景下,申请GPU的容器运行一段时间后执行nvidia-smi后返回如下错误。

nvidia-smi

Failed to initialize NVML: Unknown Error

同时查看容器的/sys/fs/cgroup/devices/devices.list文件内容已被修改为如下内容。

....... # 省略其他

c 195:0 m # 原始内容为c 195:0 rw,也就是设备权限被修改。

....... # 省略其他

这是因为节点执行systemctl daemon-reloadsystemctl daemon-reexec等操作时会更新cgroup相关配置,进而影响NVIDIA GPU设备在容器中的正常使用。更多信息,请参见#1671

解决方案

修复方式,请参见#1730

cGPU故障

cGPU是ACK集群中实现共享GPU调度和显存隔离的组件。更多信息,请参见安装共享GPU调度组件

内核升级导致的编译版本过期

故障描述

cGPU的安装不是单纯的文件复制过程,而是“半编译包”,即驱动的一部分为预先编译,而另一部分则需要基于系统的内核开发包(kernel-devel)进行现场编译。cGPU和编译时依赖的内核版本强相关。如果在安装cGPU后进行了内核升级,可能会导致cGPU不可用。

解决方案

卸载cGPU,重新安装。关于如何卸载cGPU,请参见升级节点cGPU版本

相关文档

  • 您可以发起GPU节点诊断,根据诊断结果定位和解决问题。更多信息,请参见自助诊断GPU节点问题

  • 关于使用GPU节点过程中可能会遇到的一些常见问题,请参见GPU FAQ