系统配置#

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

另请参阅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/";

将 ConnectX 从 InfiniBand 配置为以太网#

许多 DGX 系统配备了 NVIDIA ConnectX 网络控制器，通常用于集群通信。默认情况下，控制器配置为 InfiniBand 端口。可选地，您可以将端口配置为以太网。

在您重新配置端口之前或之后，请确保连接到该端口的网络交换机也重新配置为以太网，或者该端口连接到配置为以太网的不同交换机。

以下各节中的代码示例显示了 mlxconfig 命令。mlxconfig 命令适用于使用 MLNX_OFED 驱动程序的主机。如果您的主机使用 Inbox OFED 驱动程序，请替换为 mstconfig 命令。

您可以通过运行 sudo nvidia-manage-ofed.py -s 命令来确定您的主机是否使用 MLNX_OFED 驱动程序。如果输出在 Mellanox OFED Packages Installed: 字段下方显示软件包名称，则表示已安装 MLNX_OFED 驱动程序。

确定当前端口配置#

执行以下步骤以确定端口的当前配置。

查询设备

sudo mlxconfig -e query | egrep -e Device\|LINK_TYPE

以下示例显示了 NVIDIA DGX 100 系统上其中一个端口设备的输出。输出显示设备路径以及默认、当前和下次启动配置，它们都设置为 IB(1)。

Device #9:
Device type:    ConnectX6
Device:         0000:e1:00.0
*        LINK_TYPE_P1                  IB(1)           IB(1)          IB(1)
*        LINK_TYPE_P2                  IB(1)           IB(1)          IB(1)

IB(1) 表示端口配置为 InfiniBand。
ETH(2) 表示端口配置为以太网。

确定您要配置的端口的插槽号的设备路径总线号。有关更多信息，请参阅以下文档

《NVIDIA DGX H100/H200 系统用户指南》中的DGX H100/H200 网络端口。
《NVIDIA DGX A100 系统用户指南》中的DGX A100 网络端口。

配置端口#

对于您要配置的每个端口，使用带有 set LINK_TYPE_P<x> 参数的 mlxconfig 命令。

以下示例命令将 PCI ID 为 e1:00.0 的控制器的端口 1 设置为以太网 (2)

sudo mlxconfig -y -d e1:00.0 set LINK_TYPE_P1=2

以下示例输出来自 NVIDIA DGX A100 系统。

Device #1:
----------

Device type:    ConnectX6
Name:           MCX653106A-HDA_Ax
Description:    ConnectX-6 VPI adapter card; HDR IB (200Gb/s) and 200GbE; dual-port QSFP56; PCIe4.0 x16; tall bracket; ROHS R6
Device:         e1:00.0

Configurations:                                      Next Boot       New
         LINK_TYPE_P1                                ETH(2)          IB(1)

 Apply new Configuration? (y/n) [n] : y
Applying... Done!
-I- Please reboot machine to load new configurations.

以下是将端口 2 设置为以太网的示例

sudo mlxconfig -y -d e1:00.0 set LINK_TYPE_P2=2

（可选）再次运行 mlxconfig 以确认更改

sudo mlxconfig -e query |egrep -e Device\|LINK_TYPE

在以下输出中，端口 LINK_TYPE_2 在下次启动时设置为 ETH(2)。输出显示设备路径以及默认、当前和下次启动配置。

...
Device #9:
Device type:    ConnectX6
Device:         0000:e1:00.0
*        LINK_TYPE_P1                  IB(1)           IB(1)          IB(1)
*        LINK_TYPE_P2                  IB(1)           IB(1)          ETH(2)

对系统执行交流电源循环，以使更改生效。

等待操作系统启动。

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/docker-override.conf 文件来更改默认 Docker 网络地址。这些说明提供了一个修改 /etc/systemd/system/docker.service.d/docker-override.conf 以覆盖默认 Docker 网络地址的示例。

打开 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

进行以下以粗体显示的更改，为您的网络设置正确的桥接 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

保存并关闭 /etc/systemd/system/docker.service.d/docker-override.conf 文件。
重新加载 systemctl 守护程序。
```
sudo systemctl daemon-reload
```
重启 Docker。
```
sudo systemctl restart docker
```

NGC 容器的连接要求#

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

http://archive.ubuntu.com/ubuntu/
http://security.ubuntu.com/ubuntu/
http://repo.download.nvidia.com/baseos/ubuntu/jammy/x86_64/（您只能使用 apt-get 访问此 URL，而不能在浏览器中访问）
https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/
https://nvcr.io/

要验证与 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 系统。

根据您已连接到网络的物理以太网端口，确定您要配置的端口指定。

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

有关您要配置的连接的端口指定，请参阅配置网络代理。

编辑网络配置 YAML 文件 /etc/netplan/01-netcfg.yaml，并进行以下编辑。

注意

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

# This file describes the network interfaces available on your system
# For more information, see netplan(5).

network:
  version: 2
  renderer: networkd
  ethernets:
    enp226s0:
      dhcp4: no
      addresses:
        - 10.10.10.2/24
      routes:
        - to: default
          via: 10.10.10.1
      nameservers:
        addresses: [ 8.8.8.8 ]

请咨询您的网络管理员以获取特定于您站点的数值，例如网络、网关和名称服务器地址。将 enp226s0 替换为您在上一步中确定的指定。

