使用 qsub 一直运行任务有什么缺点吗?

使用 qsub 一直运行任务有什么缺点吗?

当我在计算机网络上运行任务时?我刚刚开始意识到如果我 qsub任何任务,那么该任务就不会占用我的终端,并且我可以在同一终端上执行其他操作(即使该任务只需要一分钟即可完成,这也非常有用)。

然后我运行 qstat 来查看哪些任务已完成,哪些任务尚未完成。

http://pubs.opengroup.org/onlinepubs/009604599/utilities/qsub.html是对qsub的一个很好的解释。

答案1

在这些情况下,我宁愿打开另一个终端。你不想这样做的原因是什么?

运行 qsub 的缺点是您必须为琐碎的操作编写一个很小的脚本文件,这会花费您一些时间。我不知道有多少其他用户正在同一网络上工作,但其目的是作为集群上多个用户的作业的调度程序。特别是如果没有可用的空闲核心,您的简单工作将最终排在队列中,从而花费您更多的时间。

您考虑过screen作为替代方案吗?您screen可以在同一终端中启动和暂停不同的会话。工作流程会是这样的

  • 在终端工作
  • $ screen
  • 你的小工作
  • 拆下屏幕 ( Ctrl- a Ctrl- d)
  • 在终端工作
  • $ screen -r(恢复)
  • 检查这个小工作的状态
  • $ exit
  • 你回来了

答案2

我没有看到使用qsub比标准有任何优势at。该at命令将采用“脚本”并执行它使用当前环境的特定时间(例如“现在”)。然后您可以使用 检查状态atq或删除作业atrm

$ nohup ./myscript myargs & # put script in the background
# almost the same as
$ echo ./myscript myargs | at now # computer runs script independent of terminals

您确实需要确保您myscript不会寻求意见。

正如伯恩哈德建议的那样,我自己screen无论走到哪里都在单个终端会话中使用。打开一个新窗口(在 内screen),启动脚本,切换回原始screen窗口。

答案3

qsub我认为使用通常在屏幕内交互式运行的后台作业没有任何缺点。如果您有可用的集群,那么这是最佳解决方案。

尽管我们有一个可用的作业调度程序,但很长一段时间我倾向于使用屏幕来后台长时间运行的作业或实现并行性,而无需大量 qsub 脚本编写开销。最终,这种方法的局限性变得明显,我编写了这个 qsub 包装器以允许我将andqgo替换为:&screenqsub

#!/bin/bash

mkdir -p qsubscripts

qsub -w $(pwd)/qsubscripts -d $(pwd) -M [email protected] $@ -S /bin/zsh -

请注意,我使用的是我首选的 shell (zsh),但您当然可以删除此参数,或添加其他参数。使用$@允许根据需要包含资源规范-l ncpus=4。以下是使用该脚本的方法:

echo 'command -a 23 -b zz' | qgo | tee jobids

STDERR.*和文件STDOUT.*将被写入qsubscripts当前工作目录中。The working directory for the job is set as thecwd` 上也提供了作业 ID ,这使得编写这些简短的脚本变得更加容易。

相关内容