python - 使用 qsub 提交连续且独立的作业的速度有多快？

Question

这个问题与pbs job no output when busy相关。即当 PBS/Torque 处于“忙碌”状态时，我提交的一些作业没有输出。我想当许多作业一个接一个地提交时会更忙，而且碰巧的是，在以这种方式提交的作业中，我经常得到一些不产生任何输出的作业。

这里有一些代码。

假设我有一个名为“x_analysis.py”的 python 脚本，它将包含一些数据的文件作为其输入，并分析存储在文件中的数据：

./x_analyse.py data_1.pkl

现在，假设我需要： (1) 准备 N 个这样的数据文件：data_1.pkl, data_2.pkl, ..., data_N.pkl (2) 对每个文件进行“x_analysis.py”处理，并写入结果到他们每个人的文件。(3) 由于不同数据文件的分析都是相互独立的，所以我打算使用 PBS/Torque 并行运行它们以节省时间。（我认为这本质上是一个“令人尴尬的并行问题”。）

我有这个 python 脚本来执行上述操作：

import os
import sys
import time

N = 100

for k in range(1, N+1):
    datafilename = 'data_%d' % k
    file = open(datafilename + '.pkl', 'wb')
    #Prepare data set k, and save it in the file
    file.close()

    jobname = 'analysis_%d' % k
    file = open(jobname + '.sub', 'w')
    file.writelines( [ '#!/bin/bash\n',
                       '#PBS -N %s\n' % jobname,
                       '#PBS -o %s\n' % (jobname + '.out'),
                       '#PBS -q compute\n' ,
                       '#PBS -j oe\n' ,
                       '#PBS -l nodes=1:ppn=1\n' ,
                       '#PBS -l walltime=5:00:00\n' ,
                       'cd $PBS_O_WORKDIR\n' ,
                       '\n' ,
                       './x_analyse.py %s\n' % (datafilename + '.pkl') ] ) 
    file.close()

    os.system('qsub %s' % (jobname + '.sub')) 

    time.sleep(2.)

该脚本准备一组要分析的数据，将其保存到一个文件中，写入一个 pbs 提交文件来分析这组数据，提交作业以执行此操作，然后继续对下一组数据再次执行相同操作，等等。

事实上，当脚本运行时，作业 ID 列表会在作业提交时打印到标准输出。'ls' 表示有 N 个 .sub 文件和 N 个 .pkl 数据文件。“qstat”显示所有作业都在运行，状态为“R”，然后已完成，状态为“C”。但是，之后，'ls' 显示 .out 输出文件少于 N 个，“x_analysis.py”生成的结果文件少于 N 个。实际上，一些工作没有产出。如果我要清除所有内容，然后重新运行上述脚本，我会得到相同的行为，一些作业（但不必与上次相同）不会产生任何输出。

有人建议，通过增加提交连续作业之间的等待时间，情况会有所改善。

time.sleep(10.) #or some other waiting time

但我觉得这不是最令人满意的，因为我尝试了 0.1s、0.5s、1.0s、2.0s、3.0s，但都没有真正的帮助。有人告诉我，50s 的等待时间似乎很好，但如果我必须提交 100 个工作，等待时间将是大约 5000s，这似乎非常长。

我尝试通过提交作业数组来减少使用“qsub”的次数。我会像以前一样准备所有的数据文件，但只有一个提交文件，“analysis_all.sub”：

#!/bin/bash                                                                                                                                                    
#PBS -N analyse                                                                                                                            
#PBS -o analyse.out                                                                                                                        
#PBS -q compute                                                                                                                                                
#PBS -j oe                                                                                                                                                     
#PBS -l nodes=1:ppn=1                                                                                                                                          
#PBS -l walltime=5:00:00                                                                                                                                       
cd $PBS_O_WORKDIR

./x_analyse.py data_$PBS_ARRAYID.pkl

然后提交

qsub -t 1-100 analyse_all.sub

但即便如此，一些工作仍然不会产生产出。

这是个常见的问题吗？我做的不对吗？在工作提交之间等待是最好的解决方案吗？我可以做些什么来改善这一点吗？

提前感谢您的帮助。

编辑1：

我使用的是 Torque 2.4.7 版和 Maui 3.3 版。

此外，假设作业 ID 为 1184430.mgt1 的作业不产生任何输出，而作业 ID 为 1184431.mgt1 的作业按预期产生输出，当我在这些上使用“tracejob”时，我得到以下信息：

[batman@gotham tmp]$tracejob 1184430.mgt1
/var/spool/torque/server_priv/accounting/20121213: Permission denied
/var/spool/torque/mom_logs/20121213: No such file or directory
/var/spool/torque/sched_logs/20121213: No such file or directory

