队列调度 谁先算？

abin

默认采用FIFO，
first in, first out.

为了提升最大效率，也有兼顾利用率。

假设
可用资源总计100个核心。

假设用户按甲乙丙的先后顺序提交计算。

现在空闲10个核心。

用户甲 申请20个核心， walltime设定24小时。
用户乙 申请2个核心，walltime 1小时
用户丙 申请5个核心，walltime 2小时

系统查询到，队列中，最快能完成的作业并且能空出10个核心，还需要30小时。
那么，接下来的30小时内，
让乙或者丙优先运行计算，并不会影响甲。
所以，虽然是后续提交作业的乙或者丙，可能先计算。

甚至，就算是恰好空闲20个核心，
由于甲申请时长很长，
而乙和丙时间较短， 也有可能乙和丙的计算先运行。

实际中，队列调度可能更复杂一些，
比如用户优先权，用户组有限权等等。

abin

再写几句。
调度流程，有时候可以类比为快递派送。

在派送deadline之前，
快递员可以优先派送物品轻巧，
派送耗时少，可以更快派送完的物品。

这样会显得，在某一个时间段内，
更快地派送出了更多的物品。

这就是，经常看到的，
后买的小件物品优先派送，
购买较早的大件物品，会稍晚派送。

调度系统，有时候为了保持高效率运作，
也会采取类似的策略。

要的核心数内存多，就是大件物品，
要的walltime长，就是要求派送的deadline更长久。
这是很好理解的事情。

当然现实中，会有高端会员，优先派送。
也就相当于队列中的VIP，具有较高的优先级。

对于小规模的集群系统，没有必要采用复杂的队列策略。
但是国家超算这种，
用户多，应用复杂的场景，
复杂的调度策略是必要的。

doublezhang

我们这边的一般用户都喜欢申请walltime=999:00:00
有利有弊，这也为偷鸡摸狗偷偷排队的人提供了机会

abin

doublezhang 发表于 2021-4-14 15:34
我们这边的一般用户都喜欢申请walltime=999:00:00
有利有弊，这也为偷鸡摸狗偷偷排队的人提供了机会

可以综合判定，
walltime很长， 但是连续一段时间，CPU负载， GPU负载很低，
就直接干掉该节点上的所有PBS session。

如果是slurm  要几个核心，去机器上，就只有几个核心， 祸害不了其他人。