python - 使用qsub提交连续和独立的作业有多快?

标签 python cluster-computing pbs qsub torque

这个问题与pbs job no output when busy有关也就是说,当PBS/TORQUE处于“忙碌”状态时,我提交的一些作业不会产生输出。我想,当许多作业被一个接一个地提交时,会更忙,而且碰巧,在以这种方式提交的作业中,我经常会得到一些不产生任何输出的作业。
这里有一些密码。
假设我有一个名为“x_analyze.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'显示只有少于N个输出文件,并且由“x_analyze.py”生成的结果文件少于N个实际上,有些工作没有产出。如果清除所有内容并重新运行上面的脚本,我将得到相同的行为,一些作业(但不必与上次相同)不会产生任何输出。
有人建议,通过增加连续提交作业之间的等待时间,情况会有所改善。
time.sleep(10.) #or some other waiting time

但我觉得这不是最令人满意的,因为我试过0.1,0.5,1.0,2.0,3.0,这些都没有帮助。有人告诉我,50秒的等待时间看起来不错,但如果我必须提交100份工作,那么等待时间大约为5000秒,这似乎非常长。
我试图通过提交作业数组来减少使用'qsub'的次数我会像以前一样准备所有的数据文件,但是只有一个提交文件,“analyze_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'输出来看,问题似乎与作业后文件处理中的'Stale NFS file handle'有关通过提交数百个测试作业,我已经能够识别出产生失败作业的许多节点。通过对这些文件进行ssh操作,我可以在/var/spool/torque/spool中找到丢失的pbs输出文件,在这里我还可以看到属于其他用户的输出文件。这些有问题的节点有一个奇怪的地方,如果它们是唯一被选择使用的节点,那么作业就可以在它们上面正常运行。只有当它们与其他节点混合时,问题才会出现。
由于我不知道如何修复作业后处理“过时的nfs文件句柄”,所以我通过向这些节点提交“虚拟”作业来避免这些节点
echo sleep 60 | qsub -lnodes=badnode1:ppn=2+badnode2:ppn=2

在提交真正的工作之前。现在,所有的工作岗位都按预期产出,不需要等待连续提交。

最佳答案

我在失败作业的tracejob输出中看到两个问题。
首先是Exit_status=135。此退出状态不是扭矩错误代码,而是脚本返回的退出状态,它是“cc>”。python没有使用x_analyse.py函数的约定,sys.exit()代码的源可能在脚本中使用的某个模块中。
第二个问题是作业后文件处理失败这可能表示节点配置错误。
从现在开始我猜由于一个成功的作业需要大约00:00:16,因此在延迟50秒的情况下,您可能会将所有作业降落到第一个可用节点上。延迟越小,涉及的节点就越多,最终会碰到一个配置错误的节点,或者让两个脚本在一个节点上并发执行我将修改提交脚本,添加一行

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

生成135文件的python脚本。这会将执行主机的名称添加到debug.log中,如果我正确理解您的设置,该日志将驻留在公共文件系统中。
然后,您(或torque管理员)可能希望在故障节点上的mom.sub目录中查找未处理的输出文件,以获取一些信息,以便进一步诊断。

关于python - 使用qsub提交连续和独立的作业有多快?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13849604/

相关文章:

python - 使用python比较两个数组中的元素并在一个值大于另一个值时返回True

python - 存储程序序列的数据结构 - Python

cluster-computing - 为什么在 Slurm 中重复调用 squeue 不受欢迎?

elasticsearch - 适用于具有大量聚合的大型集群的ElasticSearch设置

pbs - 请求节点的所有处理器

pbs - 在 PBS 作业脚本中获取挂墙时间

python - 在Python中,如何分割字符串并保留分隔符?

python - 在提取列之后立即将 df[col].str.extract() 结果插入原始 Pandas df 的 pandanic 方式

python - Python 中总计 "CPU hours"

c++ - 如果可执行文件在两个或多个节点上运行,为什么无法看到环境变量?