保存文件。
应用更改。
```
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 缓解措施。

安装 nv-mitigations-off 软件包。
```
sudo apt install nv-mitigations-off -y
```
重启系统。

验证 CPU 缓解措施已禁用。

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

输出应包含多个 vulnerable 行。请参阅确定 DGX 系统的 CPU 缓解状态，其中提供了关于如何确定 DGX 系统的 CPU 缓解状态的示例输出信息。

重新启用 CPU 缓解措施#

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

移除 nv-mitigations-off 软件包。
```
sudo apt purge nv-mitigations-off
```
重启系统。

验证 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 的使用，并确保不为崩溃内核保留任何内存。

连接到 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 Display GPU。NVIDIA A100 GPU 用于运行高性能和 AI 工作负载，DGX Display 卡用于驱动监视器上的高质量显示。

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

使用 Docker 容器运行
在裸机上运行
使用多实例 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 Display GPU。

在运行应用程序或工作负载时，DGX Display 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 Display 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 访问另一个设备，它将回退到正常的 memcopy 过程。因此，在这些情况下，您可以看到带宽 (GB/s) 较低且延迟 (us) 不稳定。

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

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

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

注意

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

上面的示例显示了跨所有五个 GPU（包括 DGX Display 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 访问另一个设备，它将回退到正常的 memcopy 过程。因此，在这些情况下，您可以看到带宽 (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 时，结果可能会有所不同。

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

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 与应用程序一起使用，如下所示。

转到以下目录

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

运行 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 访问另一个设备，它将回退到正常的 memcopy 过程。因此，在这些情况下，您可以看到带宽 (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 时，结果可能会有所不同。

更新 MIG 配置的 containerd 覆盖文件#

当您添加 MIG 实例时，containerd 覆盖文件不会自动更新，并且您添加的新 MIG 实例不会添加到允许文件中。当 DGX Station A100 启动时，在 nv-docker-gpus 服务运行后，会在 /etc/systemd/system/containerd.service.d/ directory 目录中创建一个 containerd 覆盖文件。

注意

此文件阻止 Docker 在 DGX Station A100 上使用显示 GPU。

以下是覆盖文件的示例

[Service]
DeviceAllow=/dev/nvidia1
DeviceAllow=/dev/nvidia2
DeviceAllow=/dev/nvidia3
DeviceAllow=/dev/nvidia4
DeviceAllow=/dev/nvidia-caps/nvidia-cap1
DeviceAllow=/dev/nvidia-caps/nvidia-cap2
DeviceAllow=/dev/nvidiactl
DeviceAllow=/dev/nvidia-modeset
DeviceAllow=/dev/nvidia-uvm
DeviceAllow=/dev/nvidia-uvm-tools

该服务只能添加它知道的设备。为了确保您的新 MIG 实例已添加到允许列表中，请完成以下步骤

要刷新覆盖文件，请运行以下命令

sudo systemctl restart nv-docker-gpus

sudo systemctl restart docker

验证您的新 MIG 实例现在是否在容器中被允许。以下是更新后的覆盖文件的示例

|       ID ID Dev |                 BAR1-Usage |  SM    Unc| CE ENC DEC OFA JPG    |
|                  |                      |        ECC|                       |
|==================+======================+===========+=======================|
| 0      0   0   0 |      0MiB / 81252MiB |  98      0|  7   0   5   1   1    |
|                  |      1MiB / 13107... |           |                       |
+------------------+----------------------+-----------+-----------------------+
| Processes:                                                                  |
| GPU   GI     CI     PID Type    Process name    GPU Memory                    |
|       ID     ID     Usage                                                   |
|=============================================================================|
| No running processes found                                                  |

数据存储配置#

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

将数据存储用于 NFS 缓存#

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

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

确保您有一个 NFS 服务器，其中包含一个或多个包含 DGX 系统将访问的数据的导出。
确保 DGX 系统和 NFS 服务器之间存在网络访问。

使用 cachefilesd#

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

为 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. 保存更改。
验证 NFS 服务器是否可访问。
```
ping <nfs_server>
```
使用您的网络管理员提供的服务器 IP 地址或服务器名称。
挂载 NFS 导出。
```
sudo mount /mnt
```
/mnt 是一个示例挂载点。
验证是否已启用缓存。
```
cat /proc/fs/nfsfs/volumes
```

在输出中，找到 FSC=yes。

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

禁用 cachefilesd#

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

如果您不想通过运行以下命令启用 cachefilesd

停止 cachefilesd 服务
```
sudo systemctl stop cachefilesd
```
永久禁用 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 及更高版本中，已安装）
NVIDIA Container Runtime for Docker

这在 nvidia-docker2 软件包中。

DGX OS 6 的推荐方法是原生 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 容器的更多信息，请参阅运行容器。

系统配置#

网络配置#

配置网络代理#

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

对于 apt 包管理器#

将 ConnectX 从 InfiniBand 配置为以太网#

确定当前端口配置#

配置端口#

将 ConnectX 从 InfiniBand 配置为以太网的相关信息#

Docker 配置#

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

允许用户运行 Docker 容器#

配置 Docker IP 地址#

NGC 容器的连接要求#

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

管理 CPU 缓解措施#

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

禁用 CPU 缓解措施#

重新启用 CPU 缓解措施#

管理 DGX 崩溃转储功能#

使用脚本#

连接到 LAN 上的串行端口#

文件系统配额#

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

使用 Docker 容器运行#

在裸机上运行#

使用多实例 GPU#

更新 MIG 配置的 containerd 覆盖文件#

数据存储配置#

将数据存储用于 NFS 缓存#

使用 cachefilesd#

禁用 cachefilesd#

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

运行 NGC 容器#

获取 NGC 帐户#

使用 GPU 支持运行 NGC 容器#