系统配置#

本节提供关于系统安装完成后不太常见的配置选项的信息。

另请参阅 DGX OS 连接要求，其中列出了各种服务使用的网络端口。

网络配置#

本节提供关于如何在您的 DGX 系统中配置网络的信息。

配置网络代理#

如果您的网络需要使用代理服务器，您需要设置配置文件以确保 DGX 系统通过代理进行通信。

对于操作系统和大多数应用程序#

以下是关于为操作系统和其他应用程序配置网络的一些信息。

编辑 /etc/environment 文件，并将以下代理地址添加到文件的 PATH 行下方。

http_proxy="http://<username>:<password>@<host>:<port>/"
ftp_proxy="ftp://<username>:<password>@<host>:<port>/"
https_proxy="https://<username>:<password>@<host>:<port>/"
no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"
HTTP_PROXY="http://<username>:<password>@<host>:<port>/"
FTP_PROXY="ftp://<username>:<password>@<host>:<port>/"
HTTPS_PROXY="https://<username>:<password>@<host>:<port>/"
NO_PROXY="localhost,127.0.0.1,localaddress,.localdomain.com"

其中 username 和 password 是可选的。

例如，对于 HTTP 代理（必须更改大小写版本）

http_proxy="http://myproxy.server.com:8080/"
HTTP_PROXY="http://myproxy.server.com:8080/"

对于 apt 软件包管理器#

以下是关于为 apt 软件包管理器配置网络的一些信息。

编辑或创建 /etc/apt/apt.conf.d/myproxy 代理配置文件，并包含以下行

Acquire::http::proxy "http://<username>:<password>@<host>:<port>/";
Acquire::ftp::proxy "ftp://<username>:<password>@<host>:<port>/";
Acquire::https::proxy "https://<username>:<password>@<host>:<port>/";

例如

Acquire::http::proxy "http://myproxy.server.com:8080/";
Acquire::ftp::proxy "ftp://myproxy.server.com:8080>/";
Acquire::https::proxy "https://myproxy.server.com:8080/";

Docker 配置#

为了确保 Docker 可以通过代理访问 NGC 容器注册表，Docker 使用环境变量。

关于为 Docker 配置代理环境变量的最佳实践建议，请参阅 使用 systemd 控制 Docker。

准备 DGX 系统以与 Docker 一起使用#

需要对 DGX 系统进行一些初始设置，以确保用户拥有运行 Docker 容器所需的权限，并防止 Docker 和 DGX 系统之间的 IP 地址冲突。

启用用户运行 Docker 容器#

为了防止 docker 守护程序在没有特权升级保护的情况下运行，Docker 软件需要 sudo 权限才能运行容器。满足此要求涉及到启用将运行 Docker 容器的用户以 sudo 权限运行命令。

您应确保只有您信任且了解以 sudo 权限运行命令对 DGX 系统潜在风险的用户才能运行 Docker 容器。

在您允许多个用户以 sudo 权限运行命令之前，请咨询您的 IT 部门，以确定您是否可能违反您组织的安全策略。有关启用用户运行 Docker 容器的安全影响，请参阅 Docker 守护程序攻击面。

您可以通过以下方式之一启用用户运行 Docker 容器

  • 将每个用户添加为具有 sudo 权限的管理员用户。

  • 将每个用户添加为没有 sudo 权限的标准用户，然后将用户添加到 docker 组。

这种方法本质上是不安全的，因为任何可以向 docker 引擎发送命令的用户都可以升级权限并运行 root 用户操作。

要将现有用户添加到 docker 组，请运行以下命令

sudo usermod -aG docker user-login-id

其中 user-login-id 是您要添加到 docker 组的现有用户的用户登录 ID。

配置 Docker IP 地址#

为了确保您的 DGX 系统可以访问 Docker 容器的网络接口，应将 Docker 配置为使用与 DGX 系统使用的其他网络资源不同的子网。

默认情况下，Docker 使用 172.17.0.0/16 子网。请咨询您的网络管理员以了解您的网络使用的 IP 地址。如果您的网络与默认的 Docker IP 地址范围没有冲突，则无需进行任何更改，您可以跳过本节。但是，如果您的网络在此范围内使用地址用于 DGX 系统，则应更改默认的 Docker 网络地址。

您可以通过修改 /etc/docker/daemon.json 文件或修改 /etc/systemd/system/docker.service.d/dockeroverride.conf 文件来更改默认的 Docker 网络地址。以下说明提供了一个修改 /etc/systemd/system/docker.service.d/docker-override.conf 以覆盖默认 Docker 网络地址的示例。

  1. 打开 docker-override.conf 文件进行编辑。

    sudo vi /etc/systemd/system/docker.service.d/docker-override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -s overlay2
