SGE - QSUB无法以-sync模式提交作业

我们的网站在SGE 6.2u5中遇到了这个问题。我在邮件列表上发布了一些问题，但没有解决方案。到现在。 事实证明，错误信息是虚假的。我通过阅读Univa github“open-core”repo上的更改日志来发现这一点。我后来看到了Son of Gridengine v8.0.0c发行说明中提到的问题。 以下是github repo中的相关提交： https://github.com/gridengine/gridengine/commit/b449607972614e4608272d8c0fc6f109d35fbecc https://github.com/gridengine/gridengine/commit/a47c32f965111554ec076db1526a6ad62c5bdae5 错误消息应该说的是您已达到系统中

qsub sync -y

作业数量的限制。该参数称为

MAX_DYN_EC

。我们版本中的默认值为99，上面的更改将默认值增加到1000。

MAX_DYN_EC

的定义（来自sge_conf（5）手册页）是：   设置动态事件客户端的最大数量（由qsub -sync使用）   y和Grid Engine DRMAA API库会话）。默认设置   到99.动态事件客户端的数量不应该更大   超过系统具有的文件描述符数量的一半。数字   文件描述符的共享在所有exec的连接之间共享   主机，所有事件客户端和qmaster所需的文件句柄。 您可以使用以下命令检查有多少动态事件客户端：

$ qconf -secl | grep qsub | wc -l

我们已经通过

qconf -mconf

添加了

MAX_DYN_EC=1000

到

qmaster_params

。我已经测试了提交数百个

qsub -sync y

作业，我们不再遇到range_list错误。在

MAX_DYN_EC

更改之前，这样做会可靠地触发错误。     

我找到了解决这个问题的方法 - 或者至少是一种解决方法。 我的目标是让

qsub

的单个实例保持在前台，因为它提交的作业仍然在队列中或正在运行。这是通过

-sync

选项实现的，但导致我在我的问题中描述的可怕的不可预测的错误。 这个问题的解决方案是使用

qrsh

命令和

now -n

选项。这导致作业的行为类似于

qsub -sync

，因为我的脚本可以通过在qrsh实例上使用

waitpid

隐式监视提交的作业是否正在运行。 此解决方案的唯一警告是，您正在操作的队列不得在交互节点（由

qrsh

提供）和非交互节点（由

qsub

访问）之间进行任何区分。如果存在区别（可能交互节点少于非交互节点），则此解决方法可能无济于事。 然而，由于我发现什么都没有找到解决问题的解决方案，这个问题在任何地方都是如此的功能，让这篇文章穿过互联网走向任何在我类似情况下陷入困境的灵魂。