Parallel processing 启用Univa网格引擎资源保留而不受作业时间限制

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

我们已经启用了一个票务系统，这样一个用户就不能占用整个队列，但是如果网格和队列中充满了单CPU作业，那么就永远无法启动多CPU作业（它们只是坐在队列的顶部，等待所需数量的CPU插槽变为空闲，这通常不会发生）。我们希望配置资源预留，这样，如果MPI作业是队列中的下一个作业，网格将在空闲时保持插槽打开，直到有足够的时间提交MPI作业，而不是用队列中较低的单CPU作业填充它们

我读过（例如）网格根据在这些插槽中运行的作业剩余的时间来决定“保留”哪些插槽。我们的问题是我们的作业有未知的运行时间。有些需要几秒钟，有些需要几周，虽然我们大致知道一份工作需要多长时间，但我们永远无法确定。因此，我们不希望通过-l h_rt和-l s_rt以硬时间和软时间限制开始运行qsub，否则我们的工作可能会过早终止。资源保留似乎使用默认的_持续时间，由于没有更好的数字可以使用，我们将其设置为无穷大，并平等地对待所有作业。它的拣选时段由已经运行了几天的长达一个月的作业占据，而不是由只运行了几秒钟的每分钟作业占据

---

有没有一种方法可以告诉计划程序在多CPU MPI作业可用时为其保留插槽，而不是根据作业的某些感知运行时间预先选择插槽？

不幸的是，我不知道有什么方法可以满足您的要求-我认为在提交作业时会创建一次保留，当插槽变为空闲时，不会逐渐增加。如果您还没有看到资源保留功能的设计文档，请了解该功能

相反，我将建议一些自信地设置作业运行时的策略。当您的任何作业都没有运行时时，主要问题是网格引擎无法在将来无限地保留空间，因此即使您设置了一些非常粗略的运行时（在真正运行时的数量级内），您也可能会得到一些积极的结果

如果您以前运行过类似的作业，一个简单的经验法则是根据历史趋势将作业的最大运行时间设置为典型或最大运行时间的150%。使用

qacct

或解析

accounting

文件以获取硬数据。当然，将这个百分比调整到适合你的风险阈值

另一个经验法则是，设置最大运行时间不是基于作业的真实运行时间，而是基于对的感觉。“在此日期之后，结果将不会有用”或“如果需要这么长时间，肯定出了问题”。如果您需要在周五之前得到答案，那么设置三个月的运行时间限制是没有意义的。类似地，如果您在典型的兆字节大小的文件上运行md5sum，那么设置1天运行时间限制是没有意义的；这些工作应该只需要几秒钟或几分钟，如果真的需要很长时间，那么有些东西就坏了

如果您确实必须允许真正的不定长作业，那么一个选项是将集群划分为无限队列和有限队列。指定有限运行时的作业将能够使用这两个队列，而无限作业的可用资源将更少；这将激励用户更加努力地选择运行时，而不是强迫他们这样做 最后，确保提交多插槽作业时带有

-ry

qsub标志，以启用资源预留系统。这可能会出现在系统默认的sge_请求文件中，但通常不建议这样做，因为这样会降低调度性能：

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

---

谢谢你的回复。我有一种感觉，也许没有办法去做我想做的事，但我很高兴得到第二种意见。也谢谢你让我参考那份文件！我确实有这个问题。我们必须添加大量额外的基础设施来解决这个问题。但为什么SGE不只是推迟提交单插槽作业，直到它有足够的插槽用于多插槽作业？这是因为它在MPI作业到达队列顶部时选择要保留的插槽，但如果其他插槽提前打开，它不会调整。如果所有作业都具有相同的运行时（可能是从队列配置而不是从用户继承的），它只会选择最旧的作业。我们通过使用“-ldu rt=HH:MM:SS”qsub选项来解决这个问题，这是“估计”的运行时。如果作业超过此时间限制，它不会被终止，但它似乎有助于资源保留选择最佳的插槽以保持打开状态。不完美，但总比没有好。