发行说明

发行说明和已知问题。

新增功能

Nsight Systems 2025.1 亮点:

支持 CUDA 12.8
保留最后 N 秒 CLI 选项 - nsys stop 现在接受 --keep=N 选项，以便在尝试记录不可预测的事件时保留最相关的数据。
每个范围（NVTX 或 CUDA 内核）的 GPU 指标样本摘要的配方
生成包含 ETW 数据的 Windows 报告时，减少了内存开销
Windows 图形资源跟踪器跟踪资源优先级更改
Pytorch 性能分析
用于启用 pytorch autograd NVTX 性能标记的新命令行选项
跟踪重要的 pytorch 函数
支持用 Python 3.12 编写的脚本和配方
Linux 自解压 .run 安装程序现已可用于 Arm64 SBSA 系统。
预览：多通道脚本，用于运行 Arm 顶向下分析中涉及的所有 CPU 事件

已知问题

一般问题

Nsight Systems 使用的默认时间转换在 WSL 上不可靠，我们需要回退到更安全但精度较低的时间系统。为此，请将配置文件选项 CuptiUseRawGpuTimestamps 设置为 false。可以使用以下命令设置配置文件选项
```
mkdir -p "$(dirname "$(nsys -z)")"
echo 'CuptiUseRawGpuTimestamps=false' >> "$(nsys -z)"
```
在未来的版本中正确处理时间戳转换之前，这是必需的。
Nsight Systems 版本，从 2024.2 开始，不再支持 Power PC，我们建议您使用旧版本，可从 https://developer.nvidia.com/gameworksdownload 下载。
Nsight Systems 版本，从 2024.4 开始，不再支持 11.4 之前的 cuBLAS 版本。如果您无法更新 cuBLAS，我们建议您使用旧版本，可从 https://developer.nvidia.com/gameworksdownload 下载。
当前版本的 Nsight Systems CLI 不支持使用长度超过 127 个字符的名称命名会话。使用名称超过 111 个字符的可执行文件进行性能分析也不受 nsys profile 命令的支持。这些限制将在未来版本的 CLI 中删除。
Nsight Systems 2020.4 引入了在没有完整采样的情况下收集线程调度信息的功能。虽然这允许以较低的成本获取系统信息，但它确实增加了开销。要关闭线程调度信息收集，请将 --cpuctxsw=none 添加到命令行，或在 GUI 中关闭。
目前不正式支持超过 5 分钟的性能分析。在高活动应用程序、高性能机器上进行长时间分析，可能会创建大型结果文件，这些文件可能需要很长时间才能加载、耗尽内存或锁定系统。如果您的应用程序很复杂，我们建议从不超过 5 分钟的短时间性能分析会话开始进行初始分析。如果您的应用程序具有自然的重复模式（通常称为帧或迭代），您通常只需要几个这样的模式。建议的限制将在未来的版本中增加。
使用 x86_64 Linux 目标时，不支持从 GUI 附加或重新附加到进程。可以通过使用交互式 CLI 启动进程，然后在多个点启动和停止分析来获得等效的结果。
为了减少开销，Nsight Systems 在跟踪 API 时，会跟踪可能影响性能的 API 调用的子集，而不是所有可能的调用。目前，使用 CLI 时无法更改正在跟踪的子集。有关默认跟踪的调用列表，请参阅本文档中相应库的部分。CLI 限制将在未来版本的产品中删除。

工具用于记录收集期间的跟踪事件的默认大小存在上限。如果您看到以下诊断错误，则 Nsight Systems 已达到上限。

Reached the size limit on recording trace events for this process.
       Try reducing the profiling duration or reduce the number of features
       traced.

当分析使用 CUPTI 的框架或应用程序时，例如某些版本的 TensorFlow(tm)，由于 CUPTI 的限制，Nsight Systems 将无法跟踪 CUDA 使用情况。这些限制将在未来版本的 CUPTI 中得到纠正。如果需要 CUDA 跟踪，请考虑关闭应用程序对 CUPTI 的使用。
不支持跟踪使用非线程安全内存分配器的应用程序。
不支持在预加载 glibc 符号的应用程序中跟踪 OS 运行时库，并且可能导致未定义的行为。
Nsight Systems 无法分析通过虚拟窗口管理器（如 GNU Screen）启动的应用程序。
将 Nsight Systems MPI 跟踪功能与 Darshan 运行时模块一起使用可能会导致段错误。要解决此问题，请卸载该模块。

