4

この質問は、ビジー状態のときに出力されないpbsジョブに関連しています。つまり、PBS / Torqueが「ビジー」の場合、送信するジョブの一部は出力を生成しません。たくさんの仕事が次々と提出されると忙しいのではないかと思いますが、そういう形で提出された仕事の中には、何も出てこないものがよくあります。

ここにいくつかのコードがあります。

「x_analyse.py」というPythonスクリプトがあり、その入力としてデータを含むファイルを受け取り、そのファイルに保存されているデータを分析するとします。

./x_analyse.py data_1.pkl

ここで、次のことを行う必要があるとします。(1)N個のそのようなデータファイルを準備します:data_1.pkl、data_2.pkl、...、data_N.pkl(2)「x_analyse.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」は、「x_analyse.py」によって生成された.out出力ファイルがN個未満であり、結果ファイルがN個未満であることを示しています。実際、一部のジョブでは出力が生成されません。すべてをクリアして上記のスクリプトを再実行すると、同じ動作が得られますが、一部のジョブ(前回と同じである必要はありません)では出力が生成されません。

連続した仕事の提出間の待ち時間を増やすことによって、物事は改善することが示唆されています。

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

しかし、私は0.1秒、0.5秒、1.0秒、2.0秒、3.0秒を試しましたが、どれも実際には役に立たなかったので、これは最も満足のいくものではないと感じています。50代の待ち時間は問題ないようだと言われていますが、100件の求人を提出しなければならない場合、5000秒程度の待ち時間になり、非常に長いようです。

代わりにジョブ配列を送信して、「qsub」が使用される回数を減らしてみました。以前と同じようにすべてのデータファイルを準備しますが、送信ファイルは「analyse_all.sub」の1つだけです。

#!/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ここでは、他のユーザーに属する出力ファイルも確認できます。これらの問題のあるノードの奇妙な点の1つは、それらが使用するように選択された唯一のノードである場合、ジョブはそれらで正常に実行されることです。この問題は、他のノードと混在している場合にのみ発生します。

ポストジョブ処理の「古いNFSファイルハンドル」を修正する方法がわからないため、「ダミー」ジョブを送信することでこれらのノードを回避します

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

実際の仕事を提出する前に。これで、すべてのジョブが期待どおりに出力を生成し、連続して送信されるまで待つ必要がなくなりました。

4

1 に答える 1

2

tracejob失敗したジョブの出力に 2 つの問題があります。

まずですExit_status=135。この終了ステータスは Torque エラー コードではなく、スクリプトによって返される終了ステータスですx_analyse.pysys.exit()Python には関数の使用に関する規則がなく、135コードのソースはスクリプトで使用されるモジュールの 1 つにある場合があります。

2 つ目の問題は、ポスト ジョブ ファイルの処理の失敗です。これは、ノードの構成が誤っていることを示している可能性があります。

これからは推しです。ジョブが成功するには約 00:00:16 かかるため、おそらく 50 秒の遅延ですべてのジョブが最初に使用可能なノードに到達することは事実です。遅延が小さいと、より多くのノードが関与し、最終的には構成が不適切なノードにヒットするか、1 つのノードで 2 つのスクリプトが同時に実行されます。行を追加して送信スクリプトを変更します

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

.subファイルを生成する python スクリプトに。これにより、実行ホストの名前が debug.log に追加されます。これは、セットアップが正しく理解されていれば、共通のファイルシステムに存在します。

次に、あなた (または Torque 管理者) は、障害が発生したノードの MOM ディレクトリで未処理の出力ファイルを探して、spoolさらに診断するための情報を取得することができます。

于 2012-12-14T12:39:27.427 に答える