Dynolog：开源系统可观测性

鉴于高级人工智能模型的规模和复杂性，我们有必要将人工智能训练分布到多个服务器节点。各节点还可利用 GPU 等硬件加速器提高性能。举例而言，运行这些分布式人工智能模型的硬件包括 Meta AI 研究超级集群、AWS Sagemaker、Azure ML 等等。不管这些集群的计算能力多么强大，都需要精心优化人工智能应用程序才能充分利用基础硬件。因此，出色的性能监控和分析工具不可或缺。

虽然目前已有现成的监控 (Opentelemetry) 及分析 CPU 和 GPU 的解决方案，但将这些数据整合到一起以全面了解系统极具挑战性。例如，我们需要了解某一资源（如通信结构）的低效率是否会降低总体计算速度。此外，这些解决方案还需要在不降低性能的情况下，对实际应用程序产生积极影响。

为应对这些挑战，我们将开放 Dynolog（适用于 CPU-GPU 异构系统的轻量型监控守护程序）的源代码。Dynolog 支持始终开启性能监控以及深入分析模式。要激活深入分析模式，可对守护程序进行远程过程调用。为支持人工智能训练应用程序，Dynolog 还可与 PyTorch Profiler 和 Kineto CUDA 分析资源库集成。请先了解本帖子中的某些 Dynolog 功能，然后再探索 GitHub 存储库以访问可用资源。

主要功能

部分主要功能如下，本帖子稍后将介绍这些功能的更多详情：

• Dynolog 可与 PyTorch Profiler 无缝集成，并可提供按需远程追踪功能。用户可发出一个 CLI 命令 (dyno) 以同时追踪数百个 GPU 并检查收集的追踪数据（PyTorch v1.13 和更高版本可提供此功能）。

• 此程序可使用 DCGM 对 NVIDIA GPU 进行 GPU 性能监控。

• 此程序还可管理 Intel 和 AMDCPU 的 CPU 缓存、TLB、内存控制器的相关微架构特定性能事件计数器。此外，此程序还可检测 Linux 内核中的遥测数据，包括 CPU、网络和 IO 资源的使用情况。

• 我们在功能方面不断推陈出新，包括对 Intel 处理器追踪的支持、在 LLVM 方面的贡献，以及内存延迟和带宽监控。

鉴于用户在云端环境中主要使用 Linux 平台，我们将着重介绍此平台的相关内容。以下部分将深入介绍 Dynolog 的持续监控和分析模式。

持续监控

持续监控指标可帮助精准确定性能或可靠性瓶颈，以及回归分析的出现时间或位置。此时，用户可深入分析并了解根本原因。Dynolog 可利用硬件和 Linux 内核的各种接口检测这些指标。

CPU/存储空间/网络：首先，我们可通过 Linux 内核检测基本计数器，大致了解 CPU、磁盘和网络使用率。为此，我们需要读取 Linux procfs API。

CPU 性能监控单元计数器：使用 CPU 的时段可能无法全面反映性能瓶颈（如本博客所述）。例如，CPU 可能在等待内存提供数据，但仍显示为使用状态。由于现代 CPU 处理器存在多个争用点，我们需要深入分析其微架构。大多数现代 CPU 的性能监控单元 (PMU) 可使用 Linux perf_event API 进行编程。我们可集成读取这些 PMU 计数器的功能（例如，其中包括 L1/L2 缓存缺失量、TLB 缺失量以及内存读写量）。我们的代码目前支持 Intel 和 AMD CPU，但未来将扩大范围，支持更多 CPU 架构。

GPU：在使用 GPU 的异构系统中，性能分析的情况会稍显复杂。GPU 可能因 CPU 到 GPU 或 GPU 到 GPU 内存传输缓慢而未得到充分利用。我们也可能未按高级使用说明提供更高的数量级性能。为自查 GPU 不同资源/接口的使用率，我们集成了 NVIDIA 数据中心 GPU 管理器资源库。这些指标可帮助人工智能开发者迅速确定瓶颈，比如计算（SM 占用率）、内存带宽（HBM 带宽）、NVLink、PCIE 带宽等。

说明：此图片展示 GPU 指标示例：sm_active_ratio 指标。NVIDIA GPU 包含约 100 个称为流式多处理器 (SM) 的单元。SM 活动率展示了 GPU 中所有 SM 的使用率均值。在此示例中，我们只使用了 12.8％ 的 GPU 可用计算资源，这表明我们还有改进空间。如需详细了解支持的指标，请点击此处。

