玩轉GPU

近幾年，包含GPU通用計算在內的異構計算體系得到快速發展。

本文通過使用P40 GPU搭建一整套深度學習開發環境打開玩轉GPU的大門，並通過部署DCGM來集中化管理GPU集群。

全文大概6580字，閱讀需要9分鐘。

封面圖片來自於：pixabay geralt

硬體環境：4塊P40 Tesla GPU

作業系統：Centos 7.3 x64 ，3.18版本內核

網絡環境：能夠上網下載相關驅動和tensorflow等軟體資源

1) 確保gpu卡識別成功，使用以下命令確認

lspci|grep -i nvidia

2) 依賴包安裝

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.rpmyum 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/deviceQuerymake./deviceQuery

備註: 如果打算在windows下面使用桌面gpu進行開發，安裝完成後可以到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\extras\demo_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桌面的，有兩種方式來解決這個問題:

服務啟動文件位置 /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

不過使用後臺服務實現更加優雅，建議採用第一種方式。

1) 前提條件

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

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

NVIDIA Data Center GPU Manager是Tesla平臺解決方案的一個核心組件，專注於集群級別的健康和可用性，降低GPU管理成本。可以獨立部署在GPU主機上，也可以集成到其他集群管理產品中。其功能如下:

FunctionDetailActive Health Monitoring

Runtime Health Checks

Prologue Checks

Epilogue Checks

Diagnostics & System Validation

System Validation Tests

Deep HW Diagnostics

Policy & Group Config Management

Pre-configured policies

Job Level accounting

Stateful configuration

Power & Clock Mgmt

Dynamic Power Capping

Synchronous Clock Boost

GPU管理工具架構如下：

LevelFunctionNVML

Stateless queries.Can only query current data

Low overhead while running,high overhead to develop

Management app run on same box as GPUs

Low-level control of GPUs

DCGM

Can query a few hours of metrics

Provides health checks and diagnostics

Can batch queries/operations to groups of GPUs

Can be remote or local

3rd Party tools

對於gpu數量較少的業務來說，使用NVML命令行工具即可實現對GPU的簡單管理。如果集群內gpu數量較多，顯然無法登陸到每一個機器進行操作，此時就需要採用DCGM進行遠程管理，也可以基於DCGM開發各類第三方的管理平臺進行管理。

只支持Tesla系列GPU(即Kepler，Maxwell，Pascal以及最新的Volta)

Linux X64或者POWER

Ubuntu或者Centos/RHEL

建議採用的驅動版本為R375或者更高版本(具體的版本，需要參考Release Notes，比如v1.2.3版本就要求驅動版本為R384或更高)

V1.0版本不支持硬體診斷(建議採用最新版本，截至發文日期最新版本為v1.2.3)

訪問地址 https://developer.nvidia.com/data-center-gpu-manager-dcgm根據系統選擇不同的安裝包，我們採用centos7系統，最終下載得到的文件為 datacenter-gpu-manager-384-1.x86_64.rpm

使用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.6

啟動/停止監聽引擎

nv-hostengine

Started 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.1

組件名稱說明

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

備註：操作如下命令前必須先啟動監聽引擎

Groups

幾乎所有的DCGM操作都是以group為單位進行的。用戶可以創建、銷毀以及修改本地節點上的GPU group，後續將以此為單位進行其他操作。Groups的概念旨在將一些GPU作為單個抽象資源進行管理，對於只有一個GPU的機器來說，完全可以忽略group概念，可以當作只有一個GPU的group進行操作。為了方便起見，DCGM會創建一個默認的group來包含集群內所有的GPU。不同的group的GPU成員可以重疊，通過創建不同的GPU group可以方便的對job級別的工作進行處理，比如查看job狀態或者健康檢查等管理group非常簡單，使用dcgmi group子命令即可，下面示例了如何創建、列出、刪除group

Successfully created group "GPU_Group" with a group ID of 1

 1 group found.+-+| GROUPS                                                                     |+============+===============================================================+| Group ID   | 1                                                             || Group Name | GPU_Group                                                     || GPU ID(s)  | None                                                          |+--+---+

 

Successfully removed group 1如果想要將GPU添加到group中，需要識別它們，首先列出已安裝的GPU設備

 4 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中：

   Add to group operation successful.

查看指定的group信息：

 +-+| 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目前支持如下配置

SettingsDescriptionDefaults

Sync 

Boost

Coordinate Auto Boost across GPUs in the groupNone

