抽象。

分析来自 GPU 分析器的大规模性能日志通常需要数 TB 的内存和数小时的运行时间，即使是基本摘要也是如此。这些限制会阻止及时洞察，并阻碍将性能分析集成到自动化工作流程中。现有的分析工具通常按顺序处理数据，这使得它们不适合跟踪复杂性和容量不断增长的 HPC 工作流。我们引入了一个分布式数据分析框架，该框架可随数据集大小和计算可用性而扩展。我们的系统没有将数据集视为单个实体，而是将其划分为可独立分析的分片，并在 MPI 等级之间并发处理它们。这种设计减少了每个节点的内存压力，避免了中央瓶颈，并支持对高维跟踪数据的低延迟探索。我们将该框架应用于来自真实 HPC 和 AI 工作负载的端到端 Nsight Compute 跟踪，展示了其诊断性能变化的能力，并揭示了内存传输延迟对 GPU 内核行为的影响。

GPU 具有并行处理能力，是高性能计算 （HPC） 工作负载的关键加速器。对 GPU 驱动的应用程序进行高效分析对于识别性能瓶颈、管理资源和优化 GPU 利用率至关重要。但是，高级分析工具生成的性能日志会迅速增长到 TB，使将整个数据集加载到单节点内存的传统顺序分析方法不堪重负。当前的方法严重依赖增量处理或重复的基于磁盘的作，严重限制了可扩展性和效率。

为了克服这些限制，我们提出了一个专为 GPU 性能日志设计的分布式数据驱动分析框架。我们的解决方案将大型 SQLite3 表划分为较小的分片，跨多个 MPI 等级并发处理。这允许每个节点仅分析一小部分数据，从而显著降低每个节点的内存需求和计算延迟，从而实现对大量 GPU 数据集的可扩展、高效分析。

NVIDIA Nsight 分析（Nsight Systems 和 Nsight Compute）跟踪 CPU-GPU 交互、内核执行、内存传输和硬件使用情况。使用 Gueroudji 等人的数据集，将分析数据组织到 CUPTI 表中（表 1）。（Gueroudji 等人，2024).在数据集中，

（1） ACTIVITY_KIND_KERNEL记录内核启动、时间戳、设备和流 ID 以及资源使用情况;

（2） ACTIVITY_KIND_MEMCPY记录内存传输、时间戳、大小、方向和流 ID;

（3） TARGET_INFO_GPU报告 GPU 属性，例如内存大小、带宽、SM 数量和计算能力。

我们设计了一个两阶段管道，包括 （i） 提取和分片执行跟踪的数据生成阶段，以及 （ii） 整合和分析数据以揭示异常行为的数据聚合阶段。

数据生成我们的管道识别基本的 SQLite3 表并提取内核时间戳以定义数据集边界。我们将整个时间范围均匀划分为N非重叠分片，每个分片按时间戳对内核执行进行分箱。鉴于PMPI 排名，我们选择块分区而不是循环分区，因为数据集是静态的，并且工作负载的可预测性很高。数据块分区将连续的分片分配给每个等级，从而减少查询开销，提高数据局部性，并实现高效的 SQL 查询执行。每个排名都独立处理其分配的分片，并将查询结果保存到名称一致的 parquet 文件中，从而促进无缝的下游聚合。

数据聚合我们通过定义一个全局字典来开始聚合，其中时间戳作为键和固定的用户定义持续时间 （我⁢n⁢t⁢e⁢r⁢v⁢一个⁢l=1⁢s默认情况下）。每个等级都会加载其分配的NPparquet 文件，将样本映射到相应的时间分片。随后P排名以循环方式协作计算统计指标（最小值、最大值、标准偏差），从而均匀平衡工作负载并最大限度地减少争用。这些共享的统计数据有助于识别异常，我们使用四分位距 （IQR） 从中选择前 5 个异常分片（惠利，2014)方法。

为了评估我们的管道，我们使用了德克萨斯州高级计算中心 （TACC） 的 Lonestar6 超级计算机。Lonestar6 超级计算机有 560 个计算节点，每个节点配备两个 AMD EPYC 7763 处理器（总共 128 个内核）和 256 GB DDR4 内存。有 84 个 GPU 节点，每个节点具有相同的 CPU 和 3 个 NVIDIA A100 GPU（每个 40 GB HBM2）

所有等级的 Memory Stall Duration  绘制了所有四个等级的内存停顿持续时间，y 轴上是停顿持续时间，x 轴上是经过的运行时间（以秒为单位）。该图显示了在多个 rank之间同时发生的持续内存停顿，这表明存在同步问题或内存带宽争用。根据目视检查，我们选择 Rank 2 进行详细分析。

内存停顿与内核执行关系 我们从 Rank 2 中分离出前 5% 的最高可变性区间，以分析内存停顿和内核执行之间的关系。该图证实了 Device-to-Host 和 Host-to-Device 传输占主导地位，这表明由于批处理效率低下导致了频繁的乒乓模式。相比之下，稀疏的设备到设备传输表明 GPU 内部作不频繁，突出了通过共享内存重用或平铺进行优化的机会。

开销 比较了不同 MPI 配置中两个阶段的持续时间：数据生成和数据聚合。我们发现，随着 MPI 秩数量的增加，数据生成和聚合时间都会减少。这证明我们的管道是 可扩展以处理大量数据。

我们开发了一个分布式框架，通过将 SQLite3 表分区为分片来并发分析 GPU 性能日志，从而减少内存使用和延迟。分析了 93M 个样本，我们确定了导致内存停顿的时间戳和实体。未来的工作将侧重于通过消除中间 I/O 瓶颈来提高可扩展性。