- DCGM、dcgm-exporter 和 Metricbeat 的组合可以对 Linux 上的 NVIDIA GPU 的内存、温度和性能进行详细监控。
- Elastic Observability 和 Kibana 可以轻松地分析和可视化 GPU 指标以及 CPU 指标，从而检测瓶颈和基础设施问题。
- 调整自动加速、电源配置文件和 GPU 时钟频率是实现数据中心和游戏稳定和最大性能的关键。
- 在 Linux 系统上，高端 NVIDIA GPU 比 AMD GPU 提供更好的支持和性能，尤其是在要求苛刻的游戏和 4K 工作负载方面。
如果你在 Linux 系统上使用 NVIDIA GPU，迟早都需要了解系统的内存、性能和内部统计数据。无论是用于游戏、机器学习、科学模拟还是数据中心，监控这些数据都能决定你的机器是仅仅“能用”还是真正优化。
同时，许多用户期望在 Linux 系统下使用 NVIDIA GPU 能获得比 Windows 系统更好的性能，但实际测试结果却往往与预期不符。关键在于了解如何监控、解读和微调操作系统和 GPU 配置，并利用DCGM、dcgm-exporter、gpu-monitoring-tools等专用工具以及 Elastic 等可观测性解决方案。
NVIDIA GPU 在 Linux 上的性能：预期与现实
当拥有RTX 4070 或其他高端显卡的用户考虑转用 Linux 系统时，他们通常会在论坛、Reddit、YouTube 视频以及各种指南上进行研究。多年来，Linux 的性能总是优于 Windows 的说法一直被反复提及，但当我们查看一些严肃的基准测试和对比测试时，就会发现实际情况远比这复杂得多。
在游戏领域，得益于Steam、Proton 和 DXVK 等工具，Linux 的性能有了显著提升，使得大多数 Windows 游戏都能在 Linux 平台上运行。然而，在测试一些对配置要求较高的游戏时，Linux 平台的帧率并不总是能达到 Windows 平台的水平，尤其是在游戏没有原生 Linux 版本而依赖兼容层的情况下。
除了游戏之外，NVIDIA GPU 已成为高性能基础设施的基石：神经网络训练、复杂的物理模拟、渲染以及海量数据中心工作负载。在这种情况下，监控 Linux 内存使用情况并最大限度地发挥 NVIDIA GPU 的性能至关重要，而一个优秀的监控系统正是在此发挥关键作用。
需要注意的是，在 Linux 系统下，性能并非完全取决于 GPU 本身，而是取决于NVIDIA 的专有驱动程序、内核、所选发行版以及显卡的功耗和时钟设置等因素的综合作用。如果这些因素中的任何一个出现偏差，即使使用性能非常强大的硬件，基准测试结果也可能令人失望。
为什么GPU监控在Linux中如此重要？
NVIDIA GPU不再仅仅是“游戏显卡”；它们已成为数据中心、公有云和计算密集型环境的核心组件。在许多部署中，大部分计算能力都来自GPU而非CPU，因此忽视其性能指标对于企业和高级用户来说都是一种无法承受的奢侈。
在这种情况下，仅仅知道总内存容量或安装了哪种型号的GPU是不够的。必须能够实时查看内存使用情况、GPU负载、温度、功耗、时钟频率以及其他内部计数器，这些指标可以提供有关瓶颈或稳定性问题的线索。
此外，Linux 是计算集群、高性能计算 (HPC) 和云 AI 平台的主流操作系统，因此整个监控基础设施通常都围绕它构建。NVIDIA 提供自己的指标公开堆栈，而 Elastic Observability 等解决方案则能够以高度灵活的方式集中管理这些数据、实现数据可视化并生成智能警报。
如果您在Google Cloud、AWS 或 Genesis Cloud等提供商处使用 NVIDIA GPU ，监控不仅可以帮助您检测错误，还可以帮助您验证您在云中付费购买的资源是否得到有效利用，从而避免因利用率不足或配置错误的实例而产生的不必要成本。
另一个关键点是，与 CPU 指标不同，许多 GPU 指标并未很好地集成到标准 Linux 工具中。因此，像NVIDIA 数据中心 GPU 管理器 (DCGM)这样的组件以及与现代可观测性系统集成的专用指标导出器就显得尤为重要。
基本依赖项：NVIDIA 驱动程序、DCGM 和监控工具
要在 NVIDIA 显卡上获得优化的 Linux 内存统计信息，第一步是搭建一个配置完善的环境：正确的驱动程序、GPU 工具以及用于收集和可视化数据的可观测性解决方案。如果系统无法持续显示指标，那么再漂亮的图表也毫无意义。
在数据中心环境中，NVIDIA 提供数据中心 GPU 管理器 (DCGM)，它为收集各种指标奠定了基础，这些指标涵盖内存使用情况、温度以及详细的内部性能信息。对于 Ubuntu 18.04 等主流发行版及其他兼容版本，DCGM 的安装通常依赖于软件包。
在按照 NVIDIA 的说明进行设置过程中，务必注意一些细节，例如参数设置。 在 CUDA 存储库中对于典型的 64 位系统，该命令的结果为： uname -a 这表明建筑是 x86_64因此，添加到软件包系统中的行必须正确使用该值。
将 CUDA 软件仓库添加到基于 Debian/Ubuntu 的发行版的典型示例如下：
echo "deb http://developer.download.nvidia.com/compute/cuda/repos/$distribution/x86_64 /" | sudo tee /etc/apt/sources.list.d/cuda.list
此外，建议检查文档中是否有任何信息。 官方命令中的印刷错误例如，在定义变量时使用额外的 > 符号 $distribution 在导入 GPG 密钥的那一行，必须先进行更正才能运行：
sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/$distribution/x86_64/7fa2af80.pub
安装驱动程序和 DCGM 后，我们可以使用标准的nvidia-smi工具检查 GPU 的基本状态，该工具会显示显卡的型号、总内存和已用内存、温度以及当前正在使用该显卡的进程。
安装 gpu-monitoring-tools 和 dcgm-exporter
为了将 Linux 内存和 NVIDIA GPU 统计信息与 Prometheus 或 Elastic 等外部系统集成，NVIDIA 提供了gpu-monitoring-tools，其中包含 dcgm-exporter 组件。这些工具以 Go 源代码的形式分发，因此您需要在系统上安装并正确配置 Go 。
在典型情况下，Go 会被下载并安装到…… /usr/local解压 tar.gz 文件，并将 Go 二进制文件添加到 PATH 环境变量中。然后，克隆官方仓库：
cd /tmp
git clone https://github.com/NVIDIA/gpu-monitoring-tools.git
cd gpu-monitoring-tools/
sudo env "PATH=$PATH:/usr/local/go/bin" make install
该软件包的关键组件是 dcgm-出口商该组件以 Prometheus 可以理解的格式公开 DCGM 指标。启动时，它会启动一个 HTTP 服务器，默认情况下，该服务器监听本地地址，例如： localhost:9090 并提供所有可用的指标。
要显示的统计信息配置在文件/etc/dcgm-exporter/default-counters.csv中定义，该文件包含数十个预定义的计数器。这些计数器包括与GPU 内存、温度、功耗和各种内部性能指标相关的指标。如需更精细的控制，请参阅 DCGM 库 API 文档，其中详细列出了可以启用的所有指标。
使用类似这样的命令启动 dcgm-exporter 时：
dcgm-exporter --address localhost:9090
您会看到初始化消息，表明 DCGM 已成功启动。通常会收到关于某些模块未加载的警告，例如 DCP 指标，在这种情况下，这些警告可能与 DCGM 的启动有关。 可以忽略不计，不会造成太大问题。 如果它们没有被使用。
使用 Metricbeat 与 Elastic Observability 集成
一旦通过 dcgm-exporter 公开了 NVIDIA GPU 指标，下一步合乎逻辑的做法就是将这些数据发送到可观测性平台。Elastic Observability 是一个强大的选择，它利用 Metricbeat 等组件来收集指标，并将其集中存储在 Elastic Cloud 部署或自管理堆栈中。
为此，首先需要安装它。 Linux 系统上的 Metricbeat 在 dcgm-exporter 运行所在的目录下，下载与最新版本对应的 .deb 软件包，并使用以下命令进行安装： dpkg -i 主文件已配置完毕。 /etc/metricbeat/metricbeat.yml 这样它就能使用这些参数指向 Elastic Cloud 部署。 cloud.id y cloud.auth.
的价值 cloud.id 它通常采用编码形式，用于标识区域和 Elastic 部署，而 cloud.auth 将用户名和密码组合在一起，例如：
cloud.id: "staging:dXMtY2VudHJhbDEuZ2NwLmNsb3VkLmVzLmlvJDM4ODZkYmUwMWNjODQ2NDM4YjRlNzg5OWEyZDAwNGM5JDBiMTc0YzYyMTVlYTQwYWQ5M2NmMGY4MjVhNzJmOGRk"
cloud.auth: "elastic:J7KYiDku2wP7DFr62zV4zL4y"
（显然，在实际环境中，将使用用户自己的安全凭证）。
Metricbeat 的输入是模块化的，在这种情况下，我们需要启用 普罗米修斯模块因为 dcgm-exporter 以该格式发布其指标。激活方式如下：
sudo metricbeat modules enable prometheus
在正式投入使用之前，建议先运行一些配置测试，以确保 Metricbeat 配置正确，并且可以连接到 Elastic Cloud 和 Prometheus 端点。可以使用以下命令完成此操作：
sudo metricbeat test config
sudo metricbeat test output
sudo metricbeat modules list
如果这些测试失败，建议查阅相关文档。 Metricbeat故障排除因为错误通常与凭据错误、端点无法访问或模块未正确启用有关。验证完毕后，您可以运行以下命令：
sudo metricbeat setup
加载默认仪表盘并定义必要的索引映射。
最后，Metricbeat 可以通过以下命令以控制台输出模式或服务模式启动：
sudo metricbeat -e
这将导致 dcgm-exporter 公开的 GPU 指标开始持续发送到 Elastic，在那里它们将被存储并准备好进行分析。
在 Kibana 中可视化内存和 GPU 指标
数据流入 Elastic Observability 后，精彩的部分才真正开始：探索、筛选和交叉引用 GPU 和 CPU 指标，从而真正了解基础设施的运行状况。这主要通过 Kibana 来实现，Kibana 是 Elastic 基于 Web 的分析和可视化界面。
第一步是确保索引模式正确 metricbeat-* 已在该部分正确配置 堆栈管理 > Kibana > 索引模式从那里选择模式，然后单击“刷新字段列表”，以便 Kibana 可以检测到与 GPU 指标相关的新字段。
由 Prometheus 模块收集的 dcgm-exporter 指标通常以prometheus.metrics.DCGM_为前缀。这些字段包括内存使用情况、可用内存、GPU 使用率、温度、功耗和其他相关指标的统计信息。
现在有了这些字段， Kibana 的 Discover视图可以用于执行即席搜索，并按主机、GPU 名称或时间范围进行筛选。此外，还可以在仪表板部分构建可视化图表，例如，显示 GPU 内存使用率在一天中的变化情况，或在同一张图表中比较不同的实例。
其中最实用的视图之一是指标浏览器，它允许您在同一屏幕上比较CPU 和 GPU 的性能。这有助于发现一些模式，例如 GPU 满负荷运转而 CPU 利用率不足，或者反之亦然，这表明可能存在工作负载平衡问题。
此外，库存视图可帮助您精确定位大型部署中的关键 GPU 使用点，识别哪些节点已达到性能极限、哪些节点处于空闲状态以及瓶颈集中在哪里。您还可以据此定义警报，例如，当 GPU 内存使用量在特定时间段内超过某个阈值时触发警报。
根据NVIDIA提供的关键监控参数
在Linux系统上优化NVIDIA GPU环境时，并非所有指标都同等重要。根据制造商的建议，有一些关键参数需要持续监控，以防止故障发生、检测性能下降并优化功耗。
GPU温度是最明显的指标之一。持续高于安全范围的温度可能表明散热存在问题，例如风扇脏污、机箱内部空气流通不畅，甚至可能是散热设计不足以应对系统负载。
另一个关键指标是GPU功耗。如果显卡在相同工作负载下功耗高于正常水平，则可能表明硬件出现问题或电源设置过于激进。在大规模环境中，该数据对于控制电力成本和规划基础设施容量也至关重要。
当前的GPU时钟频率也能反映出系统的健康状况。如果在高负载下这些频率仍然低于预期值，则可能是由于功率限制、过热降频或保守的电源设置限制了实际可用性能。
NVIDIA 提供诸如以下工具用于压力测试或验证： dcgmproftester10这些命令允许您模拟高负载的 GPU 环境，并验证各项指标的响应。一个典型的命令是：
dcgmproftester10 --no-dcgm-validation -t 1004 -d 30
该程序会运行一个特定的性能测试 30 秒，不进行某些 DCGM 验证，非常适合检查系统在压力下是否保持稳定。
通过将这些指标与 Elastic 的警报功能相结合，可以自动执行 NVIDIA 提出的建议，在温度超过阈值、内存使用率危险地接近 100% 或功耗与正常基准相比明显失控时触发通知。
在 Linux 系统上优化 NVIDIA GPU 设置
除了被动监控之外，Linux 系统中还可以进行多项调整，以使 NVIDIA GPU 的性能更加稳定，在许多情况下还能获得更优异的性能。其中最相关的方面之一是管理驱动程序中包含的自动加速和动态时钟频率调节功能。
在某些 GPU 实例中，NVIDIA 驱动程序使用自动加速功能，根据负载和温度情况调整 GPU 频率。虽然这在一般环境下很有用，但在需要最高性能和可重复结果的场景中，最好禁用这些功能并将时钟频率手动设置为安全的最大值。
通过禁用自动睿频并设置最高频率，性能在不同运行之间会变得更加稳定和可预测。这在基准测试、硬件验证、数据中心和人工智能平台等领域尤为重要，因为这些应用场景对运行间的性能差异要求极低。
另一个需要关注的点是GPU的电源模式。在Linux系统下，NVIDIA工具允许您调整电源配置文件，从更节能的模式到可提供持续最高性能的模式，应有尽有。选择过于保守的配置文件可能会显著降低游戏帧率或密集型计算任务的性能，即使它能降低功耗。
对于消费级PC，尤其是那些配备现代显卡、专为Linux游戏设计的PC，最好检查一下驱动程序是否为最新版本，并确保持久模式、功耗限制和时钟频率配置文件设置符合预期性能目标。很多跑分不佳的结果仅仅是由于出厂配置优化不足造成的。
Linux 和使用 NVIDIA GPU 的游戏：现状
尽管 Linux 仍然背负着“不适合玩游戏”的恶名，但事实上，只要配备一块好的 NVIDIA GPU 和 Steam 生态系统，完全可以畅玩许多游戏，获得与 Windows 平台非常接近的体验，尤其是在利用现代图形 API 的情况下。
Steam Play 使用Proton 和 DXVK（Wine 的一个特定分支），将 DirectX 调用转换为 Vulkan，从而使大量最初为 Windows 开发的游戏能够在 Vulkan 上运行。虽然性能并非总能达到原生游戏的水平，但帧率损失通常很小，在很多情况下，大多数用户都能接受。
与上一代显卡（从NVIDIA GeForce GTX 980 Ti 到 TITAN RTX）以及 AMD 的 Radeon RX Vega 56 或 Radeon VII 等型号相比，NVIDIA 的高端 Turing 核心 GPU在 Linux 系统下运行4K 分辨率的游戏时表现尤为突出。
以《全面战争：三国》这样的游戏为例，在测试的18款显卡中，如果保持较低的画面细节，许多显卡都能在4K分辨率下达到理想的60帧。但当画面细节提升到中等时，只有像RTX 2080 Ti或TITAN RTX这样性能极其强大的显卡才能在Linux系统下稳定地超过这个帧率。
其他游戏，如《反恐精英：全球攻势》或《DOTA 2》，则表现出更大的容错性：在可用时利用 Vulkan API，几乎所有测试过的显卡都能在 4K 分辨率下流畅运行这些游戏，即使在分析范围内配置较低的硬件上也能获得较高的 FPS 率。
在《杀出重围：人类分裂》或《战锤40K：战争黎明3》这类对图形性能要求极高的游戏中，高端显卡在4K分辨率和高画质设置下的必要性再次凸显。而在《古墓丽影：崛起》或《全面战争传奇：不列颠王座》这类游戏中，如果将画面细节设置为低或中，大多数GPU都能流畅运行4K分辨率，这进一步印证了NVIDIA在这些场景下针对Linux系统的驱动程序和优化方面优于AMD的观点。
这些测试反复表明，AMD 的Linux 游戏驱动程序仍有改进空间，而 NVIDIA 则提供更成熟的支持和更稳定的更新。对于那些希望在 Linux 系统上获得最佳高分辨率游戏性能的用户来说，这仍然是选择 GPU 时的一个关键因素。
综合了解 Linux 内存统计信息和 NVIDIA GPU 指标的行为方式，再加上良好的驱动程序配置和监控工具，无论是在游戏 PC、AI 服务器，还是在拥有数十个节点满负荷运行的数据中心，都能让您充分发挥显卡的性能。
很显然，在 Linux 系统中对内存、性能和 NVIDIA GPU 状态进行详细控制已不再是可选项，而是生产环境和高要求用户的关键组件：一个好的驱动程序堆栈和 DCGM、一个使用 dcgm-exporter 的指标导出层、使用 Metricbeat 进行数据收集、在 Kibana 中进行可视化，再加上对 GPU 功率和时钟速度的微调，才是真正区分一个仅仅是运行的系统和一个能够充分利用每一瓦功率和每一 GB 可用内存的系统的关键所在。