Target 

Clocks

Attempt to maintain fixed clocks at the target valuesNone

ECC 

Mode

Enable ECC protection throughout the GPU’s memory

Usually

On

Power 

Limit

Set the maximum allowed power consumptionVariesCompute Modelimit concurrent process access to the GPU

No restrictions

要為一個gpu group定義一組配置，使用dcgmi config子命令

參考如下示例:

查看某一個group(示例中為gropu 1)的配置

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

一旦設置了一個配置，DCGM中有Target和Current兩個概念。Target用於跟蹤用戶請求的配置狀態，Current表示GPU當前的實際狀態。DCGM會嘗試從Current狀態轉為Target設置的狀態。

Policy

DCGM允許客戶端配置GPU在出現某些事件時自動執行特定操作。這對於event-action場景非常有用，比如當發生嚴重錯誤時自動恢復，對於event-notification場景也非常有用，比如客戶端希望當出現RAS事件時收到警告信息

在以上兩種情況下，客戶端必須定義某些條件以便觸發後續動作，這些條件是從一組預定義的可用度量值指定。

一般來說，事件分為嚴重故障，非嚴重故障或者是性能警告。包含如下情況：

最簡單的策略就是當發生特定事件時讓DCGM通知用戶，除此之外不再進行額外的動作，通常是作為編程接口中的回調機制。

每當觸發條件時，DCGM都會調用這些回調接口。一旦收到特定條件的回調，該通知註冊事件就宣告終止，如果客戶想要重複的通知某一個事件，應該在處理每一個回調之後重新執行註冊。

以下命令用於配置一條通知策略，當檢測到PCIe致命/非致命錯誤時進行通知：

Policy successfully set.

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來接收相應的通知信息，比如

Listening for violations …A PCIe error has violated policy manager values. ...

Action策略是notification策略的超集，用於自動執行特定操作，比如自動處理特定的RAS事件。

Action policy包括三個額外的組件:

ComponentDescriptionIsolation mode在執行後續步驟前，決定DCGM是否需要獨佔GPU訪問Action侵入式執行某些操作VlidationGPU狀態驗證以及後期操作

每當策略運行時設置策略的客戶端會收到兩次信息

1) 當條件被觸發，策略運行時通知回調

2) 當action運行完畢，比如驗證步驟完成通知回調

配置示例：

 Policy successfully set.    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查詢統計信息並獲得這一階段所有的聚合統計信息。

發送啟動通知

 Successfully started recording stats for <user-provided-jobid>

發送停止通知

 Successfully stopped recording stats for <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提供的專用工具進行檢測

設計目的是用於識別關鍵問題，而不會影響應用程式的行為和性能。通過這些檢查可以發現各種嚴重的問題，比如GPU無反應，固件損壞或者散熱異常等當發生這些問題時，DCGM會報告警告或者錯誤，建議遵循如下處理規則
    1) Warning，檢測到的問題不會影響當前的job工作，但需要引起注意，並儘可能進行修復。
    2) Error，檢測到關鍵問題，目前的job可能會受到影響甚至中斷，這種情況通常會引發致命的RAS事件，需要終止當前執行的工作，並執行GPU健康檢查。

啟用方式

Health monitor systems set successfully.

查看當前健康狀態

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.                                                       |+---+--+

主動健康檢查是侵入式的檢查方式，需要獨佔目標GPU設備。通過模擬運行一個真實的任務然後分析結果，DCGM可以確認各種各樣的問題，包括通過dcgmi diag子命令，可以執行不同時間長度的檢查工作。

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/親和力相關信息。

查看設備級別拓撲視圖

+----+-+| 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級別拓撲視圖

+----+-+| mygpu             | Topology Information                                   |+===================+========================================================+| CPU Core Affinity | 0 - 13, 28 - 31                                        |+----+-+| NUMA Optimal      | True                                                   |+----+-+| Worst Path        | Connected via a PCIe host bridge                       |+----+-+

DCGM提供了檢查系統中各個鏈路nvlink錯誤計數器的方法，方便用戶捕捉異常情況，觀察nvlinkhi之間通訊的健康狀況主要包括四種類型的錯誤：

TypedescriptionCRC FLIT Error

Data link receive flow control digit CRC

error

CRC Data ErrorData link receive data CRC errorReplay ErrorTransmit replay errorRecovery Error

Transmit recovery

error

檢查gpuid為0的nvlink錯誤計數器

以上就是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