module unload darshan-runtime

使用 MPI_Status 作为参数分析 MPI Fortran API（例如 MPI_Recv、MPI_Test[all]、MPI_Wait[all]）可能会导致 MPICH 3.0.x 版本的内存损坏。原因是 MPICH 3.0.x 中的 MPI_Status 结构具有与其他 MPICH 版本（已测试 2.1.x 和 >=3.1.x）以及我们用于编译 Nsight Systems MPI 拦截库的版本 (3.3.2) 不同的内存布局。
如果目标文件系统不支持文件锁定，则使用 nsys export 导出到 SQLite 数据库将失败。错误消息将提及

std::exception::what: database is locked

在某些使用 VNC 的 Linux 系统上，某些小部件可能无法正确呈现，或者 Nsight Systems 在打开“分析摘要”或“诊断摘要”页面时可能会崩溃。在这种情况下，请尝试强制使用特定的软件渲染器：GALLIUM_DRIVER=llvmpipe nsys-ui
由于 Open MPI 4.0.1 中的已知错误，目标应用程序在被 Nsight Systems 分析时可能会在执行结束时崩溃。要避免此问题，请使用不同的 Open MPI 版本，或将 --mca btl ^vader 选项添加到 mpirun 命令行。
Python 中的 multiprocessing 模块通常被客户用于创建新进程。在 Linux 上，该模块默认使用“fork”模式，在该模式下，它会 fork 新进程，但不调用 exec。根据 POSIX 标准，不带 exec 的 fork 会导致未定义的行为，并且像 Nsight Systems 这样依赖注入的工具只允许在此类进程中进行异步信号安全调用。这使得像 Nsight Systems 这样的工具很难收集性能分析信息。请参阅 https://docs.pythonlang.cn/3/library/multiprocessing.html#contexts-and-start-methods

使用 multiprocessing 模块中的 set_start_method 将启动方法更改为“spawn”，这更安全，并允许像 Nsight Systems 这样的工具收集数据。请参阅上面链接中给出的代码示例。

用户需要确保进程正常退出（例如，在 multiprocessing 模块的对象中使用 close 和 join 方法）。否则，Nsight Systems 无法正确刷新缓冲区，您可能会丢失跟踪。
当 CLI 序列 launch、start、stop 用于分析进程树时，LinuxPerf 会执行深度优先搜索 (DFS)，以在对 OS 进行编程以收集数据之前找到进程树启动的所有线程。如果在 DFS 期间，进程树创建了一个或多个线程，则这些线程可能找不到，并且 LinuxPerf 将不会收集它们的数据。

请注意，一旦通过 perf_event_open 对线程进行编程，由于设置了 perf_event_open 继承位，该线程生成的任何后续子进程或线程都将被跟踪。

没有其他 CLI 命令序列会受到此可能问题的影响。此外，如果使用系统范围模式，则不存在该问题。

vGPU 问题

在 vGPU 上运行 Nsight Systems 时，您应始终使用 profiler grant。有关为 NVIDIA vGPU 启用 NVIDIA CUDA Toolkit profiler 的详细信息，请参阅虚拟 GPU 软件文档。如果没有 grant，意外的迁移可能会导致正在运行的会话崩溃、报告错误并中止。它也可能会静默生成损坏的报告，这些报告可能无法加载或显示不准确的数据，而不会发出警告。
从 vGPU 13.0 开始，即使在 vGPU 上，设备级别指标收集也向最终用户公开。设备级别指标将提供有关 GPU 上执行的所有工作的信息。该工作可能与同一 VM 或同一物理 GPU 上运行的其他 VM 相关。
截至 CUDA 11.4 和 R470 TRD1 驱动程序版本，vGPU 环境中支持 Nsight Systems，这需要 vGPU 许可证。如果 20 分钟后未获得许可证，该工具仍可工作，但报告的 GPU 性能指标数据将不准确。这是因为 vGPU 环境中的一项功能会降低性能，但会保留 Grid 许可用户指南中指定的功能。

