系统配置#

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

另请参阅 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 驱动程序的主机。

您可以通过运行 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) 表示端口配置为以太网。

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

DGX B200 网络端口，位于 NVIDIA DGX B200 系统用户指南 中
DGX H100/H200 网络端口，位于 NVIDIA DGX H100/H200 系统用户指南 中
DGX A100 网络端口，位于 NVIDIA DGX A100 系统用户指南 中

配置端口#

将 mlxconfig 命令与 set LINK_TYPE_P<x> 参数一起使用，用于要配置的每个端口。

以下示例命令将 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/noble/x86_64/ （您只能使用 apt-get 访问此 URL，而不能在浏览器中访问）
https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/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 缓解状态以获取示例输出。

启用 init_on_alloc 的性能影响#

CONFIG_INIT_ON_ALLOC_DEFAULT_ON Linux 内核配置选项控制内核是否默认使用零填充新分配的页面和堆对象。您可以使用 init_on_alloc=<0|1> 内核参数覆盖此设置。NVIDIA DGX 系统上预装的 DGX OS 设置 init_on_alloc=1，因为此设置是 Ubuntu 为内核加固推荐的默认设置。但是，此设置可能会对 DGX 系统上的网络接口控制器性能产生性能影响，因为在分配时将每个缓冲区页面归零是很频繁的，并且需要时间才能完成。与 Mellanox OFED (MOFED) 驱动程序相比，此选项对 inbox OFED 驱动程序的影响更大。MOFED 驱动程序分配了更大的页面缓存，可以更好地容忍零页面增加的内核成本。NVIDIA 建议保留默认设置 init_on_alloc=1 以获得最佳安全性。如果您的部署允许不太严格的安全性，并且网络接口控制器性能不佳，则可以禁用此安全功能。

编辑 /etc/default/grub 文件，并将 init_on_alloc=0 添加到 GRUB_CMDLINE_LINUX_DEFAULT 变量。
生成 GRUB 引导加载程序。
```
sudo update-grub
sudo reboot
```

可选：系统重启后，验证更改是否生效。

cat /proc/cmdline

示例输出

BOOT_IMAGE=/boot/vmlinuz-... init_on_alloc=0

管理 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 的 DGX 系统。

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

ipmitool -I lanplus -H <BMC-IP> -U <username> -P <password> 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，则此排序将被覆盖。

NVIDIA 提供了一个开源实用程序 nvbandwidth，用于测量 NVIDIA GPU 上的带宽。

有关下载、构建和运行 nvbandwidth 的信息，请参阅 NVIDIA/nvbandwidth。

使用多实例 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/ 目录 中创建一个 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 配置。

注意

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

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