在没有作业时间限制的情况下启用Univa Grid Engine资源预留

Question

我的组织有一个运行Univa Grid Engine 8.4.1的服务器集群，用户提交各种类型的作业，一些使用单个CPU核心，一些使用OpenMPI来利用多个核心，所有这些都具有不同的和不可预测的运行时间。

我们启用了一个票务系统，以便一个用户可以占用整个队列，但如果网格和队列中装满了单CPU作业，则无法启动多CPU作业（它们只是坐在队列的顶部，等待所需数量的cpu插槽变为空闲，这通常不会发生。我们正在寻找配置资源预留，这样，如果MPI作业是队列中的下一个，网格将保持空闲，因为它们已经空闲，直到足以提交MPI作业，而不是填写它们使用队列中较低的单CPU作业。

我已经阅读过（例如here），网格决定哪些广告位是＆＃34;保留＆＃34;根据这些插槽中运行的作业剩余时间。我们遇到的问题是我们的工作有不确定的运行时间。有些需要几秒钟，有些需要几周时间，虽然我们大致了解工作需要多长时间，但我们永远无法确定。因此，我们不想通过-l h_rt和-l s_rt开始运行具有硬和软时间限制的qsub，否则我们的工作可能会过早被杀死。资源预留似乎使用default_duration，我们将其设置为无穷大，因为缺少更好的数字，并且平等地处理所有作业。它的采摘位置已经运行了几个月，而且已经运行了几天，而不是只运行了几分钟的长时间工作的插槽。

有没有办法告诉调度程序在多CPU MPI作业可用时保留插槽，而不是根据其中某些感知的作业运行时间预先选择插槽？

Answer 1

不幸的是，我不知道如何做你所要求的事情 - 我认为保留是在提交作业时创建的，而不是随着广告位空闲而逐步创建。如果您还没有看到资源预留功能的设计文档，it's worth a look将面向该功能。

相反，我将建议一些自信地设置工作运行时的策略。当你的任何作业都没有运行时的主要问题是Grid Engine未来无法无限地保留空间，所以即使你设置了一些非常粗糙的运行时（在真实运行时的一个数量级内），你可能会得到一些积极的结果。

1. 如果您以前经营过类似的工作，根据历史趋势，一个简单的经验法则是将最大运行时间设置为作业的典型或最大运行时间<150％。使用qacct或解析accounting文件以获取硬数据。当然，将该百分比调整为适合您的风险阈值。
2. 另一个经验法则是设置最大运行时间不是基于作业的真实运行时间，而是基于＆＃34;在此日期之后的结果，结果不会是有用的＆＃34; 或＆＃34;如果花了这么长时间，那肯定是错的＆＃34; 。如果您需要在星期五之前得到答案，那么将运行时限制设置为三个月是没有意义的。同样，如果您在典型的兆字节大小的文件上运行md5sum，那么设置1天的运行时限制就没有意义;那些工作应该只需要几秒钟或几分钟，如果它真的花了很长时间，那么就会有一些东西被打破。
3. 如果你真的必须允许真正的无限期工作，那么一个选择是将你的集群划分为无限和有限队列。指定有限运行时的作业将能够使用两个队列，而无限作业将拥有更少的可用资源;这将激励用户在选择运行时更加努力，而不必强迫他们这样做。

最后，请确保使用-R y qsub标志提交多插槽作业以启用资源预留系统。这可以放在系统默认的sge_request文件中，但通常不推荐这样做，因为它会降低调度性能：

  

由于已知预留调度性能消耗随着待处理作业的数量而增长，因此建议仅对实际排队等待瓶颈资源的作业使用-R y选项。