5

バイナリプログラムへの入力用にファイルを準備し、バイナリプログラムの実行をSGEキューイングシステムバージョン6.2u2に送信するperlスクリプトがあります。

ジョブは-sync y、親perlスクリプトがwaitpid関数を使用して送信されたジョブのステータスを監視できるようにするオプションを使用して送信されます。

親perlスクリプトにSIGTERMを送信すると、このシグナルが各子に伝播され、子がこのシグナルをqsubに転送して、関連するすべての送信済みジョブを正常に終了するため、これも非常に便利です。

-sync yしたがって、このオプションを使用してジョブを送信できることが非常に重要です。

残念ながら、次のエラーが発生し続けます。

Unable to initialize environment because of error: range_list containes no elements

'contains'の不適切なスペルに注意してください。それはタイプミスではありません。これは、コード/エラーメッセージのこの領域がいかに不十分に維持されている必要があるかを示しています。

このエラーを生成する送信を試行しても、STDOUTファイルとSTDERRファイル*.e{JOBID}およびは生成されません*.o{JOBID}。送信は完全に失敗します。

このエラーメッセージをグーグルで検索すると、あいまいなメッセージボードに未解決の投稿が表示されるだけです。

このエラーは確実には発生しません。スクリプトを再実行できますが、同じジョブで必ずしもエラーが発生するわけではありません。また、どのノードからジョブを送信しようとしても問題ではないようです。

私の希望は、ここの誰かがこれを理解できることです。

したがって、これらの質問のいずれかに答えると、私の問題は解決します。

  1. このエラーは、より新しいバージョンのSGEでも持続しますか？
  2. これを回避するためにqsubのコマンドラインオプションを変更できますか？
  3. このエラーメッセージは一体何を話しているのでしょうか。
4

2 に答える 2

9

私たちのサイトはSGE6.2u5でこの問題にぶつかりました。メーリングリストにいくつか質問を投稿しましたが、解決策はありませんでした。今まで。

エラーメッセージは偽物であることが判明しました。これは、Univagithubの「オープンコア」リポジトリの変更ログを読んで発見しました。後で、Son OfGridenginev8.0.0cリリースノートに記載されている問題を確認しました。

githubリポジトリの関連するコミットは次のとおりです。

エラーメッセージに表示されるのは、システム内のジョブ数の制限に達したということです。qsub sync -yこのパラメータはとして知られていMAX_DYN_ECます。私たちのバージョンのデフォルトは99でしたが、上記の変更により、デフォルトは1000に増加します。

MAX_DYN_EC（sge_conf（5）のマニュアルページから）の定義は次のとおりです。

動的イベントクライアントの最大数を設定します（qsub-syncyおよびGridEngineDRMAA APIライブラリセッションで使用されます）。デフォルトは99に設定されています。動的イベントクライアントの数は、システムにあるファイル記述子の数の半分を超えてはなりません。ファイル記述子の数は、すべてのexecホスト、すべてのイベントクライアント、およびqmasterが必要とするファイルハンドルへの接続間で共有されます。

次のコマンドを使用して、動的イベントクライアントの数を確認できます。

$ qconf -secl | grep qsub | wc -l

viaに追加MAX_DYN_EC=1000しました。何百ものジョブの送信をテストしましたが、range_listエラーは発生しなくなりました。変更する前は、そうすることで確実にエラーが発生します。qmaster_paramsqconf -mconfqsub -sync yMAX_DYN_EC

于 2011-11-22T21:43:42.303 に答える
0

私はこの問題の解決策を見つけました-または少なくとも回避策。

私の目標は、qsub送信されたジョブがまだキューにあるか実行中であるため、の個々のインスタンスをフォアグラウンドに残すことでした。これはオプションで達成されました-syncが、私の質問で説明する恐ろしく予測できないバグが発生しました。

この問題の解決策は、オプションを指定してqrshコマンドを使用することでした。これにより、qrshインスタンスでを使用して、送信されたジョブが実行されているかどうかをスクリプトが暗黙的に監視できるという点でnow -n、ジョブは同様に動作します。qsub -syncwaitpid

qrshこのソリューションの唯一の注意点は、操作しているキューが対話型ノード（によって提供される）と非対話型ノード（によってアクセス可能）を区別してはならないということqsubです。区別が存在する場合（非対話型よりも対話型ノードが少ない可能性が高い）、この回避策は役に立たない可能性があります。

しかし、これほど機能的な問題の解決策に近いものは何も見つからなかったのでqsub -sync、この投稿をインターウェブを越えて、私の同様の状況で捕らえられた邪悪な魂に向けて発信させてください。

于 2011-02-11T21:46:44.123 に答える