按需分析人工智能应用程序

调试分布式人工智能应用程序的性能极具挑战性，因为调试人员需要了解多个 CPU 和 GPU 彼此互动的方式。任何等待或延迟均可导致性能下降，训练时间增加。开发者可使用 PyTorch Profiler API，以编程方式检查其 PyTorch 训练应用程序。此分析器可提供大量有关 CPU 和 GPU 互动方式的信息。但是，用户需要编辑其 python 代码才能获取此数据，并且可能要重新开展工作。

目前，没有什么好工具可触发按需分析 CPU-GPU 任务（即在不更改代码的情况下随时对其进行分析）。但对于 CPU，其按需分析器工具已经存在很多年了，比如 Linux perf。

Dynolog 通过集成 PyTorch GPU 分析资源库 Kineto 填补了此 CPU-GPU 分析技术空白。实际上，Dynolog 将提供服务，帮助用户 将其人工智能应用程序设置为分析模式。流程如下图所示：

1. 用户可使用 Dynolog 命令行界面请求追踪 Pytorch GPU。此请求将通过网络发送到 Dynolog 守护程序。
2. Dynolog 守护程序和 PyTorch Kineto 资源库采用 Linux 进程间通信机制（称为 ipcfabric）在本地相互通信，此分布机制也是 Dynolog 的一部分。
3. 使用第 1 步中的请求配置按需分析应用程序。PyTorch 随后会将追踪数据保存到网络驱动器（例如 Amazon S3）的指定位置。

说明：图表展示了上述分析模式的工序流程：1) 用户通过 dyno 命令行工具触发追踪，系统通过网络将此请求发送到 Dynolog 守护程序，2) Dynolog 将分析请求参数转发到 Kineto 分析资源库，3) Kineto 使用 CUDA 分析工具 (libcupti) 获取时间线追踪数据，4) 将追踪数据保存到共享驱动器或其他远程对象存储空间。

我们将一同提供一个名为 unitrace.py 的脚本，需与 SLURM（安排并运行 HPC 集群作业的热门工具）搭配使用。此脚本可自动向运行分布式训练工作的所有计算节点发出请求。我们团队很乐意为其他作业调度程序和环境提供支持。请参阅 GPU 分析支持，了解详情。

记录数据

Dynolog 采用通用 Logger 类，此类支持自定义，可将数据发布到各种存储空间。例如，用例之一即是创建特定记录器，以便向存储空间提交时间序列数据。Dynolog 团队很乐意为各类型数据存储和通用数据存储提供支持：请联系我们。

结论

Dynolog 为系统和应用程序监控提供了全面的处理方法。我们在本博文中探讨过，使用此程序可构建成熟的工作流程，以便使用持续监控指标以及按需分析。两个关键要点包括：

• Dynolog 可检测采用 CPU 和 GPU 的异构系统的性能监控指标。

• 我们与 PyTorch Profiler 团队密切合作，提供按需追踪功能，支持 PyTorch 应用程序在任何平台（AWS、Azure、私有云）上收集相关数据。

目前大热的用例是实现包括人工智能研究超级集群在内的 Meta AI 研究集群的可观测性。我们将尽力确保这些工具无缝集成，以帮助工程师和研究员更好地优化其人工智能模型。

联系我们

如有疑问或问题，请随时联系 Dynolog 团队。我们也很乐意与您一起研究和改进 Dynolog。

附加说明

使用 Rust

我们已使用 Rust 开发 Dynolog 客户端命令行工具。Dynolog 团队热衷于使用 Rust 编写新组件，并通过外部函数接口集成以 C++ 编写的现有模块。将 Rust 用于编写客户端等小模块，为以后使用 Rust 编程语言进行开发奠定了基础。Dynolog 服务器采用复杂的多线程进程。采用 Rust 提供的编译时间正确性检查功能，可增强遥测服务的可靠性。

开源优先

在开发 Dynolog 的过程中，我们将坚持开源优先原则，以确保优先向社群提供各项功能。这样，有助于使该项目与 Pytorch Kineto 分析器、Param 基准和 LLVM（适用于基于 Intel 处理器追踪的调试）等配套开源项目保持同步。