Docker 问题

在 Docker 中，当系统主机使用的内核版本早于 v4.3 时，除非主机和 Docker 都运行使用内核版本 3.10.1-693 或更高版本的 RHEL 或 CentOS 操作系统，否则 Nsight Systems 无法收集采样数据。未来版本将提供用户覆盖此设置的功能。
当在正在运行的容器上调用 docker exec 并且从该 shell 内调用的命令保持 stdout 打开时，exec shell 会挂起，直到命令退出。您可以通过使用 docker exec --tty 运行来避免此问题。请参阅以下错误报告：
https://github.com/moby/moby/issues/33039
https://github.com/drud/ddev/issues/732

CUDA 跟踪问题

cudaMemPrefetchAsync() API 允许用户指定流以将内存预取操作排队。但是，Nsight Systems 无法从 UVM 后端获取 UVM 页面迁移的流信息。因此，Nsight Systems 无法正确显示与 cudaMemPrefetchAsync() API 调用关联的流信息。这将在未来版本中修复。
当使用 CUDA Toolkit 10.X 时，跟踪 DtoD 内存复制操作可能会导致崩溃。要避免此问题，请将 CUDA Toolkit 更新到 11.X 或最新版本。
当在 Volta 设备或更高版本的设备上的目标应用程序中找到 CDP（CUDA 动态并行）内核时，Nsight Systems 将不会跟踪内核。
在 Tegra 平台上，CUDA 跟踪需要 root 权限。使用项目设置中的 以 root 身份启动 复选框，使分析的应用程序以 root 身份运行。
如果目标应用程序使用来自多个线程的多个流，则 CUDA 事件缓冲区可能无法正确释放。在这种情况下，您将看到以下诊断错误
```
Couldn't allocate CUPTI bufer x times. Some CUPTI events may
       be missing.
```
请联系 Nsight Systems 团队。
在本版本的 Nsight Systems 中，如果您使用交互式 CLI 在应用程序内部启动和停止性能分析，则 CUDA 内存分配图的生成仅保证在第一个性能分析范围内是正确的。此限制将在未来版本的产品中删除。
CUDA GPU 跟踪收集需要一部分 GPU 内存。如果您的应用程序使用了所有可用的 GPU 内存，则 CUDA 跟踪可能无法工作或可能破坏您的应用程序。例如，如果 GPU 内存分配失败，cuDNN 应用程序可能会因 CUDNN_STATUS_INTERNAL_ERROR 错误而崩溃。
对于早于 4.4 的旧 Linux 内核，当分析在性能分析会话中间退出的非常短期的应用程序（约 1 秒）时，Nsight Systems 可能不会在时间轴上显示 CUDA 事件。
当应用程序中执行超过 64k 个串行 CUDA 内核和内存复制时，您可能会在性能分析期间遇到以下异常
```
InvalidArgumentException: "Wrong event order detected"
```
请至少升级到 CUDA 9.2 驱动程序以避免此问题。如果您无法升级，则可以使用 CLI 进行部分分析，可能会丢失大部分 CUDA 事件。
在 Vibrante 上，当运行具有多个目标的性能分析会话时，这些目标是在 NAT 后面的 CCC 配置中的来宾 VM，您可能会在性能分析期间遇到以下文本的错误
```
Failed to sync time on device.
```
请编辑组连接设置，选中那里的 同一 SoC 上的目标 复选框，然后重试。
当使用 CUDA Tool Kit 11.1 附带的 455 驱动程序，并使用 Nsight Systems 跟踪 CUDA 时，您可能会在应用程序退出时遇到崩溃。要避免此问题，请在应用程序退出之前结束性能分析会话或更新您的驱动程序。

多报告分析问题

请注意，在您的工作站上设置 Dask 分析需要在系统上进行一些额外的工作。对于小型数据输入，在没有 Dask 的情况下运行配方可能会更快。