近几年，包含GPU通用计算在内的异构计算体系得到快速发展。
本文通过使用P40 GPU搭建一整套深度学习开发环境打开玩转GPU的大门，并通过部署DCGM来集中化管理GPU集群。
全文大概6580字，阅读需要9分钟。
封面图片来自于：pixabay geralt
环境准备
硬件环境：4块P40 Tesla GPU
操作系统：Centos 7.3 x64 ，3.18版本内核
网络环境：能够上网下载相关驱动和tensorflow等软件资源
实现目标
-
搭建一套完整的深度学习开发环境
-
介绍常用的检测命令，方便后期出现问题时快速定位故障原因
玩转步骤 初级
1
安装cuba
1) 确保gpu卡识别成功，使用以下命令确认
lspci|grep -i nvidia2) 依赖包安装
-
系统64位(uname -m 返回x86_64)，本文档以centos7.3为例
-
安装gcc
-
需要安装内核对应版本的Kernel Headers和Development Packages
yum install kernel-devel-$(uname -r) kernel-headers-$(uname -r)3) 选择cuda安装方式选择
rpm/deb包或者runfile包，后者比较通用，但是无法自动升级。本文档中我们选择rpm包安装，因为我们是centos系统 😀
4) 下载repo配置文件
访问http://developer.download.nvidia.com/compute/cuda/repos/rhel7/x86_64/ 下载最新版本的repo文件
5) 配置repo并安装cuda
rpm -ivh cuda-repo-rhel7-9.0.176-1.x86_64.rpm yum install cuda
6) 安装验证
-
使用命令验证
nvidia-smi
输出：
Fri Dec 1 17:42:13 2017+-----------------------------------------------------------------------------+ | NVIDIA-SMI 384.81 Driver Version: 384.81 | |-------------------------------+----------------------+----------------------+ | 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 P40 On | 00000000:02:00.0 Off | 0 | | N/A 21C P8 9W / 250W | 10MiB / 22912MiB | 0% Default | +-------------------------------+----------------------+----------------------+ | 1 Tesla P40 On | 00000000:03:00.0 Off | 0 | | N/A 24C P8 9W / 250W | 10MiB / 22912MiB | 0% Default | +-------------------------------+----------------------+----------------------+ | 2 Tesla P40 On | 00000000:83:00.0 Off | 0 | | N/A 20C P8 9W / 250W | 10MiB / 22912MiB | 0% Default | +-------------------------------+----------------------+----------------------+ | 3 Tesla P40 On | 00000000:84:00.0 Off | 0 | | N/A 19C P8 9W / 250W | 10MiB / 22912MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+
- 运行测试程序
cd /usr/local/cuda/samples/1_Utilities/deviceQuery make ./deviceQuery
备注: 如果打算在windows下面使用桌面gpu进行开发，安装完成后可以到C:Program FilesNVIDIA GPU Computing ToolkitCUDAv9.0extrasdemo_suite
下面执行命令deviceQuery.exe查看详细信息
7) 后续配置
在使用GPU设备前，必须先加载NVIDIA内核模式驱动并连接到目标GPU设备。通常，如果内核模式驱动尚未加载，当用户调用gpu的时候会先加载驱动并对GPU执行初始化，这个过程对用户是透明的。当所有调用GPU的程序运行完成后，驱动程序会取消GPU的初始化状态。驱动加载行为会造成两个问题：
-
应用程序启动延迟 : 应用程序触发的GPU初始化过程中，每个GPU会由于要刷新ECC造成一个短暂的延迟(约1-3秒)。如果GPU已经经过了初始化，不会再执行该步骤比较明显的示例是，当我们安装完驱动重启系统后第一次执行nvidia-smi命令时会卡住一段时间才会显示结果
-
Preservation of driver state : 如果驱动程序将GPU恢复到未初始化状态，则该GPU某些非持久状态会丢失，并恢复到默认配置，直到下次进入到persistence mode，为了避免这种情况，GPU应该始终保持在persistence mode
对于windows系统，驱动程序在系统启动的时候加载，一直到关机为止，所以不用考虑以下配置对于linux系统，如果安装了X桌面，驱动加载逻辑和windows一样，然而大部分情况下我们服务器上是不会安装X桌面的，有两种方式来解决这个问题:
-
使用nvidia官方提供的一个后台服务
服务启动文件位置 /usr/lib/systemd/system/nvidia-persistenced.service，这个文件是由xorg-x11-drv-nvidia软件包提供的，如果找不到这个文件，请检查该软件包是否安装成功
systemctl start nvidia-persistenced.service
如果希望系统启动后自动进入持久化状态，可以执行：
systemctl enable nvidia-persistenced.service- 使用如下命令可以达到同样的效果
nvidia-smi -pm 1
如果希望系统启动后自动进入persistence mode，可以将以上命令加入/etc/rc.d/rc.local
不过使用后台服务实现更加优雅，建议采用第一种方式。
2
安装cuDNN
1) 前提条件
-
GPU的计算能力至少3.0或者更高，每种显卡型号的计算能力可以参考 http://developer.nvidia.com/cuda-gpus
-
如果使用的是Volta GPU，必须安装version7或者更高版本
-
必须先安装cuda
2) 下载cuDNN安装包 访问 https://developer.nvidia.com/rdp/cudnn-download 我们用的是centos7系统，选择下载tgz包，即”cuDNN v7.0 Library for Linux”选项最终我们得到tar包为cudnn-9.0-linux-x64-v7.tgz
3) 解压安装包
tar zxvf cudnn-9.0-linux-x64-v7.tgz
4) 拷贝文件
/usr/bin/cp cuda/include/cudnn.h /usr/local/cuda/include/ /usr/bin/cp cuda/lib64/libcudnn* /usr/local/cuda/lib64/ chmod a+r /usr/local/cuda/include/cudnn.h /usr/local/cuda/lib64/libcudnn*5) 配置环境变量
echo 'export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"' >> /etc/profileecho 'export CUDA_HOME=/usr/local/cuda' >> /etc/profilesource /etc/profile
备注:在安装tensorflow并验证的时候会报错找不到so库，需要执行以下命令，假如你执行验证时没有问题，以下步骤可以省略
cd /usr/local/cuda/lib64 ln -s libcudart.so libcudart.so.8.0 ln -s libcublas.so libcublas.so.8.0 ln -s libcudnn.so libcudnn.so.5 ln -s libcufft.so libcufft.so.8.0 ln -s libcurand.so libcurand.so.8.0
3
安装tensorflow
1) 使用pip安装
-
安装指定版本
pip install tensorflow-gpu==1.0.0
- 安装最新版本
pip install tensorflow
2) 安装后验证
python -c "import tensorflow"
如果遇到类似于如下找不到so的错误，请参考”安装cuDNN”章节中的备注部分Couldn’t open CUDA library libcudnn.so.5
祝贺你，至此一个深度学习环境就搭建完毕了，为了方便管理gpu设备以及在出现问题时快速定位问题，我们建议配置以下部分
玩转步骤 进阶
配置DCGM
1
基础介绍
NVIDIA Data Center GPU Manager是Tesla平台解决方案的一个核心组件，专注于集群级别的健康和可用性，降低GPU管理成本。可以独立部署在GPU主机上，也可以集成到其他集群管理产品中。其功能如下:
| Function | Detail |
|---|---|
| Active Health Monitoring |
|
| Diagnostics & System Validation |
|
| Policy & Group Config Management |
|
| Power & Clock Mgmt |
|
2
可用的GPU管理工具
GPU管理工具架构如下：
| Level | Function |
|---|---|
| NVML |
|
| DCGM |
|
| 3rd Party tools |
|
对于gpu数量较少的业务来说，使用NVML命令行工具即可实现对GPU的简单管理。如果集群内gpu数量较多，显然无法登陆到每一个机器进行操作，此时就需要采用DCGM进行远程管理，也可以基于DCGM开发各类第三方的管理平台进行管理。
3
依赖条件
-
只支持Tesla系列GPU(即Kepler，Maxwell，Pascal以及最新的Volta)
-
Linux X64或者POWER
-
Ubuntu或者Centos/RHEL
-
建议采用的驱动版本为R375或者更高版本(具体的版本，需要参考Release Notes，比如v1.2.3版本就要求驱动版本为R384或更高)
-
V1.0版本不支持硬件诊断(建议采用最新版本，截至发文日期最新版本为v1.2.3)
4
下载安装包
访问地址 https://developer.nvidia.com/data-center-gpu-manager-dcgm根据系统选择不同的安装包，我们采用centos7系统，最终下载得到的文件为 datacenter-gpu-manager-384-1.x86_64.rpm
5
安装软件
使用root或者具有特权的用户执行
rpm -ivh datacenter-gpu-manager-384-1.x86_64.rpm查看dcgmi版本：
dcgmi --version正常的输出结果：
dcgmi version: 1.2.3查看nvvs版本
nvvs --version正常的输出结果：
nvvs version: 384.66
常用命令解析
启动/停止监听引擎
nv-hostengineStarted host engine version 1.2.3 using port number: 5555 默认监听127.0.0.1:5555，对于单机管理足矣，但是如果想要使用远程管理，可以通过-b参数指定要监听的ip，比如
nv-hostengine -b 10.1.1.1或者直接指定-b all表示监听所有端口如果想停止引擎使用如下命令:
nv-hostengine -t查看当前主机上面的gpu设备
dcgmi discovery -l默认连接的是本地引擎，如果要查看远端gpu设备
dcgmi discovery -l --host 10.1.1.17
涉及组件
| 组件名称 | 说明 |
|---|---|
| DCGM
shared library |
用户层共享库，libdcgm.so，是DCGM的核心组件。这个库实现了主要的底层函数，并作为一组基于C的APIs公开 |
| NVIDIA
Host Engine |
NVIDIA 主机引擎，nv-hostengine，是对DCGM共享库的一个简单封装。主要作用是将DCGM库实例化为一个持续独立运行的进程，并配置相应的监控和管理功能。备注：DCGM可以使用root用户或者非root用户执行，但是大部分操作，比如配置管理GPU是不能使用非root用户执行的 |
| DCGM
CLI Tool |
DCGM的命令行界面dcgmi，以简单的交互形式执行大部分的DCGM操作。适合不想额外编写程序操作接口控制DCGM或者收集相关数据的管理员或者用户。本程序不适合用于脚本处理 |
| Python
Bindings |
安装目录为/usr/src/dcgm/bindings |
| Software
Development Kit |
包括如何使用DCGM的功能以及API的示例文档和头文件。SDK包括C和Python两类APIs，包括了独立和嵌入模式下两种不同环境的使用示例。安装位置为/usr/src/dcgm/sdk_samples |
8
关键特性
备注：操作如下命令前必须先启动监听引擎
Groups
几乎所有的DCGM操作都是以group为单位进行的。用户可以创建、销毁以及修改本地节点上的GPU group，后续将以此为单位进行其他操作。Groups的概念旨在将一些GPU作为单个抽象资源进行管理，对于只有一个GPU的机器来说，完全可以忽略group概念，可以当作只有一个GPU的group进行操作。为了方便起见，DCGM会创建一个默认的group来包含集群内所有的GPU。不同的group的GPU成员可以重叠，通过创建不同的GPU group可以方便的对job级别的工作进行处理，比如查看job状态或者健康检查等管理group非常简单，使用dcgmi group子命令即可，下面示例了如何创建、列出、删除group
# dcgmi group -c GPU_GroupSuccessfully created group “GPU_Group” with a group ID of 1
# dcgmi group -l 1 group found. +----------------------------------------------------------------------------+ | GROUPS | +============+===============================================================+ | Group ID | 1 | | Group Name | GPU_Group | | GPU ID(s) | None | +------------+---------------------------------------------------------------+ # dcgmi group -d 1Successfully removed group 1如果想要将GPU添加到group中，需要识别它们，首先列出已安装的GPU设备
# dcgmi discovery -l4 GPUs found. +--------+-------------------------------------------------------------------+ | GPU ID | Device Information | +========+===================================================================+ | 0 | Name: Tesla P40 | | | PCI Bus ID: 00000000:02:00.0 | | | Device UUID: GPU-8bed4da1-ac8c-5613-d74a-e71dec80c048 | +--------+-------------------------------------------------------------------+ | 1 | Name: Tesla P40 | | | PCI Bus ID: 00000000:03:00.0 | | | Device UUID: GPU-5e7f452b-d6bb-c61e-bcb0-678a19278c0a | +--------+-------------------------------------------------------------------+ | 2 | Name: Tesla P40 | | | PCI Bus ID: 00000000:83:00.0 | | | Device UUID: GPU-4ee978a0-ade4-3b67-274e-b4c8083132fd | +--------+-------------------------------------------------------------------+ | 3 | Name: Tesla P40 | | | PCI Bus ID: 00000000:84:00.0 | | | Device UUID: GPU-8055c4f0-9523-0af1-c88a-1be7847c1434 | +--------+-------------------------------------------------------------------+我们当前有4块GPU卡，我们想把id为0和1的两块gpu卡添加到我们之前创建的group中：
# dcgmi group -g 1 -a 0,1 Add to group operation successful.查看指定的group信息：
# dcgmi group -g 1 -i
+----------------------------------------------------------------------------+ | GROUPS | +============+===============================================================+ | Group ID | 1 | | Group Name | GPU_Group | | GPU ID(s) | 0, 1 | +------------+---------------------------------------------------------------+Configuration
管理GPU，尤其是在多节点的环境中一个重要方面就是确保跨工作负载和跨设备的配置要保持一致。
这里说的配置指的是NVIDIA公开的用于调整GPU行为的一组管理参数。
DCGM工具让客户更容易定义所需要的配置，并且确保这些配置不随着时间推移而发生改变不同的GPU参数具有不同级别的持久化属性。主要分为两大类：
1) Device InfoROM lifetime * 存在于电路板上面的非易失性存储器，可以保持一定的配置 * 即便刷新固件，配置也会被保存 2) GPU initialization lifetime * 驱动级别的数据存储，保存一些容易变化的GPU运行数据 * 一直保存直到GPU被内核模式驱动解除初始化状态为止DCGM维护的主要是第二类，这类配置通常是经常变化的，每次GPU进入空闲状态或者被reset的时候都可能会发生变化。
▼
通过使用DCGM，客户端可以确保在期望的时间内保持配置不变。
▼
在大部分情况下，客户端应该为系统中所有的GPU在初始化的时候定义一个统一的配置，或者基于每一个任务定义单独的group。
一旦定义了相关配置，DCGM会在必要时强制执行该配置，比如驱动程序重启，GPU重置或者作业启动
DCGM目前支持如下配置
| Settings | Description | Defaults |
|---|---|---|
| Sync
Boost |
Coordinate Auto Boost across GPUs in the group | None |
| Target
Clocks |
Attempt to maintain fixed clocks at the target values | None |
| ECC
Mode |
Enable ECC protection throughout the GPU’s memory | Usually
On |
| Power
Limit |
Set the maximum allowed power consumption | Varies |
| Compute Mode | limit concurrent process access to the GPU | No restrictions |
要为一个gpu group定义一组配置，使用dcgmi config子命令
参考如下示例:
查看某一个group(示例中为gropu 1)的配置
# dcgmi config -g 1 --get
+--------------------------+------------------------+------------------------+ | GPU_Group | | | | Group of 2 GPUs | TARGET CONFIGURATION | CURRENT CONFIGURATION | +==========================+========================+========================+ | Sync Boost | Not Configured | Disabled | | SM Application Clock | Not Configured | Not Specified | | Memory Application Clock | Not Configured | Not Specified | | ECC Mode | Not Configured | Enabled | | Power Limit | Not Configured | 250 | | Compute Mode | Not Configured | Unrestricted | +--------------------------+------------------------+------------------------+ **** Non-homogenous settings across group. Use with –v flag to see details.其中可以看到这个组里包含了两个GPU
# dcgmi config -g 1 --set -c 2一旦设置了一个配置，DCGM中有Target和Current两个概念。Target用于跟踪用户请求的配置状态，Current表示GPU当前的实际状态。DCGM会尝试从Current状态转为Target设置的状态。
Policy
DCGM允许客户端配置GPU在出现某些事件时自动执行特定操作。这对于event-action场景非常有用，比如当发生严重错误时自动恢复，对于event-notification场景也非常有用，比如客户端希望当出现RAS事件时收到警告信息
在以上两种情况下，客户端必须定义某些条件以便触发后续动作，这些条件是从一组预定义的可用度量值指定。
一般来说，事件分为严重故障，非严重故障或者是性能警告。包含如下情况：
-
Notifications Policy
最简单的策略就是当发生特定事件时让DCGM通知用户，除此之外不再进行额外的动作，通常是作为编程接口中的回调机制。
每当触发条件时，DCGM都会调用这些回调接口。一旦收到特定条件的回调，该通知注册事件就宣告终止，如果客户想要重复的通知某一个事件，应该在处理每一个回调之后重新执行注册。
以下命令用于配置一条通知策略，当检测到PCIe致命/非致命错误时进行通知：
# dcgmi policy -g 2 --set 0,0 -p
Policy successfully set.# dcgmi policy -g 2 --get
Policy information +---------------------------+------------------------------------------------+ | GPU_Group | Policy Information | +===========================+================================================+ | Violation conditions | PCI errors and replays | | Isolation mode | Manual | | Action on violation | None | | Validation after action | None | | Validation failure action | None | +---------------------------+------------------------------------------------+ **** Non-homogenous settings across group. Use with –v flag to see details.一旦设置了策略，客户端就会收到相应的通知，虽然主要是用于编程使用，我们也可以用dcgmi来接收相应的通知信息，比如
# dcgmi policy -g 2 --regListening for violations … A PCIe error has violated policy manager values. ...-
Action
Action策略是notification策略的超集，用于自动执行特定操作，比如自动处理特定的RAS事件。
Action policy包括三个额外的组件:
| Component | Description |
|---|---|
| Isolation mode | 在执行后续步骤前，决定DCGM是否需要独占GPU访问 |
| Action | 侵入式执行某些操作 |
| Vlidation | GPU状态验证以及后期操作 |
每当策略运行时设置策略的客户端会收到两次信息
1) 当条件被触发，策略运行时通知回调
2) 当action运行完毕，比如验证步骤完成通知回调
配置示例：
# dcgmi policy -g 1 --set 1,1 -e Policy successfully set. # dcgmi policy -g 1 --get Policy information +---------------------------+------------------------------------------------+ | GPU_Group | Policy Information | +===========================+================================================+ | Violation conditions | Double-bit ECC errors | | Isolation mode | Manual | | Action on violation | Reset GPU | | Validation after action | NVVS (Short) | | Validation failure action | None | +---------------------------+------------------------------------------------+ **** Non-homogenous settings across group. Use with –v flag to see details.
Job Stats
以上是一个job执行流程。
DCGM提供了后台数据收集和分析的功能，可以在job执行整个生命周期内收集汇总所涉及到的GPU的数据。
要使用该功能，客户端必须先配置指定group启用stats记录功能，这会让DCGM定期查看这些GPU的所有相关指标以及设备上执行的处理活动。该操作只需要在每次初始化任务的时候执行一次即可。
# dcgmi state -g 1 --enable
Successfully started process watches.
注意必须先启动stats记录功能，然后再启动job，否则可能信息会不准确。
一旦job执行完毕，就可以通过DCGM查询这个job相关的信息，并且可以根据需要，在该group内的GPU之间分解相关信息。
建议的方式是客户端在epilogue阶段的脚本中执行查询来作为job清理的一部分。
以下命令表示获取pid为19025这个job执行的相关统计信息
# dcgmi stats --pid 19025 -v Successfully retrieved process info for PID: 19025. Process ran on 4 GPUs. +------------------------------------------------------------------------------+ | GPU ID: 0 | +====================================+=========================================+ |----- Execution Stats ------------+-----------------------------------------| | Start Time * | Tue Nov 7 09:46:42 2017 | | End Time * | Tue Nov 7 09:47:29 2017 | | Total Execution Time (sec) * | 47.46 | | No. of Conflicting Processes * | 0 | +----- Performance Stats ----------+-----------------------------------------+ | Energy Consumed (Joules) | 2082 | | Max GPU Memory Used (bytes) * | 170917888 | | SM Clock (MHz) | Avg: 1220, Max: 1531, Min: 544 | | Memory Clock (MHz) | Avg: 2658, Max: 3615, Min: 405 | | SM Utilization (%) | Avg: 20, Max: 100, Min: 0 | | Memory Utilization (%) | Avg: 5, Max: 57, Min: 0 | | PCIe Rx Bandwidth (megabytes) | Avg: 94, Max: 146, Min: 75 | | PCIe Tx Bandwidth (megabytes) | Avg: 102, Max: 158, Min: 81 | +----- Event Stats ----------------+-----------------------------------------+ | Single Bit ECC Errors | 0 | | Double Bit ECC Errors | 0 | | PCIe Replay Warnings | 0 | | Critical XID Errors | 0 | +----- Slowdown Stats -------------+-----------------------------------------+ | Due to - Power (%) | 0 | | - Thermal (%) | 0 | | - Reliability (%) | 0 | | - Board Limit (%) | 0 | | - Low Utilization (%) | 0 | | - Sync Boost (%) | 0 | +----- Process Utilization --------+-----------------------------------------+ | PID | 19025 | | Avg SM Utilization (%) | 16 | | Avg Memory Utilization (%) | 4 | +----- Overall Health -------------+-----------------------------------------+ | Overall Health | Healthy | +------------------------------------+-----------------------------------------+对于某些框架来说，处理过程和pid和job不是直接关联的，在job执行过程中可能会产生很多的子进程。为了获取这种job的统计信息，在job启动和停止的时候必须先通知DCGM。
客户端需要在job的prologue阶段将用户定义的job id和使用的GPU group告知DCGM，并在job的epilogue阶段再次通知job id。
用户可以依据job id查询统计信息并获得这一阶段所有的聚合统计信息。
发送启动通知
# dcgmi stats -g 1 -s <user-provided-jobid> Successfully started recording stats for <user-provided-jobid>发送停止通知
# dcgmi stats -x <user-provided-jobid> Successfully stopped recording stats for <user-provided-jobid>要查看统计信息使用如下命令
# dcgmi stats -j <user-provided-jobid>
Health & Diagnostics
DCGm提供了多种机制来获取GPU的健康状态，不同的机制应用于不同的场景。通过使用这些接口，客户可以轻松的以非侵入的方式(不影响正在运行的任务)了解GPU的健康状态，也可以采用主动方式(当GPU没有任务可以运行一些深度诊断测试)
| 获取机制 | 描述 |
|---|---|
| Background
health checks |
非侵入式健康检查，可以在跑job的时候执行，不会影响job和性能 |
| Prologue
health checks |
侵入式健康检查，耗时数秒钟，旨在验证提交job前GPU已经准备好了执行任务 |
| Epilogue
health checks |
侵入式健康检查，耗时数分钟，主要是用于job运行失败或者怀疑GPU健康状态有问题时执行 |
| Full system
validation |
侵入式健康检查，完整的系统检查，耗时数十分钟，可以用于诊断硬件问题或者其他严重问题 |
注意以上这几种都是在线诊断，除了GPU之外有很多的其他因素可能会影响到测试结果。要完成完整的硬件诊断以及走RMA流程都需要在离线状态下使用NVIDIA提供的专用工具进行检测
-
Background Health Checks
设计目的是用于识别关键问题，而不会影响应用程序的行为和性能。通过这些检查可以发现各种严重的问题，比如GPU无反应，固件损坏或者散热异常等当发生这些问题时，DCGM会报告警告或者错误，建议遵循如下处理规则
1) Warning，检测到的问题不会影响当前的job工作，但需要引起注意，并尽可能进行修复。
2) Error，检测到关键问题，目前的job可能会受到影响甚至中断，这种情况通常会引发致命的RAS事件，需要终止当前执行的工作，并执行GPU健康检查。
启用方式
# dcgmi health -g 1 -s mpi Health monitor systems set successfully.查看当前健康状态
# dcgmi helath -g 1 -c
Health Monitor Report +------------------+---------------------------------------------------------+ | Overall Health: Healthy | +==================+=========================================================+ 假如有问题，示例如下 Health Monitor Report +----------------------------------------------------------------------------+ | Group 1 | Overall Health: Warning | +==================+=========================================================+ | GPU ID: 0 | Warning | | | PCIe system: Warning - Detected more than 8 PCIe | | | replays per minute for GPU 0: 13 | +------------------+---------------------------------------------------------+ | GPU ID: 1 | Warning | | | InfoROM system: Warning - A corrupt InfoROM has been | | | detected in GPU 1. | +------------------+---------------------------------------------------------+
-
Active Health Checks
主动健康检查是侵入式的检查方式，需要独占目标GPU设备。通过模拟运行一个真实的任务然后分析结果，DCGM可以确认各种各样的问题，包括通过dcgmi diag子命令，可以执行不同时间长度的检查工作。
# dcgmi diag -g 1 -r 1 Successfully ran diagnostic for group. +---------------------------+------------------------------------------------+ | Diagnostic | Result | +===========================+================================================+ |----- Deployment --------+------------------------------------------------| | Blacklist | Pass | | NVML Library | Pass | | CUDA Main Library | Pass | | CUDA Toolkit Libraries | Skip | | Permissions and OS Blocks | Pass | | Persistence Mode | Pass | | Environment Variables | Pass | | Page Retirement | Pass | | Graphics Processes | Pass | +---------------------------+------------------------------------------------+-r指定检查类型，1表示快速检查，2表示中等时间检查，3表示完整检查
诊断测试也可以作为action policy验证阶段的一部分，DCGM会将主动健康检查的日志保存到系统中。
有两种类型的日志：1) 硬件诊断会产生一个加密的二进制文件，这个文件只能由NVIDIA官方查看。2) 系统验证和压力测试检查通过JSON文本提供了额外的带有时间序列数据，可以用多种程序查看。
Topology
DCGM提供了多种机制来帮助用户了解GPU拓扑，包括详细的设备级别以及简略的group两个级别。用于提供连接到系统中的其他GPU信息以及关于NUMA/亲和力相关信息。
查看设备级别拓扑视图
# dcgmi topo --gpuid 0
+-------------------+--------------------------------------------------------+ | GPU ID: 0 | Topology Information | +===================+========================================================+ | CPU Core Affinity | 0 - 13, 28 - 31 | +-------------------+--------------------------------------------------------+ | To GPU 1 | Connected via a PCIe host bridge | | To GPU 2 | Connected via a CPU-level link | | To GPU 3 | Connected via a CPU-level link | +-------------------+--------------------------------------------------------+查看group级别拓扑视图
# dcgmi topo -g 1
+-------------------+--------------------------------------------------------+ | mygpu | Topology Information | +===================+========================================================+ | CPU Core Affinity | 0 - 13, 28 - 31 | +-------------------+--------------------------------------------------------+ | NUMA Optimal | True | +-------------------+--------------------------------------------------------+ | Worst Path | Connected via a PCIe host bridge | +-------------------+--------------------------------------------------------+DCGM提供了检查系统中各个链路nvlink错误计数器的方法，方便用户捕捉异常情况，观察nvlinkhi之间通讯的健康状况主要包括四种类型的错误：
| Type | description |
|---|---|
| CRC FLIT Error | Data link receive flow control digit CRC
error |
| CRC Data Error | Data link receive data CRC error |
| Replay Error | Transmit replay error |
| Recovery Error | Transmit recovery
error |
检查gpuid为0的nvlink错误计数器
# dcgmi nvlink -g 0以上就是dcgm提供的一些常用的功能，更加详细的用法可以参考命令帮助。
总结
GPU强大的并行运算能力缓解了深度学习算法的训练瓶颈，从而释放了人工智能的全新潜力，也让NVIDIA顺利成为人工智能平台方案供应商。希望以上文档能够为各位小伙伴在配置NVIDIA GPU环境时提供帮助。由于本人水平有限，如有错误疏漏之处，敬请留言，我会及时修正。
参考链接
官方产品资料，包括性能数据规格等
http://www.nvidia.cn/object/tesla_product_literature_cn.html
官方软件开发工具，样本代码等
http://www.nvidia.cn/object/tesla_software_cn.html
官方管理软件，如监控/集群管理等
http://www.nvidia.cn/object/software-for-tesla-products-cn.html
Nvidia docker样例仓库
https://github.com/NVIDIA/nvidia-docker
CUDA Toolkit文档
http://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html
CUDA下载地址
http://www.nvidia.com/getcuda
GPU驱动下载
http://www.nvidia.com/Download/index.aspx
关于persistence
http://docs.nvidia.com/deploy/driver-persistence/index.html
DCGM官方介绍页
https://developer.nvidia.com/data-center-gpu-manager-dcgm
不同型号显卡计算能力查询
http://developer.nvidia.com/cuda-gpus
cuDNN下载
https://developer.nvidia.com/rdp/cudnn-download