调试性能瓶颈

  • 5 分钟

若要在大量 VM（超过 16 个）上运行高性能计算 (HPC) 应用程序，那么最好在较少的 VM 上开始运行较小的问题。 该测试验证 HPC 应用程序是否按预期运行。

不要认为仅仅因为你运行的是 HPC 并行应用程序，它的实际时间（已用实际时间）就会随着你在更多 VM（有更多的并行进程）上运行它而持续递减。 事实上，当你尝试在其他 VM 上运行许多紧密耦合 HPC 应用程序时，它们的实际时间可能会较长。

实际时间较长的原因可能有多种。 例如：

  • 你可以低效地实现并行算法。

  • 问题规模（即模型大小或自由度数 (NDOF)）不够大。 当应用程序在更多的并行进程上运行时，每个进程的计算量过小。 因此，并行进程之间的通信时间会支配总实际时间。 通讯时间增加便会增加总实际时间。

运行所需的问题规模时，了解 HPC 应用程序的缩放情况很重要。 然后，可以从性能和成本的角度确定可接受的并行效率。

下面的并行加速公式可测量当你添加更多的并行进程时并行应用程序性能的改善情况：

$${\text{并行加速}} = {\dfrac{\text{实际时间（1 个进程）}}{\text{实际时间（n 个进程）}}}$$

下面的并行效率公式说明了在添加更多进程来提高并行应用程序性能时对计算资源的使用效率如何：

$${\text{并行效率}} = {\dfrac{\text{并行加速}}{\text{N 个进程}}}$$

如果你不确定紧密耦合 HPC 应用程序的并行缩放性能，请进行缩放研究。 也就是说，在第 1 个、第 2 个、第 4 个、第 8 个、第 16 个等并行进程上运行应用程序。 计算并行加速和并行效率，然后根据这些结果确定要使用多少并行进程。

在运行作业之前，请考虑禁用可能会影响并行缩放的任何不必要的服务（如 Azure Linux 代理）。 作业完成后，可以重新启用这些服务。 如果你正在使用所有可用的核心并扩展到大量 VM，那么这个建议尤其有效。

若要停止 Azure Linux 代理，请使用以下命令：

sudo system stop waagent.service

性能检查

以下信息提供了一些基本的检查，以帮助发现潜在的性能问题。

检查每个 VM 上运行的进程数和线程数是否正确

若要确定你在每个虚拟机 (VM) 上所使用进程和线程的数量是否正确，可使用 uptime 等工具获取每个 VM 的系统负载平均值。 该数量应与每个虚拟机上所需的进程和线程总数大致相当。 如果记录的负载平均值小于或大于预期的进程和线程总数，则表明存在必须要修复的问题。

应仔细检查消息传递接口 (MPI) 参数，以及如何指定并行线程数。 例如，应检查应用程序的命令行参数或检查环境变量（如 OMP_NUM_THREADS）的值。

检查进程和线程是否均匀分布在所有 Numa 节点域中

如果使用的是 top 或 htop 工具，则可以通过指定 2 作为命令行参数来选择非一致性内存访问 (NUMA)节点域视图。 （例如：在 HB120_v2 上，使用此视图应该可以显示 30 个 Numa 节点域。）

用户利用率应均匀分布在所有 NUMA 域中。 如果不是这样，请检查 MPI 命令行参数和环境变量。

下图展示了 Linux top 工具在 NUMA 视图中的输出。 在此示例中，每个 NUMA 的利用率为 50%。

该屏幕截图显示了 Linux top 命令的 NUMA 输出。

检查进程和线程运行状态

若要检查进程和线程的运行状态，应使用 top 工具。 理想情况下，所有进程和线程都应处于“正在运行(R)”状态。

如果部分或所有进程和线程处于“不间断睡眠(D)”状态或“睡眠(S)”状态，请调查情况来查明原因。 根据应用程序算法的设计方式，进程和线程处于睡眠状态可能是正常的预期行为。 但是，这可能指示资源约束，如使用的存储解决方案的 I/O 性能不足。

下面的公式说明了并行应用程序在等待某些系统资源（例如 I/O）时的运行效率以及达到何种程度：

$${\text{应用程序等待时间}} = {\text{实际时间}} - \left( {\dfrac{\text{所有并行进程的总 CPU 时间}}{\text{并行进程数}}} \right)$$

检查应用程序是否受 I/O 约束

如果进程和线程在很长时间内处于“不间断睡眠(D)”或“睡眠(S)”状态，则可能表明存在需要调查的 I/O 瓶颈。 某些 HPC 应用程序在其输出中会提供性能分析。 这些配置文件显示执行 I/O 所用时间的百分比和读/写 I/O 率，这些也可能指向 I/O 瓶颈。

如果不确定 I/O 的情况如何，可以使用 iostat 等工具来帮助判断。 若要验证是否存在 I/O 问题，请将存储解决方案更改为你所知的比你一直使用的解决方案更快的解决方案。 然后重新运行 HPC 应用程序。 例如，可以使用快速的本地 NVMe SSD 或 RAM 磁盘。

进行此更改后，请向自己提出以下问题：I/O 时间是否有任何改进？ 总实际时间是否有所改善？ 如果可以，限制度可以有多高？

检查应用程序是否受网络约束

确定应用程序执行进程通信（通常是 MPI 通信）所用的总实际时间的百分比。

如果应用程序受网络约束，请验证是否在运行 HPC 应用程序时使用了 InfiniBand 网络。 如果有混合并行版本可用，请确定它是否缩短网络通信时间。

如果你有权访问源代码，请检查是否有更高效的方法来实现通信。 例如，使用集体操作，而不是点对点，或尝试使用异步通信，而不是同步通信。