抽象。

分析來自 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 瓶頸來提高可擴展性。