Job: 1184430.mgt1

12/13/2012 13:53:13  S    enqueuing into compute, state 1 hop 1
12/13/2012 13:53:13  S    Job Queued at request of batman@mgt1, owner = batman@mgt1, job name = analysis_1, queue = compute
12/13/2012 13:53:13  S    Job Run at request of root@mgt1
12/13/2012 13:53:13  S    Not sending email: User does not want mail of this type.
12/13/2012 13:54:48  S    Not sending email: User does not want mail of this type.
12/13/2012 13:54:48  S    Exit_status=135 resources_used.cput=00:00:00  resources_used.mem=15596kb resources_used.vmem=150200kb resources_used.walltime=00:01:35
12/13/2012 13:54:53  S    Post job file processing error
12/13/2012 13:54:53  S    Email 'o' to batman@mgt1 failed: Child process '/usr/lib/sendmail -f adm batman@mgt1' returned 67 (errno 10:No child processes)
[batman@gotham tmp]$tracejob 1184431.mgt1
/var/spool/torque/server_priv/accounting/20121213: Permission denied
/var/spool/torque/mom_logs/20121213: No such file or directory
/var/spool/torque/sched_logs/20121213: No such file or directory

Job: 1184431.mgt1

12/13/2012 13:53:13  S    enqueuing into compute, state 1 hop 1
12/13/2012 13:53:13  S    Job Queued at request of batman@mgt1, owner = batman@mgt1, job name = analysis_2, queue = compute
12/13/2012 13:53:13  S    Job Run at request of root@mgt1
12/13/2012 13:53:13  S    Not sending email: User does not want mail of this type.
12/13/2012 13:53:31  S    Not sending email: User does not want mail of this type.
12/13/2012 13:53:31  S    Exit_status=0 resources_used.cput=00:00:16 resources_used.mem=19804kb resources_used.vmem=154364kb resources_used.walltime=00:00:18

编辑 2：对于不产生输出的作业，“qstat -f”返回以下内容：

[batman@gotham tmp]$qstat -f 1184673.mgt1
Job Id: 1184673.mgt1   
Job_Name = analysis_7
Job_Owner = batman@mgt1
resources_used.cput = 00:00:16
resources_used.mem = 17572kb
resources_used.vmem = 152020kb
resources_used.walltime = 00:01:36
job_state = C
queue = compute
server = mgt1
Checkpoint = u
ctime = Fri Dec 14 14:00:31 2012
Error_Path = mgt1:/gpfs1/batman/tmp/analysis_7.e1184673
exec_host = node26/0
Hold_Types = n
Join_Path = oe
Keep_Files = n
Mail_Points = a
mtime = Fri Dec 14 14:02:07 2012
Output_Path = mgt1.gotham.cis.XXXX.edu:/gpfs1/batman/tmp/analysis_7.out
Priority = 0
qtime = Fri Dec 14 14:00:31 2012
Rerunable = True
Resource_List.nodect = 1
Resource_List.nodes = 1:ppn=1
Resource_List.walltime = 05:00:00
session_id = 9397
Variable_List = PBS_O_HOME=/gpfs1/batman,PBS_O_LANG=en_US.UTF-8, PBS_O_LOGNAME=batman,
    PBS_O_PATH=/gpfs1/batman/bin:/usr/mpi/gcc/openmpi-1.4/bin:/gpfs1/batman/workhere/instal
    ls/mygnuplot-4.4.4/bin/:/gpfs2/condor-7.4.4/bin:/gpfs2/condor-7.4.4/sb
    in:/usr/lib64/openmpi/1.4-gcc/bin:/usr/kerberos/bin:/usr/local/bin:/bi
    n:/usr/bin:/opt/moab/bin:/opt/moab/sbin:/opt/xcat/bin:/opt/xcat/sbin,
    PBS_O_MAIL=/var/spool/mail/batman,PBS_O_SHELL=/bin/bash,
    PBS_SERVER=mgt1,PBS_O_WORKDIR=/gpfs1/batman/tmp,
    PBS_O_QUEUE=compute,PBS_O_HOST=mgt1
sched_hint = Post job file processing error; job 1184673.mgt1 on host node
    26/0Unknown resource type  REJHOST=node26 MSG=invalid home directory '
    /gpfs1/batman' specified, errno=116 (Stale NFS file handle)
etime = Fri Dec 14 14:00:31 2012
exit_status = 135  
submit_args = analysis_7.sub
start_time = Fri Dec 14 14:00:31 2012
Walltime.Remaining = 1790
start_count = 1
fault_tolerant = False
comp_time = Fri Dec 14 14:02:07 2012

