在生产环境中运行长时间 GPU 任务时，一个隐蔽但破坏力极强的问题会周期性浮现：NVIDIA 驱动和 nvidia-smi 工具会在系统运行约 66 天后出现完全挂死的状态，所有涉及 GPU 状态查询的操作都会无限期阻塞。这一问题在驱动版本 570.133.20（OpenRM）和内核 6.6.0 环境下被明确记录，影响 B200 等高端加速器平台。更棘手的是，即使尝试发送 SIGTERM 或 SIGKILL 信号终止 nvidia-smi 进程，系统关机也可能被拖累至 10 分钟以上。理解看门狗超时机制与进程信号处理的联动逻辑，是构建高可用 GPU 计算基础设施的关键工程能力。
问题现象与触发边界
当系统连续运行超过 66 天后，nvidia-smi 命令会完全失去响应。用户执行 nvidia-smi 或 nvidia-smi -q 时，命令会阻塞在 I/O 调用层面，无法返回任何输出。使用 strace 追踪会发现阻塞发生在与 /var/run/nvidia-persistenced/socket 的 Unix 域套接字通信环节。更为棘手的是，试图终止挂死的 nvidia-smi 进程本身也往往失败，因为进程可能处于不可中断的等待状态。这导致依赖 GPU 状态监控的自动化流水线集体失效，因为健康检查脚本会卡住，系统无法判断 GPU 是否仍正常工作。
在容器化部署场景下，如果主机上启用了 nvidia-persistenced 服务，容器内的 nvidia-smi 响应时间会从正常的 2 秒恶化至 24 秒甚至完全挂死。这与容器运行时对 NVML 库的调用路径有关 —— 当持久化守护进程与容器内部的工具使用不同的通信通道时，驱动程序内部的状态机可能出现竞态条件。这种现象在长时间运行的 Kubernetes GPU 工作节点上尤为常见，因为节点重启频率通常以月为单位，恰好落在问题触发窗口内。
看门狗超时的驱动层机制
NVIDIA 驱动程序内部实现了一套看门狗定时器机制，用于检测和响应 GPU 硬件异常。当 GPU 计算任务超出预设的时间阈值时，看门狗会触发硬件层面的中断，要求驱动程序执行抢占或重置操作。问题在于，这套保护机制在某些边界条件下会自我锁定：当看门狗检测到异常状态后，如果用户空间的监控工具（如 nvidia-smi）尝试查询 GPU 信息，驱动程序会等待一个永远无法完成的硬件响应，从而导致整个查询路径被阻塞。
具体来说，驱动程序通过 NVML（NVIDIA Management Library）向上层提供 GPU 状态查询接口。当 GPU 处于某些特定的错误状态（如 ECC 错误累积、显存通道异常、或计算单元挂起）时，NVML 的查询会触发底层驱动的恢复流程。如果此时看门狗定时器已经介入并开始执行设备重置，而用户空间进程仍在等待查询响应，就会形成一个经典的死锁场景：用户进程等待驱动完成恢复，驱动等待用户进程释放某些资源才能继续。
66 天这个时间窗口并非偶然，它与 Linux 内核的 32 位时间戳溢出问题（Year 2038 问题在 32 位系统上的变体）以及驱动程序内部使用的时间计数器精度有关。驱动代码中使用毫秒级时间戳来追踪各种超时状态，当系统运行时间超过 2 的 31 次方毫秒（约 49.7 天）时，某些未正确处理的时间回绕会导致看门狗超时计算出错，将合法的等待时间误判为超时，从而触发异常处理流程。
信号处理策略与进程终止机制
针对挂死的 nvidia-smi 进程，标准的进程终止信号往往失效。SIGTERM（信号编号 15）作为优雅终止请求，在进程处于不可中断等待状态时无法被处理，因为内核会将该信号挂起直到进程从系统调用返回 —— 而这个返回永远不会发生。SIGKILL（信号编号 9）作为强制终止信号，虽然可以绕过大多数信号处理逻辑，但如果进程正处于内核态执行特定驱动程序代码，内核可能选择在当前操作完成前拒绝终止该进程，以避免驱动状态不一致。
工程实践中的解决方案是建立多层次的信号发送策略。首先，向目标进程发送 SIGTERM 并等待一个短暂的宽限期（通常 5 到 10 秒），让进程有机会处理清理逻辑。其次，如果进程仍未响应，发送 SIGINT（信号编号 2）模拟中断请求，这在某些情况下可以唤醒处于 NVML 调用中的进程。最后，对于仍无响应的进程，使用 SIGKILL 执行强制终止。整个流程需要配合进程状态监控，确保在合理时间内确认进程已被移除。
对于 nvidia-persistenced 相关的挂死问题，更治本的方法是调整持久化守护进程的启动策略。默认配置下，nvidia-persistenced 会在 GPU 空闲时将驱动状态持久化到磁盘，以加速后续的 GPU 重用。但这种持久化操作与容器环境的隔离模型存在冲突 —— 容器内部的 NVML 调用需要与主机守护进程协调，通信超时可能导致双方同时挂住。解决方案是禁用容器工作负载节点的 nvidia-persistenced 服务，转而使用更轻量的按需模式。
超时参数配置与监控阈值
构建防御性 GPU 基础设施，需要在多个层面配置合理的超时参数。在系统层面，可以通过内核参数设置 GPU 驱动的响应超时预期，但这通常需要重新编译或加载带参数的驱动模块。更实用的做法是在应用层面实现超时控制：对所有涉及 nvidia-smi 调用的脚本和程序设置执行超时，使用 timeout 命令或语言级别的超时机制（如 Python 的 signal 模块或 Go 的 context 包）。
以下是一个生产可用的超时包装示例，采用 bash 脚本配合 timeout 命令实现：
#!/bin/bash
# nvidia-smi-safe-query.sh - 带超时保护的 GPU 状态查询
NVIDIA_SMI_TIMEOUT=10 # 秒
GPU_INDEX=${1:-0}
function cleanup() {
# 超时或中断时的清理逻辑
pkill -P $$ 2>/dev/null
exit 124
}
trap cleanup SIGTERM SIGINT SIGHUP
timeout ${NVIDIA_SMI_TIMEOUT} nvidia-smi -i ${GPU_INDEX} -q 2>&1
exit_code=$?
if [ $exit_code -eq 124 ]; then
echo "ERROR: nvidia-smi query timed out after ${NVIDIA_SMI_TIMEOUT}s" >&2
# 这里可以触发告警或执行 GPU 重置逻辑
nvidia-smi --gpu-reset -i ${GPU_INDEX} 2>/dev/null || true
fi
exit $exit_code
在监控阈值设计上，建议将 60 天作为主动预防窗口。超过 55 天后，系统应自动执行一次软重启或至少重启 nvidia-persistenced 服务，以刷新驱动内部状态。对于不可中断的关键任务，可以配置 cron 作业在预期到达 66 天前执行滚动更新，将工作负载迁移到备用节点后对当前节点进行维护重启。
GPU 状态检查与主动重置流程
当 nvidia-smi 挂死时，GPU 设备本身可能仍处于可用状态，问题仅限于管理工具的通信通道受阻。此时可以尝试绕过 NVML 直接访问设备文件，通过 /proc/driver/nvidia/capabilities/ 下的调试接口获取有限的设备信息。更激进的恢复手段是执行 GPU 级别的重置操作：nvidia-smi --gpu-reset -i <gpu_id> 会向指定 GPU 发送重置请求，触发驱动执行硬件重初始化。
如果 GPU 重置失败（错误信息提示设备正被其他进程使用），则需要深入排查隐藏的 GPU 占用进程。某些场景下，CUDA 应用程序崩溃后可能留下僵尸子进程，或 Xorg 会话在 GPU 进入特定状态后拒绝释放控制权。使用 lsof /dev/nvidia* 列出所有打开 GPU 设备文件的进程，或者遍历 /sys/class/misc/nvidia0/device/ 下的进程关联信息，通常可以定位到阻塞源。
对于数据中心的规模化部署，建议引入 NVIDIA DCGM（Data Center GPU Manager）作为统一的监控和诊断框架。DCGM 提供了更健壮的 GPU 健康检查机制，其内置的诊断工具可以在不依赖 nvidia-smi 的情况下探测 GPU 硬件状态。配置 DCGM 的主动监控策略，定期执行轻量级健康检查，可以在问题扩大前识别出处于临界状态的 GPU 节点。
工程配置参数汇总
在实际部署中，以下参数值经过生产验证具有较好的平衡性。看门狗检测间隔建议设置为 5000 毫秒，这既能及时捕获异常计算任务，又不会因过于敏感而产生大量误报。NVML 操作超时建议控制在 8000 到 12000 毫秒之间，具体取决于 GPU 型号和负载特性 ——A100 和 H100 等高端卡在重负载下响应较慢，需要适当放宽。对于需要长期稳定运行的节点，nvidia-persistenced 应配置为 --persistence-mode=manual 并仅在需要时手动启动，避免服务常驻带来的潜在死锁风险。
信号处理方面，推荐将 SIGTERM 的响应窗口设为 5 秒，SIGKILL 的延迟设为 2 秒，整个终止流程不应超过 10 秒。对于关键基础设施节点，还应在监控系统（如 Prometheus + Alertmanager）中配置 nvidia-smi 响应时间指标，当查询耗时超过阈值时触发预警，便于运维人员在问题累积到挂死程度前介入处理。
在容器编排层面，Kubernetes GPU 工作节点应配置 nvidia-device-plugin 的健康检查探针，将 nvidia-smi 响应作为节点就绪条件的一部分。当检测到响应异常时，节点会自动从调度池中移除，防止新 Pod 被分配到异常节点。同时，Daemonset 中应部署轻量级监控代理，定期报告 GPU 温度、功耗和 SM 利用率，这些指标可以辅助判断设备是否处于异常边缘。
资料来源：GitHub NVIDIA open-gpu-kernel-modules Issue #971（nvidia-smi hangs after ~66 days）、NVIDIA nvidia-container-toolkit Issue #1053（nvidia-smi hangs with nvidia-persistenced）、NVIDIA GPU Debug Guidelines（r560）。