两个pbs套用提交任务_第四节 HPC服务器申请多任务计算资源的技巧

假定我们有多个相同或相似任务需要运行，每个任务的总循环数是一个很大的常数。已知处理器越多，算得越快；但是申请处理器越多，在队列中的优先级越低，越难排上队。多个任务需要排队，每个任务申请几个处理器（处理器个数Nproc=节点数NDS*16）进行并行运算才能最大效率的利用资源呢？

我们以南安普顿大学的IRIDIS4（Torque PBS调度系统）为例进行分析。

单个任务例子的结构如下图所示：

一、Short answer:

分两步进行选择，第一步：选择可以让任务机时小于4小时（IRIDIS4上规定低于4小时的机时优先排队）的节点个数；

第二步：在节点数限制下，尽量使用全部节点数。例如：每个用户的节点数限制为32，则每个任务申请节点数可以为1、2、4、8、16、32. 如果申请节点数为9，则同时只能占用3*9=27个节点，剩余5个节点额度占用不到。

二、详细分析：

为了方便计算，假定以下条件成立：

• IRIDIS4规定，每个用户可以同时使用的CPU处理器个数为512个，系统利用率不高时可以提升至1024个。这里我们假设只能申请512个，即Nproc=512。因为每个节点（node）上只有16个处理器，所以每个用户可申请的节点总数为NDS=512/16=32。

注意，服务器是以节点为单位分配资源的，如果用户申请64个处理器，则会分配到4个节点；如果用户申请49个处理器，也会分配4个节点，这样的话最后一个节点就有15个处理器得不到利用。所以尽量申请16的整数倍个处理器。

• 申请的机时walltime越短，排队越靠前，尤其是低于4小时的情况（IRIDIS4的规定）。排队越靠前，任务之间的等待时间越短。现在为了简单计算，都默认为等待时间Twait=20分钟。
• 自己程序的运行时间T与处理器个数成线性关系，即：

（1）

其中LoopSize为整个任务的循环次数，Nproc为参加运算的处理器个数，t为单次循环的运行时间，需要用户进行估算。

假设我需要运行若干个蒙特卡洛仿真任务，每个任务为一个Job，则同时可以在服务器上运行的任务个数为NJob：

（2）

NDS为每个任务要求的节点数，Nproc= NDS*16，[.]为向下取整。向下取整的原因可以下例解释：如果用户每个任务需要NDS=7，则提交4个任务之后，已经使用了28个节点，还可再申请4个节点，但是4个节点又不满足提交一次任务的需求，所以只能浪费节点额度了。

---

基于以上3点模型简化条件，我们分析如何进行任务分配才能最高效的利用HPC资源。

以我的任务为例，先使用个人电脑做小规模串行运算试验，得到结果为：每运行1E7次循环，需要2个小时，单次循环时间为：

整个任务循环次数为LoopSize=1E9，如不使用并行运算，将需要200小时。

如果使用并行运算，将1E9次循环分配到Nproc=16*NDS个处理器上，按照公式（1）计算，得到任务执行时间为

实际上Nproc个处理器的运行速度并非完全相同，所以T实际上会是一个分布。如图1中所示，Njob=48，x轴为任务ID，每个任务占用Nproc个处理器，将所有Nproc个处理器的计算时间的分布画成一个箱型图（matlab boxplot函数），圆形箱中的黑点表示分布的中值（median）。NDS=6、7、8时，分别用不同颜色表示。

图1 实际任务占用处理器的时间分布图

为了简便计算，我们认为每个处理器的计算时间相等，且等于T的计算值 ，即公式(1)。当NDS=1：32时，得到T与NDS的关系如图2所示：

图2 单任务耗时与节点数NDS的关系曲线

---

如果选NDS=6，则T=2.08小时，同时可以运行的任务数为Njob=[32/6]=5。即每批次运行5个任务。假设每批次任务之间的等待时间是20分钟，则每批次运行需要的总时间为2.08+20/60=2.41小时。总计有960个任务，可分为960/5=192批次运行，总时间为2.41*192/24=19.28天。

如果选NDS=7, T=1.79小时. 同时可以运行的任务数为 Njob= [32/7]=4，加上等待时间，每批次运行时间为1.79+20/60=2.12小时。总计960个任务，可分为960/4=240批次运行，总时间为2.12*240/24=21.2天。

在可能的范围内，列表如下:

图3 显示了所有任务总时间Ttotal与单任务所需节点个数NDS的关系，X轴为NDS个数，Y轴为总时间。可以看出Ttotal的局部最小值出现在NDS=1、2、4，8，10，16，32时。

改变单次循环耗时t的值，再画Ttotal与NDS的曲线，可以得到图4。不同颜色的曲线代表不同的t值，可以看出无论t如何变化，Ttotal与NDS的相对关系不变，即Ttotal的局部最小值总是出现在NDS=1、2、4，8，10，16，32时。

图3 所有任务总时间Ttotal与单任务所需节点个数NDS的关系

图4 单次循环时间不同时，Ttotal与NDS的关系

如果按照图3来选，最优解应为NDS=1、2、4。但是IRIDIS4规定，申请时长walltime低于4个小时的资源申请，具有较高的优先级。因此我们排除了walltime大于4小时的选项，即 1、2、4个NDS的情况。剩余选项中，NDS=8为最优选项。

---

在上述分析中我们都假定了任务间排队等待时间Twait为20分钟，实际上PBS的排队算法是根据机时walltime和节点个数NDS计算每个任务的Twait的。算法比较复杂，我们不研究它，但是可以通过试验比较排队时间。我们比较NDS=6和NDS=8的情形。

根据图1，我们知道当NDS=6时，我们申请walltime=3：30：00可以保证所有处理器完成任务的时间。

当NDS=8时，申请walltime=2：45：00可以保证所有处理器完成任务的时间。

在服务器上同时提交48个NDS=6的任务和48个NDS=8的任务，结果是NDS=8的任务全部排在NDS=6的任务前面。

我们之前假定等待时间Twait相同时，NDS=8已经是最优解；现在实际情况下，又得到Twait（NDS=8）< Twait（NDS=6），说明在考虑等待时间的情况下，NDS=8也优于NDS=6。

在服务器上同时提交48个NDS=8的任务和48个NDS=10（walltime=02:10:00）的任务，结果是NDS=8的任务全部排在NDS=10的任务前面，即Twait（NDS=8）< Twait（NDS=10），说明在考虑等待时间的情况下，NDS=8也优于NDS=10。

所以，NDS=8的情况优于其他局部最优解。

三、结论

针对本次仿真，分析得出NDS=8时利用HPC服务器效率最高。