与产生输出的工作相比：

[batman@gotham tmp]$qstat -f 1184687.mgt1
Job Id: 1184687.mgt1
Job_Name = analysis_1
Job_Owner = batman@mgt1
resources_used.cput = 00:00:16
resources_used.mem = 19652kb
resources_used.vmem = 162356kb
resources_used.walltime = 00:02:38
job_state = C
queue = compute
server = mgt1
Checkpoint = u
ctime = Fri Dec 14 14:40:46 2012
Error_Path = mgt1:/gpfs1/batman/tmp/analysis_1.e118468
    7
exec_host = ionode2/0
Hold_Types = n
Join_Path = oe
Keep_Files = n
Mail_Points = a
mtime = Fri Dec 14 14:43:24 2012
Output_Path = mgt1.gotham.cis.XXXX.edu:/gpfs1/batman/tmp/analysis_1.out
Priority = 0
qtime = Fri Dec 14 14:40:46 2012
Rerunable = True   
Resource_List.nodect = 1
Resource_List.nodes = 1:ppn=1
Resource_List.walltime = 05:00:00
session_id = 28039 
Variable_List = PBS_O_HOME=/gpfs1/batman,PBS_O_LANG=en_US.UTF-8,
    PBS_O_LOGNAME=batman,
    PBS_O_PATH=/gpfs1/batman/bin:/usr/mpi/gcc/openmpi-1.4/bin:/gpfs1/batman/workhere/instal
    ls/mygnuplot-4.4.4/bin/:/gpfs2/condor-7.4.4/bin:/gpfs2/condor-7.4.4/sb
    in:/usr/lib64/openmpi/1.4-gcc/bin:/usr/kerberos/bin:/usr/local/bin:/bi
    n:/usr/bin:/opt/moab/bin:/opt/moab/sbin:/opt/xcat/bin:/opt/xcat/sbin,
    PBS_O_MAIL=/var/spool/mail/batman,PBS_O_SHELL=/bin/bash,
    PBS_SERVER=mgt1,PBS_O_WORKDIR=/gpfs1/batman/tmp,
    PBS_O_QUEUE=compute,PBS_O_HOST=mgt1
etime = Fri Dec 14 14:40:46 2012
exit_status = 0
submit_args = analysis_1.sub
start_time = Fri Dec 14 14:40:47 2012
Walltime.Remaining = 1784
start_count = 1

似乎一个的退出状态是 0 而另一个不是。

编辑3：

从上面的“qstat -f”输出来看，问题似乎与后期作业文件处理中的“过时 NFS 文件句柄”有关。通过提交数百个测试作业，我已经能够识别出许多产生失败作业的节点。通过ssh查看这些，我可以在中找到丢失的 PBS 输出文件/var/spool/torque/spool，我还可以在其中看到属于其他用户的输出文件。这些有问题的节点的一件奇怪的事情是，如果它们是唯一选择使用的节点，那么作业在它们上运行良好。只有当它们与其他节点混合时才会出现问题。

由于我不知道如何修复后期作业处理“过时的 NFS 文件句柄”，因此我通过向它们提交“虚拟”作业来避开这些节点

echo sleep 60 | qsub -lnodes=badnode1:ppn=2+badnode2:ppn=2

在提交实际工作之前。现在所有作业都按预期产生输出，无需等待连续提交。

score 2 · Accepted Answer

tracejob我在失败的作业的输出中看到了两个问题。

首先是Exit_status=135. 此退出状态不是 Torque 错误代码，而是脚本返回的退出状态，即x_analyse.py. sys.exit()Python 对函数的使用没有约定，135代码的来源可能在脚本中使用的模块之一中。

第二个问题是后期作业文件处理失败。这可能表示节点配置错误。

从现在开始，我猜。由于成功的作业大约需要 00:00:16，因此延迟 50 秒后，您的所有作业可能都会降落到第一个可用节点上，这可能是真的。使用较小的延迟，您会涉及更多节点，最终会遇到配置错误的节点或在单个节点上同时执行两个脚本。我会修改提交脚本添加一行

  'echo $PBS_JOBID :: $PBS_O_HOST >> debug.log',

到生成.sub文件的python脚本。如果我正确理解您的设置，这会将执行主机的名称添加到 debug.log 中，该名称将驻留在通用文件系统中。

然后，您（或 Torque 管理员）可能希望spool在故障节点的 MOM 目录中查找未处理的输出文件，以获取一些信息以进行进一步诊断。

python - 使用 qsub 提交连续且独立的作业的速度有多快？

1 回答 1

Related

Reference