LimitMEMLOCK=infinity
LimitSTACK=67108864

  2. 进行以下以粗体指示的更改，为您的网络设置正确的网桥 IP 地址和 IP 地址范围。

    请咨询您的 IT 管理员以获取正确的地址。

    [Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -s overlay2 --bip=192.168.127.1/24
--fixed-cidr=192.168.127.128/25
LimitMEMLOCK=infinity
LimitSTACK=67108864

  3. 保存并关闭 /etc/systemd/system/docker.service.d/dockeroverride.conf 文件。

  4. 重新加载 systemctl 守护程序。

    sudo systemctl daemon-reload

  5. 重启 Docker。

    sudo systemctl restart docker

NGC 容器的连接要求#

要从 NGC 容器注册表运行 NVIDIA NGC 容器，您的网络必须能够访问以下 URL

要验证与 nvcr.io 的连接，请运行

wget https://nvcr.io/v2

您应该看到连接验证，然后是 401 错误

--2018-08-01 19:42:58-- https://nvcr.io/v2
Resolving nvcr.io (nvcr.io) --> 52.8.131.152, 52.9.8.8
Connecting to nvcr.io (nvcr.io)|52.8.131.152|:443. --> connected.
HTTP request sent, awaiting response. --> 401 Unauthorized

配置网络端口的静态 IP 地址#

以下是配置网络端口的静态 IP 地址的步骤。

在 DGX 系统的初始启动设置过程中，其中一个步骤是为网络接口配置静态 IP 地址。如果您当时未配置地址，则可以使用以下说明从 Ubuntu 命令行配置静态 IP 地址。

注意

如果您要远程连接到 DGX 控制台，请使用 BMC 远程控制台进行连接。如果您使用 SSH 连接，则在完成最后一步时您的连接将丢失。此外，如果您遇到配置文件问题，BMC 连接将有助于故障排除。

如果您无法远程访问 DGX 系统，请将分辨率为 1440x900 或更低的显示器和键盘直接连接到 DGX 系统。

  1. 根据您连接到网络的物理以太网端口，确定要配置的端口指定。请参阅[配置网络代理](index.html#config-network-proxies “如果您的网络需要使用代理服务器，您需要设置配置文件以确保 DGX 系统通过代理进行通信。”)，了解您要配置的连接的端口指定。

  2. 编辑网络配置文件 yaml 文件。

    注意

    确保您的文件与以下示例完全相同，并使用空格而不是制表符。

    sudo vi /etc/netplan/01-netcfg.yaml
network: version: 2
renderer: networkd Ethernets:
<port-designation>: dhcp4: no
dhcp6: no
addresses: [10.10.10.2/24] gateway4: 10.10.10.1 nameservers:
search: [<mydomain>, <other-domain>]
    addresses: [10.10.10.1, 1.1.1.1]

    请咨询您的网络管理员，以获取粗体项目的适当信息，例如网络、网关和名称服务器地址，并使用您在步骤 1 中确定的端口指定。

  3. 完成编辑后，按 ESC 键切换到命令模式。

  4. 将文件保存到磁盘并退出编辑器。

  5. 应用更改。

    sudo netplan apply

注意

如果您在信息后未返回到命令行提示符，请参阅Ubuntu 服务器指南中的 更改、错误和错误。

管理 CPU 缓解措施#

DGX OS 软件包含安全更新，以缓解 CPU 推测性侧信道漏洞。这些缓解措施可能会降低深度学习和机器学习工作负载的性能。

如果您的 DGX 系统安装包含其他措施来缓解这些漏洞，例如集群级别的措施，您可以禁用单个 DGX 节点的 CPU 缓解措施并提高性能。

确定 DGX 系统的 CPU 缓解状态#

以下是关于如何确定 DGX 系统的 CPU 缓解状态的信息。

如果您不知道是否启用或禁用了 CPU 缓解措施，请发出以下命令。

cat /sys/devices/system/cpu/vulnerabilities/*

当输出包含多行以 Mitigation: 为前缀时，CPU 缓解措施为已启用。

例如

KVM: Mitigation: Split huge pages
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable Mitigation: Clear CPU buffers; SMT vulnerable
Mitigation: PTI
Mitigation: Speculative Store Bypass disabled via prctl and seccomp Mitigation: usercopy/swapgs barriers and __user pointer sanitization Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP:
conditional, RSB filling
Mitigation: Clear CPU buffers; SMT vulnerable

如果输出包含多行以 Vulnerable 为前缀时，CPU 缓解措施为已禁用。

KVM: Vulnerable
Mitigation: PTE Inversion; VMX: vulnerable Vulnerable; SMT vulnerable
Vulnerable
Vulnerable
Vulnerable: user pointer sanitization and usercopy barriers only; no swapgs barriers
Vulnerable, IBPB: disabled, STIBP: disabled Vulnerable

禁用 CPU 缓解措施#

以下是禁用 CPU 缓解措施的步骤。

警告：执行以下说明将禁用 DGX OS 软件提供的 CPU 缓解措施。

  1. 安装 nv-mitigations-off 软件包。

    sudo apt install nv-mitigations-off -y

  2. 重启系统。

  3. 验证 CPU 缓解措施是否已禁用。

    cat /sys/devices/system/cpu/vulnerabilities/*

输出应包含几行 vulnerable 行。请参阅 确定 DGX 系统的 CPU 缓解状态 “以下是关于如何确定 DGX 系统 CPU 缓解状态的信息示例输出。

重新启用 CPU 缓解措施#

以下是再次启用 CPU 缓解措施的步骤。

  1. 删除 nv-mitigations-off 软件包。

    sudo apt purge nv-mitigations-off

  2. 重启系统。

  3. 验证 CPU 缓解措施是否已启用。

    cat /sys/devices/system/cpu/vulnerabilities/*

输出应包含几行 Mitigations 行。有关示例输出，请参阅 确定 DGX 系统的 CPU 缓解状态。

管理 DGX 崩溃转储功能#

本节提供关于管理 DGX 崩溃转储功能的信息。您可以使用 DGX OS 中包含的脚本来管理此功能。

使用脚本#

以下命令可帮助您使用脚本完成必要的任务。

  • 要仅启用 dmesg 崩溃转储，请运行

    /usr/sbin/nvidia-kdump-config enable-dmesg-dump

    此选项为崩溃内核保留内存。

  • 要同时启用 dmesg 和 vmcore 崩溃转储，请运行

    /usr/sbin/nvidia-kdump-config enable-vmcore-dump

    此选项为崩溃内核保留内存。

  • 要禁用崩溃转储，请运行

    /usr/sbin/nvidia-kdump-config disable

此选项禁用 kdump 的使用，并确保不为崩溃内核保留内存。

连接到 Serial Over LAN#

您可以连接到 LAN 上的串行端口。

警告

这仅适用于具有 BMC 的系统。

在转储 vmcore 时，BMC 屏幕控制台会在崩溃转储开始后大约 11 分钟变为空白。要查看崩溃转储期间的控制台输出，请按如下方式连接到 LAN 上的串行端口

ipmitool -I lanplus -H -U -P sol activate

文件系统配额#

以下是关于文件系统配额的一些信息。

运行 NGC 容器时，您可能需要限制文件系统上使用的磁盘空间量，以避免填满分区。请参阅 如何在 Ubuntu 18.04 上设置文件系统配额，了解如何在 Ubuntu 18.04 及更高版本上设置文件系统配额。

在具有混合 GPU 类型的系统上运行工作负载#

DGX Station A100 配备了四个高性能 NVIDIA A100 GPU 和一个 DGX 显示 GPU。NVIDIA A100 GPU 用于运行高性能和 AI 工作负载，而 DGX 显示卡用于驱动监视器上的高质量显示。

在此系统上运行应用程序时，重要的是确定启动应用程序和工作负载的最佳方法，以确保使用高性能 NVIDIA A100 GPU。您可以通过以下方式之一实现此目的

当您登录系统并检查可用的 GPU 时，您会发现以下内容

nvidia-smi -L
GPU 0: Graphics Device (UUID: GPU-269d95f8-328a-08a7-5985-ab09e6e2b751)
GPU 1: Graphics Device (UUID: GPU-0f2dff15-7c85-4320-da52-d3d54755d182)
GPU 2: Graphics Device (UUID: GPU-dc598de6-dd4d-2f43-549f-f7b4847865a5)
GPU 3: DGX Display (UUID: GPU-91b9d8c8-e2b9-6264-99e0-b47351964c52)
GPU 4: Graphics Device (UUID: GPU-e32263f2-ae07-f1db-37dc-17d1169b09bf)

nvidia-smi 列出了总共五个 GPU。这是因为 nvidia-smi 包括了用于驱动监视器和高质量图形输出的 DGX 显示 GPU。

当运行应用程序或工作负载时，DGX 显示 GPU 可能会妨碍，因为它不具有直接的 NVlink 连接、足够的内存或安装在系统上的 NVIDIA A100 GPU 的性能特征。因此，您应确保正在使用正确的 GPU。

使用 Docker 容器运行#

在 DGX OS 上，由于 Docker 已配置为识别高性能 NVIDIA A100 GPU 并将 GPU 分配给容器，因此此方法是最简单的。

一个简单的测试是使用 [–gpus all] 标志在命令中运行一个小容器，并在正在运行 nvidia-smi 的容器中运行一次。输出显示只有高性能 GPU 可用于容器

docker run --gpus all --rm -it ubuntu nvidia-smi -L
GPU 0: Graphics Device (UUID: GPU-269d95f8-328a-08a7-5985-ab09e6e2b751)
GPU 1: Graphics Device (UUID: GPU-0f2dff15-7c85-4320-da52-d3d54755d182)
GPU 2: Graphics Device (UUID: GPU-dc598de6-dd4d-2f43-549f-f7b4847865a5)
GPU 3: Graphics Device (UUID: GPU-e32263f2-ae07-f1db-37dc-17d1169b09bf)

当使用 --gpus n 标志时，此步骤也适用，其中 n 可以是 1、2、3 或 4。这些值表示应分配给该容器的 GPU 数量。例如

docker run --gpus 2 --rm -it ubuntu nvidia-smi -L
GPU 0: Graphics Device (UUID: GPU-269d95f8-328a-08a7-5985-ab09e6e2b751)
GPU 1: Graphics Device (UUID: GPU-0f2dff15-7c85-4320-da52-d3d54755d182)

在此示例中，Docker 选择前两个 GPU 运行容器，但如果使用 device 选项，您可以指定要使用的 GPU

docker run --gpus '"device=GPU-dc598de6-dd4d-2f43-549f-f7b4847865a5,GPU-e32263f2-ae07-f1db-37dc-17d1169b09bf"' --rm -it ubuntu nvidia-smi -L
GPU 0: Graphics Device (UUID: GPU-dc598de6-dd4d-2f43-549f-f7b4847865a5)
GPU 1: Graphics Device (UUID: GPU-e32263f2-ae07-f1db-37dc-17d1169b09bf)

在此示例中，先前未使用的两个 GPU 现在被分配到容器上运行。

在裸机上运行#

要使用四个高性能 GPU 运行应用程序，必须在运行应用程序之前指定 CUDA_VISIBLE_DEVICES 变量。

注意

此方法不使用容器。

CUDA 按性能对 GPU 进行排序，因此 GPU 0 将是性能最高的 GPU，而最后一个 GPU 将是性能最低的 GPU。

警告

如果 CUDA_DEVICE_ORDER 变量设置为 PCI_BUS_ID，则此排序将被覆盖。

在以下示例中，运行 CUDA 示例附带的 CUDA 应用程序。在输出中，GPU 0 是 DGX Station A100 中最快的，而 GPU 4 (DGX 显示 GPU) 是最慢的

sudo apt install cuda-samples-11-2

cd /usr/local/cuda-11.2/samples/1_Utilities/p2pBandwidthLatencyTest

sudo make
/usr/local/cuda/bin/nvcc -ccbin g++ -I../../common/inc  -m64    --threads
0 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37
-gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52
-gencode arch=compute_60,code=sm_60 -gencode arch=compute_61,code=sm_61
-gencode arch=compute_70,code=sm_70 -gencode arch=compute_75,code=sm_75
-gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86
-gencode arch=compute_86,code=compute_86 -o p2pBandwidthLatencyTest.o -c p2pBandwidthLatencyTest.cu
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
/usr/local/cuda/bin/nvcc -ccbin g++   -m64
-gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37
-gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52
-gencode arch=compute_60,code=sm_60 -gencode arch=compute_61,code=sm_61
-gencode arch=compute_70,code=sm_70 -gencode arch=compute_75,code=sm_75
-gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86
-gencode arch=compute_86,code=compute_86 -o p2pBandwidthLatencyTest p2pBandwidthLatencyTest.o
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' and 'sm_50' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
mkdir -p ../../bin/x86_64/linux/release
cp p2pBandwidthLatencyTest ../../bin/x86_64/linux/release
lab@ro-dvt-058-80gb:/usr/local/cuda-11.2/samples/1_Utilities/p2pBandwidthLatencyTest cd /usr/local/cuda-11.2/samples/bin/x86_64/linux/release
lab@ro-dvt-058-80gb:/usr/local/cuda-11.2/samples/bin/x86_64/linux/release ./p2pBandwidthLatencyTest
[P2P (Peer-to-Peer) GPU Bandwidth Latency Test]
Device: 0, Graphics Device, pciBusID: 1, pciDeviceID: 0, pciDomainID:0
Device: 1, Graphics Device, pciBusID: 47, pciDeviceID: 0, pciDomainID:0
Device: 2, Graphics Device, pciBusID: 81, pciDeviceID: 0, pciDomainID:0
Device: 3, Graphics Device, pciBusID: c2, pciDeviceID: 0, pciDomainID:0
Device: 4, DGX Display, pciBusID: c1, pciDeviceID: 0, pciDomainID:0
Device=0 CAN Access Peer Device=1
Device=0 CAN Access Peer Device=2
Device=0 CAN Access Peer Device=3
Device=0 CANNOT Access Peer Device=4
Device=1 CAN Access Peer Device=0
Device=1 CAN Access Peer Device=2
Device=1 CAN Access Peer Device=3
Device=1 CANNOT Access Peer Device=4
Device=2 CAN Access Peer Device=0
Device=2 CAN Access Peer Device=1
Device=2 CAN Access Peer Device=3
Device=2 CANNOT Access Peer Device=4
Device=3 CAN Access Peer Device=0
Device=3 CAN Access Peer Device=1
Device=3 CAN Access Peer Device=2
Device=3 CANNOT Access Peer Device=4
Device=4 CANNOT Access Peer Device=0
Device=4 CANNOT Access Peer Device=1
Device=4 CANNOT Access Peer Device=2
Device=4 CANNOT Access Peer Device=3

注意

如果设备无法与其他设备进行 P2P 访问，则会回退到正常的内存复制过程。因此，在这些情况下，您可以看到较低的带宽 (GB/s) 和不稳定的延迟 (us)。

P2P Connectivity Matrix
     D\D     0     1     2     3     4
     0       1     1     1     1     0
     1       1     1     1     1     0
     2       1     1     1     1     0
     3       1     1     1     1     0
     4       0     0     0     0     1
Unidirectional P2P=Disabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3      4
     0 1323.03  15.71  15.37  16.81  12.04
     1  16.38 1355.16  15.47  15.81  11.93
     2  16.25  15.85 1350.48  15.87  12.06
     3  16.14  15.71  16.80 1568.78  11.75
     4  12.61  12.47  12.68  12.55 140.26
Unidirectional P2P=Enabled Bandwidth (P2P Writes) Matrix (GB/s)
   D\D     0      1      2      3      4
     0 1570.35  93.30  93.59  93.48  12.07
     1  93.26 1583.08  93.55  93.53  11.93
     2  93.44  93.58 1584.69  93.34  12.05
     3  93.51  93.55  93.39 1586.29  11.79
     4  12.68  12.54  12.75  12.51 140.26
Bidirectional P2P=Disabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3      4
     0 1588.71  19.60  19.26  19.73  16.53
     1  19.59 1582.28  19.85  19.13  16.43
     2  19.53  19.39 1583.88  19.61  16.58
     3  19.51  19.11  19.58 1592.76  15.90
     4  16.36  16.31  16.39  15.80 139.42
Bidirectional P2P=Enabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3      4
     0 1590.33 184.91 185.37 185.45  16.46
     1 185.04 1587.10 185.19 185.21  16.37
     2 185.15 185.54 1516.25 184.71  16.47
     3 185.55 185.32 184.86 1589.52  15.71
     4  16.26  16.28  16.16  15.69 139.43
P2P=Disabled Latency Matrix (us)
   GPU     0      1      2      3      4
     0   3.53  21.60  22.22  21.38  12.46
     1  21.61   2.62  21.55  21.65  12.34
     2  21.57  21.54   2.61  21.55  12.40
     3  21.57  21.54  21.58   2.51  13.00
     4  13.93  12.41  21.42  21.58   1.14

   CPU     0      1      2      3      4
     0   4.26  11.81  13.11  12.00  11.80
     1  11.98   4.11  11.85  12.19  11.89
     2  12.07  11.72   4.19  11.82  12.49
     3  12.14  11.51  11.85   4.13  12.04
     4  12.21  11.83  12.11  11.78   4.02
P2P=Enabled Latency (P2P Writes) Matrix (us)
   GPU     0      1      2      3      4
     0   3.79   3.34   3.34   3.37  13.85
     1   2.53   2.62   2.54   2.52  12.36
     2   2.55   2.55   2.61   2.56  12.34
     3   2.58   2.51   2.51   2.53  14.39
     4  19.77  12.32  14.75  21.60   1.13

   CPU     0      1      2      3      4
     0   4.27   3.63   3.65   3.59  13.15
     1   3.62   4.22   3.61   3.62  11.96
     2   3.81   3.71   4.35   3.73  12.15
     3   3.64   3.61   3.61   4.22  12.06
     4  12.32  11.92  13.30  12.03   4.05

注意

CUDA 示例并非用于性能测量。启用 GPU Boost 时，结果可能会有所不同。

上面的示例显示了跨所有五个 GPU（包括 DGX 显示 GPU）的点对点带宽和延迟测试。该应用程序还显示，任何 GPU 和 GPU 4 之间都没有点对点连接。这表明 GPU 4 不应用于高性能工作负载。

通过使用 CUDA_VISIBLE_DEVICES 变量再次运行该示例，该变量限制了应用程序可以看到的 GPU 数量。

注意

所有 GPU 都可以与所有其他对等设备通信。

 CUDA_VISIBLE_DEVICES=0,1,2,3 ./p2pBandwidthLatencyTest
[P2P (Peer-to-Peer) GPU Bandwidth Latency Test]
Device: 0, Graphics Device, pciBusID: 1, pciDeviceID: 0, pciDomainID:0
Device: 1, Graphics Device, pciBusID: 47, pciDeviceID: 0, pciDomainID:0
Device: 2, Graphics Device, pciBusID: 81, pciDeviceID: 0, pciDomainID:0
Device: 3, Graphics Device, pciBusID: c2, pciDeviceID: 0, pciDomainID:0
Device=0 CAN Access Peer Device=1
Device=0 CAN Access Peer Device=2
Device=0 CAN Access Peer Device=3
Device=1 CAN Access Peer Device=0
Device=1 CAN Access Peer Device=2
Device=1 CAN Access Peer Device=3
Device=2 CAN Access Peer Device=0
Device=2 CAN Access Peer Device=1
Device=2 CAN Access Peer Device=3
Device=3 CAN Access Peer Device=0
Device=3 CAN Access Peer Device=1
Device=3 CAN Access Peer Device=2

注意

如果设备无法与其他设备进行 P2P 访问，则会回退到正常的内存复制过程。因此，在这些情况下，您可以看到较低的带宽 (GB/s) 和不稳定的延迟 (us)。

P2P Connectivity Matrix
     D\D     0     1     2     3
     0       1     1     1     1
     1       1     1     1     1
     2       1     1     1     1
     3       1     1     1     1
Unidirectional P2P=Disabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3
     0 1324.15  15.54  15.62  15.47
     1  16.55 1353.99  15.52  16.23
     2  15.87  17.26 1408.93  15.91
     3  16.33  17.31  18.22 1564.06
Unidirectional P2P=Enabled Bandwidth (P2P Writes) Matrix (GB/s)
   D\D     0      1      2      3
     0 1498.08  93.30  93.53  93.48
     1  93.32 1583.08  93.54  93.52
     2  93.55  93.60 1583.08  93.36
     3  93.49  93.55  93.28 1576.69
Bidirectional P2P=Disabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3
     0 1583.08  19.92  20.47  19.97
     1  20.74 1586.29  20.06  20.22
     2  20.08  20.59 1590.33  20.01
     3  20.44  19.92  20.60 1589.52
Bidirectional P2P=Enabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3
     0 1592.76 184.88 185.21 185.30
     1 184.99 1589.52 185.19 185.32
     2 185.28 185.30 1585.49 185.01
     3 185.45 185.39 184.84 1587.91
P2P=Disabled Latency Matrix (us)
   GPU     0      1      2      3
     0   2.38  21.56  21.61  21.56
     1  21.70   2.34  21.54  21.56
     2  21.55  21.56   2.41  21.06
     3  21.57  21.34  21.56   2.39

   CPU     0      1      2      3
     0   4.22  11.99  12.71  12.09
     1  11.86   4.09  12.00  11.71
     2  12.52  11.98   4.27  12.24
     3  12.22  11.75  12.19   4.25
P2P=Enabled Latency (P2P Writes) Matrix (us)
   GPU     0      1      2      3
     0   2.32   2.57   2.55   2.59
     1   2.55   2.32   2.59   2.52
     2   2.59   2.56   2.41   2.59
     3   2.57   2.55   2.56   2.40

   CPU     0      1      2      3
     0   4.24   3.57   3.72   3.81
     1   3.68   4.26   3.75   3.63
     2   3.79   3.75   4.34   3.71
     3   3.72   3.64   3.66   4.32

注意

CUDA 示例并非用于性能测量。启用 GPU Boost 时，结果可能会有所不同。

对于裸机应用程序，也可以在 [CUDA_VISIBLE_DEVICES] 变量中指定 UUID，如下所示

CUDA_VISIBLE_DEVICES=GPU-0f2dff15-7c85-4320-da52-d3d54755d182,GPU-dc598de6-dd4d-2f43-549f-f7b4847865a5 ./p2pBandwidthLatencyTest

由于 UUID 的性质，GPU 规范更长，但这​​是将特定 GPU 绑定到应用程序的最精确方法。

使用多实例 GPU#

多实例 GPU (MIG) 在 NVIDIA A100 GPU 上可用。如果在 GPU 上启用了 MIG，并且 GPU 已分区，则可以将应用程序限制为在这些设备上运行。

这适用于 Docker 容器和裸机，使用 [CUDA_VISIBLE_DEVICES]，如下面的示例所示。有关如何配置和使用 MIG 的说明，请参阅 NVIDIA 多实例 GPU 用户指南。

识别将要使用的 MIG 实例。以下是 GPU 0 分区为 7 个 MIG 的系统的输出

nvidia-smi -L
GPU 0: Graphics Device (UUID: GPU-269d95f8-328a-08a7-5985-ab09e6e2b751)
  MIG 1g.10gb Device 0: (UUID: MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/7/0)
  MIG 1g.10gb Device 1: (UUID: MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/8/0)
  MIG 1g.10gb Device 2: (UUID: MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/9/0)
  MIG 1g.10gb Device 3: (UUID: MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/11/0)
  MIG 1g.10gb Device 4: (UUID: MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/12/0)
  MIG 1g.10gb Device 5: (UUID: MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/13/0)
  MIG 1g.10gb Device 6: (UUID: MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/14/0)
GPU 1: Graphics Device (UUID: GPU-0f2dff15-7c85-4320-da52-d3d54755d182)
GPU 2: Graphics Device (UUID: GPU-dc598de6-dd4d-2f43-549f-f7b4847865a5)
GPU 3: DGX Display (UUID: GPU-91b9d8c8-e2b9-6264-99e0-b47351964c52)
GPU 4: Graphics Device (UUID: GPU-e32263f2-ae07-f1db-37dc-17d1169b09bf)

在 Docker 中，从此输出中输入 MIG UUID，其中已选择 GPU 0 和 Device 0。

如果您在 DGX Station A100 上运行，请在创建、销毁或修改 MIG 实例时随时重启 nv-docker-gpus 和 docker 系统服务，方法是运行以下命令

sudo systemctl restart nv-docker-gpus; sudo systemctl restart docker

nv-docker-gpus 必须在 DGX Station A100 上重启，因为此服务用于屏蔽 Docker 可以使用的可用 GPU。当 GPU 架构更改时，需要刷新该服务。

docker run --gpus '"device=MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/7/0"' --rm -it ubuntu nvidia-smi -L
GPU 0: Graphics Device (UUID: GPU-269d95f8-328a-08a7-5985-ab09e6e2b751)
  MIG 1g.10gb Device 0: (UUID: MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/7/0)

在裸机上，指定 MIG 实例

注意

此应用程序测量跨 GPU 的通信，并且仅使用一个 GPU MIG 读取带宽和延迟是不相关的。

此示例的目的是说明如何将特定 GPU 与应用程序一起使用，如下所示。

  1. 转到以下目录

    cd /usr/local/cuda-11.2/samples/bin/x86_64/linux/release

  2. 运行 p2pBandwidthLatencyTest

    CUDA_VISIBLE_DEVICES=MIG-GPU-269d95f8-328a-08a7-5985-ab09e6e2b751/7/0 ./p2pBandwidthLatencyTest
[P2P (Peer-to-Peer) GPU Bandwidth Latency Test]
Device: 0, Graphics Device MIG 1g.10gb, pciBusID: 1, pciDeviceID: 0, pciDomainID:0

注意

如果设备无法与其他设备进行 P2P 访问，则会回退到正常的内存复制过程。因此，在这些情况下，您可以看到较低的带宽 (GB/s) 和不稳定的延迟 (us)。

P2P Connectivity Matrix
     D\D     0
     0       1
Unidirectional P2P=Disabled Bandwidth Matrix (GB/s)
   D\D     0
     0 176.20
Unidirectional P2P=Enabled Bandwidth (P2P Writes) Matrix (GB/s)
   D\D     0
     0 187.87
Bidirectional P2P=Disabled Bandwidth Matrix (GB/s)
   D\D     0
     0 190.77
Bidirectional P2P=Enabled Bandwidth Matrix (GB/s)
   D\D     0
     0 190.53
P2P=Disabled Latency Matrix (us)
   GPU     0
     0   3.57

   CPU     0
     0   4.07
P2P=Enabled Latency (P2P Writes) Matrix (us)
   GPU     0
     0   3.55

   CPU     0
     0   4.07

注意

CUDA 示例并非用于性能测量。启用 GPU Boost 时，结果可能会有所不同。

数据存储配置#

默认情况下，DGX 系统在 RAID 0 配置中包含多个驱动器。这些驱动器旨在用于应用程序缓存，因此您

将数据存储用于 NFS 缓存#

本节提供关于如何将数据存储用于 NFS 缓存的信息。

DGX 系统使用 cachefilesd 来管理 NFS 缓存。

  • 确保您有一个 NFS 服务器，其中包含一个或多个导出，其中包含 DGX 系统将访问的数据

  • 确保 DGX 系统和 NFS 服务器之间存在网络访问。

使用 cachefilesd#

以下步骤描述了如何在 DGX 系统上挂载 NFS，以及如何通过使用 DGX SSD 缓存 NFS 以提高性能。

  1. 为 DGX 系统配置 NFS 挂载。

    1. 编辑文件系统表配置。

      sudo vi /etc/fstab

    2. 通过使用本地 /mnt 本地挂载点，为 NFS 挂载添加新行。

      <nfs_server>:<export_path> /mnt nfs rw,noatime,rsize=32768,wsize=32768,nolock,tcp,intr,fsc,nofail 0 0

      此处，/mnt 用作示例挂载点。

      • 请联系您的网络管理员，以获取 <nfs_server> 和 <export_path> 的正确值。

      • 此处提供的 nfs 参数是基于典型用例的推荐值列表。但是，fsc 必须始终包含在内，因为该参数指定使用 FS-Cache

    1. 保存更改。

  2. 验证 NFS 服务器是否可访问。

    ping <nfs_server>

    使用您的网络管理员提供的服务器 IP 地址或服务器名称。

  3. 挂载 NFS 导出。

    sudo mount /mnt

    /mnt 是一个示例挂载点。

  4. 验证是否已启用缓存。

    cat /proc/fs/nfsfs/volumes

  1. 在输出中，查找 FSC=yes。

    NFS 将在后续重启周期中自动挂载并在 DGX 系统上缓存。

禁用 cachefilesd#

以下是关于如何禁用 cachefilesd 的一些信息。

如果您不想通过运行来启用 cachefilesd

  1. 停止 cachefilesd 服务

    sudo systemctl stop cachefilesd

  2. 永久禁用 cachefilesd 服务

    sudo systemctl disable cachefilesd

更改数据驱动器的 RAID 配置#

以下信息描述了如何更改数据驱动器的 RAID 配置。

警告

您必须至少有 2 个驱动器才能完成这些任务。如果您少于 2 个驱动器，您无法完成这些任务。

出厂时，DGX RAID 阵列的 RAID 级别为 RAID 0。此级别提供最大的存储容量，但不提供冗余。如果阵列中的一个 SSD 发生故障，则阵列上存储的数据将丢失。如果您愿意接受容量减少以换取一定程度的驱动器故障保护，您可以将 RAID 阵列的级别更改为 RAID 5。

注意

如果您将 RAID 级别从 RAID 0 更改为 RAID 5，则 RAID 阵列的总存储容量将减少。

在更改 DGX RAID 阵列的 RAID 级别之前，请备份您要保留的阵列上的数据。当您更改 DGX RAID 阵列的 RAID 级别时，阵列上存储的数据将被擦除。

您可以使用系统上安装的 configure_raid_array.py 自定义脚本来更改 RAID 阵列的级别，而无需卸载 RAID 卷。

  • 要将 RAID 级别更改为 RAID 5，请运行以下命令

    sudo configure_raid_array.py -m raid5

    将 RAID 级别更改为 RAID 5 后，将重建 RAID 阵列。虽然正在重建的 RAID 阵列处于联机状态并可以使用，但对 DGX 系统运行状况的检查会报告 RAID 卷的状态为不健康。重建 RAID 阵列所需的时间取决于系统上的工作负载。例如，在空闲系统上，重建可能在 30 分钟内完成。

  • 要将 RAID 级别更改为 RAID 0，请运行以下命令

    sudo configure_raid_array.py -m raid0

要确认 RAID 级别已更改，请运行 lsblk 命令。RAID 阵列中每个驱动器的 TYPE 列中的条目指示阵列的 RAID 级别。

运行 NGC 容器#

本节提供关于如何使用 DGX 系统运行 NGC 容器的信息。

获取 NGC 帐户#

以下是关于如何获取 NGC 帐户的一些信息。

NVIDIA NGC 提供对 GPU 优化软件的简单访问，用于深度学习、机器学习和高性能计算 (HPC)。NGC 帐户授予您访问这些工具的权限，并使您能够设置私有注册表来管理您的自定义软件。

如果您是 DGX 系统购买的组织管理员，请与 NVIDIA 企业支持部门合作设置 NGC 企业帐户。有关获取 NGC 企业帐户的更多信息，请参阅 NGC 私有注册表用户指南。

运行支持 GPU 的 NGC 容器#

为了在 DGX 系统上运行 NGC 容器时获得最佳性能，您可以使用以下方法之一为 Docker 容器提供 GPU 支持

  • 原生 GPU 支持（包含在 Docker 19.03 及更高版本中，已安装）

  • 用于 Docker 的 NVIDIA 容器运行时

这在 nvidia-docker2 软件包中。

DGX OS 5 的推荐方法是原生 GPU 支持。要运行启用 GPU 的容器，请运行 docker run --gpus。

以下是使用所有 GPU 的示例

docker run --gpus all …

以下是使用 2 个 GPU 的示例

docker run --gpus 2 …

以下是使用特定 GPU 的示例

docker run --gpus '"device=1,2"' ...

docker run --gpus '"device=UUID-ABCDEF-

有关在 MIG 设备上运行 NGC 容器的更多信息，请参阅 运行容器。

在本页中