使用并行程序在HPC系统上进行计算总需要面临一个问题： 选多大规模的节点来进行并行计算好？

这个问题很难，因为涉及的因素非常多，但其实也很容易，只需要几个简单的测试即可，但在实际的客户服务过程中，我发现很多用户都没有意识到，由于计算规模选择不当带来的时间和金钱上的浪费。另外，这个测试过程也是发现程序性能瓶颈的过程，能够为如何优化程序的性能提供指导。

测试过程可以简单的分为这几个过程 ：

• 准备测试算例

• 进行测试

• 结果分析

准备测试算例

这是很多人忽略掉得一点儿，而直接用实际的算例就开始测试，结果实际浪费了大量的时间和机时。

实际的算例的好处是测试结果直接反应了需要花费的时间。但耗时太长并非一个好的测试，因而更好的做法是保持算例的问题复杂度的同时减少需要计算的时间。幸好大部分的科学计算都是迭代计算，最简单的办法是减少迭代次数。我们并不需要跑一个完整的算例来选择最优的计算规模。在此推荐对于大多数程序的测试迭代步选择5~10步。

为了给分析提供更多的数据，我们最好选择让程序提供详细的LOG 文件，能知道每个迭代步的耗时。

如果程序实在无法提供详细的数据，那么可以通过两个不同迭代步的测试（如test1 5 step ， test2 10 step ）来评估实际的迭代计算耗时。

进行测试

测试过程建议从可能的最小的并行规模开始测试，逐步增加并行规模。

单核计算（1N1n），单节点所有核(1N24n)，2个节点一半核(2N24n)，2个节点所有核(2N48n) 这几个规模的测试可以帮助评估通信性能对计算性能的影响。

需注意对于某些程序，并非将节点上的所有核都用满为最佳。

测试过程中建议登录到计算节点去看看计算进程的 cpu 和内存的利用率。

并行规模的增加 ：

• 如果性能随规模增加很明显（接近线性加速比），则按指数进行并行规模的增加，如 1， 2， 4， 8 ...
• 如果性能随规模有增加，但不明显，则按等差数列进行并行规模的增加
• 如果性能开始下降 ， 则可以减少节点数改动步幅前后都多测几个点，有些计算在特别的进程数下会有特殊的性能，多测几个点以避免偶然因素的影响。

结果分析

衡量性能的指标：

• 绝对计算性能： P ，推荐选用 单位时间内运行的迭代步数. 如果无法从LOG 中获取此指标，可以通过 K * 5 / ( time( test_10_step ) - time( test_10_step ) ) 这种方式来获得。此指标反映了排查其他因素影响下，单纯的CPU计算和通信性能反映的程序计算能力。
• 相对计算性能 P/N , N 为节点数， 反映了P 的效率。

如果程序的执行时间刨除迭代计算时间还有很显著的部分，一般是由于IO导致的，需要根据具体情况进行优化。

• 最优节点规模： 选择 P 最高的计算规模，或P 和 P/N 均较高的情况 ， 需自己进行权限。

• 是否存在通信问题 ： 单节点24核和 2节点24核 以及 2节点48核的计算性能对比 。跨节点计算会显著提高通信的代价，如果跨节点的性能损失太多可能需要考虑如何优化通信。

• 是否存在负载不均衡 ： 计算过程中，部分节点CPU 利用率较低。 个别计算程序存在守护进程，守护进程的CPU 利用率较低为正常现象，可通过活跃进程数和自己的计算设置是否相同来进行判断。

线性加速

随节点增加， P/N 不变 ，一般情况下是会降低的。