parallel-processing - 启用没有时间限制的 Univa Grid Engine 资源预留

Question

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

我们已经启用了一个票务系统，这样一个用户就不能霸占整个队列，但是如果网格和队列中充满了单 CPU 作业，那么就没有多 CPU 作业可以启动(它们只是坐在等待所需数量的 cpu 插槽空闲的队列顶部，这通常不会发生)。我们希望配置资源预留，这样，如果 MPI 作业是队列中的下一个作业，网格将在插槽空闲时保持打开状态，直到有足够的空间来提交 MPI 作业，而不是用单 CPU 填充它们队列中更靠后的作业。

我读过(例如 here)，网格根据在这些槽中运行的作业剩余的时间来决定“保留”哪些槽。我们遇到的问题是我们的作业有未知的运行时间。有些需要几秒钟，有些需要几周，虽然我们粗略地知道一项工作需要多长时间，但我们永远无法确定。因此，我们不想通过 -l h_rt 和 -l s_rt 开始运行带有硬时间限制和软时间限制的 qsub，否则我们的作业可能会过早终止。 Resource Reservation 似乎正在使用 default_duration，我们将其设置为无穷大，因为没有更好的数字可供使用，并且平等对待所有作业。它的拣选槽由已经运行了几天的长达一个月的作业填充，而不是由只运行了几秒钟的长达一分钟的作业填充。

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

Answer 1

不幸的是，我不知道有什么方法可以完成您的要求 - 我认为预订是在提交作业时创建的，而不是随着空位的增加而逐渐创建的。如果您还没有看过资源预留功能的设计文档，it's worth a look以适应该功能。

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

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

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

Since reservation scheduling performance consumption is known to grow with the number of pending jobs, use of -R y option is recommended only for those jobs actually queuing for bottleneck resources.