2011-02-03 28 views
5

バイナリプログラムへの入力ファイルを準備し、SGEキューイングシステムバージョン6.2u2にバイナリプログラムの実行を提出するperlスクリプトがあります。SGE-QSUBは-syncモードでジョブをサブミットできません

ジョブは、親パールスクリプトがwaitpid機能を使用してサブミットされたジョブの状態を監視できるようにするため、-sync yオプションでサブミットされます。

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

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

残念ながら、私は次のエラーを取得しておいてください。

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

は 'containes' の綴りに注意してください。つまり、NOTです。これは、コード/エラーメッセージのこの領域がいかに維持されていないかを示しています。

このエラーを発生させようとした送信は、*.e{JOBID}および*.o{JOBID}というSTDOUTおよびSTDERRファイルを生成することさえできません。提出は完全に失敗します。

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

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

私の希望は、ここの誰かがこれを理解できるということです。これらの質問のいずれかに

回答は、このように私の問題を解決するだろう:

  1. このエラーはSGEの最近のバージョンに固執していますか?
  2. これを避けるためにqsubのコマンドラインオプションを変更することはできますか?
  3. このエラーメッセージは何について話していますか?

答えて

9

このサイトでは、SGE 6.2u5でこの問題が発生しました。私はメーリングリストにいくつかの質問を掲載しましたが、解決策はありませんでした。今まで。

エラーメッセージが偽であることが判明しました。私はUniva github "open-core"リポジトリの変更ログを読んでこれを発見しました。私は、後で、Grid Engine v8.0.0cリリースノートのSonに記載されている問題を見ました。ここで

はgithubのレポの関連コミットしている:

エラーメッセージ あなたは数の制限をヒットしたことである言うべき何

システム内のqsub sync -yの求人このパラメータはMAX_DYN_ECとして知られています。私たちのバージョンでのデフォルトは99で、増加上記の変更は、デフォルトの1000

は(sge_conf(5)のmanページから)MAX_DYN_ECの定義があること:

Sets the max number of dynamic event clients (as used by qsub -sync y and by Grid Engine DRMAA API library sessions). The default is set to 99. The number of dynamic event clients should not be bigger than half of the number of file descriptors the system has. The number of file descriptors are shared among the connections to all exec hosts, all event clients, and file handles that the qmaster needs.

あなたはどのように多くのを確認することができますあなたは、次のコマンドを使用して動的イベントクライアント:

$ qconf -secl | grep qsub | wc -l 

我々はqconf -mconf経由qmaster_paramsMAX_DYN_EC=1000を追加しました。私は何百ものqsub -sync yジョブを提出してテストしましたが、range_listエラーにはもう遭遇しませんでした。 MAX_DYN_ECが変更される前に、エラーが確実に発生します。

0

私はこの問題の解決方法を見つけましたが、少なくとも回避策がありました。

qsubの個々のインスタンスを、送信したジョブがまだキューに入っているか、実行中のままフォアグラウンドにとどまるようにしました。これは-syncオプションで実現しましたが、私の質問では恐ろしく予測できないバグが発生しました。

qrshコマンドにnow -nオプションを指定してこの問題を解決しました。これにより、ジョブはqsub -syncのように動作し、qrshインスタンスでwaitpidを使用してサブミットされたジョブが実行中であるかどうかを暗黙的に監視できます。

このソリューションの唯一の注意点は、対話型ノード(qrsh)と非対話型ノード(qsubでアクセス可能)の区別がないことです。区別がある場合(非対話型のノードよりも対話型のノードが少ない可能性が高い)、この回避策は役に立たない可能性があります。

しかし、これと同じように機能している問題の解決策にも近いものは見つかっていないので、私の同様の状況で捕らえられたどんな邪悪な魂にもこの記事を出すようにしてください。

+0

qsubとqrshの違いは何ですか? –

関連する問題