第 9 章 チューニング、エラーメッセージ、および障害追跡

この章では、Grid Engine システム環境をチューニングするいくつかの方法を説明します。また、エラーメッセージの通知方法と、よくあるさまざまな問題の解決方法に関するヒントを説明します。

この章で説明する内容は、次のとおりです。

• 「グリッド環境のチューニング」

• 「Grid Engine ソフトウェアのエラーレポートの取得方法」

• 「問題の診断」

• 「一般的な問題の障害追跡」

グリッド環境のチューニング

Grid Engine システムは、完全な機能を有する、汎用分散リソース管理ツールです。システムのスケジューラコンポーネントは、幅広いさまざまな計算ファームのシナリオをサポートしています。計算環境から最大限のパフォーマンスを引き出すには、使用可能になっている機能を調べる必要があります。続いて、負荷管理問題を解決するためには実際にどの機能が必要であるかを決定する必要があります。これらの機能の一部を使用不可にすることで、クラスタのスループットのパフォーマンスが向上する可能性があります。

スケジューラ監視

スケジューラ監視は、一部のジョブが振り分けられなかった理由を調べる手助けになります。ただし、すべてのジョブに対して常にこの情報を提供すると、リソースを消費する可能性があります。通常は、この情報はそれほど必要ありません。

スケジューラ監視を使用不可にするには、スケジューラ構成で schedd_job_info を false に設定します。「QMON を使用したスケジューラ構成の変更」、および sched_conf (5) のマニュアルページを参照してください。

完了ジョブ

配列ジョブの場合、qmaster の完了ジョブのリストは非常に大きなサイズになることがあります。qstat は完了ジョブのリストの取得も行うため、完了ジョブのリストを無効化すると、メモリーが節約され、qstat プロセスが高速化します。

完了ジョブのリスト機能を無効化するには、クラスタ構成で finished_jobs をゼロに設定します。「QMON を使用したグローバルおよびホスト構成の追加と変更」、および sge_conf(5) のマニュアルページを参照してください。

ジョブの検査

ジョブ発行時に検査を強制することは、振り分け不可能なジョブが永続的に保留状態のままになることを防ぐための、重要な手続きになります。ただし、ジョブの検査は時間を消費するタスクになる可能性もあります。さまざまな実行ノードと消費可能リソースを抱え、すべてのユーザーが独自のジョブプロファイル を有する、異機種システム混在環境においては特に、ジョブの検査が時間を消費する可能性があります。異なるジョブがごく少数しかない同機種システム環境では、一般的なジョブの検査は省略できます。

ジョブの検査を使用不可にするには、クラスタ全体のデフォルト要求で、qsub のオプション –w n を追加します。『Sun N1 Grid Engine 6.1 ユーザーズガイド』の「QMON による高度なジョブの発行」、および sge_request(5) のマニュアルページを参照してください。

負荷しきい値および一時停止しきい値

慎重にマシンへの過剰な予約を行い、また過剰なシステム負荷を防ぐ必要がある場合に、負荷しきい値は必要です。一時停止しきい値も、システムに過剰な負荷をかけることを防止するために使用します。

ノードの過剰な負荷を防止する必要があるもう 1 つのケースは、実行ノードが対話型の負荷に対してオープンなままである場合です。対話型の負荷は、Grid Engine システムの制御下にありません。

計算ファームは、汎用度が低い場合があります。たとえば、計算ノードの各 CPU が唯一のキュースロットによってのみ表され、これらのノードでは対話型負荷が想定されていない場合があります。このような場合、load_thresholds を省略できます。

両方のしきい値を使用不可にするには、load_thresholds を none に設定し、suspend_thresholds を none に設定します。「負荷および一時停止しきい値の構成」、および queue_conf(5) のマニュアルページを参照してください。

負荷調整

ジョブが振り分けられたあと、測定された負荷を大きくするために、負荷調整を使用します。この仕組みにより、ジョブの振り分けと対応する負荷の影響との間の遅延が原因である、マシンの過剰な予約が防止されます。必要でない場合は、負荷調整をオフにできます。負荷調整は、ホストと負荷しきい値のソートを伴って、スケジューラに追加の作業を課すことになります。

負荷調整を使用不可にするには、スケジューラ構成で job_load_adjustments を none に設定し、load_adjustment_decay_time をゼロに設定します。「QMON を使用したスケジューラ構成の変更」、および sched_conf (5) のマニュアルページを参照してください。

直接スケジューリング

Grid Engine システムのデフォルトでは、固定スケジュール間隔でスケジューリング実行を開始します。固定間隔の優れた特徴としては、qmaster およびスケジューラの CPU 時間の消費を制限する点があります。好ましくない特徴としては、固定間隔はスケジューラを制限し、人為的にスループットを制限する点があります。多くの計算ファームには、qmaster とスケジューラ専用のマシンがあり、このような設定ではスケジューラを制限する理由がありません。sched_conf(5) の schedule_interval を参照してください。

スケジューラ構成の flush_submit_sec および flush_finish_sec パラメータを使用することで、直接スケジューリングを構成できます。「QMON を使用したスケジューラ構成の変更」、および sched_conf (5) のマニュアルページを参照してください。

直接スケジューリングがアクティブである場合、計算ファームのスループットは、sge_qmaster とスケジューラをホスティングしているマシンの能力によってのみ制限されます。

緊急度ポリシーおよびリソース予約

緊急度ポリシーを使用すると、リソースに依存するジョブ優先順位方式をカスタマイズできます。このようなジョブ優先順位方式には、次の要素が含まれます。

• 最大の並列ジョブを最初に実行する、一般的な優先

• 高価なライセンスを活用するために、特定のリソースを要求するジョブに対する優先

リソース予約を使用している場合、両方の目標の実現は特に重要です。

DTrace によるパフォーマンスチューニング

数千台のアクティブなコンポーネントにまたがる可能性がある分散システムの障害追跡は、もっとも経験の豊富なシステム管理者にとってさえ難題であることがあります。実際、Grid Engine 管理者には、本番の環境のパフォーマンス低下につながる問題を特定し、再現するための明確な手段はありません。Solaris 10 環境では、DTrace ユーティリティーを使用し、Grid Engine マスターコンポーネントのオンサイトパフォーマンスを監視できます。DTrace は、Solaris 10 環境での動的イベントをトレースするための包括的なフレームワークです。DTrace に関する全般的な情報については、http://www.sun.com/bigadmin/content/dtrace/ および dtrace のマニュアルページを参照してください。N1 Grid Engine 6.1 ソフトウェア での DTrace の使用の詳細は、$SGE_ROOT/dtrace/README_dtrace.txt ファイルを参照してください。

コマンド行からの DTrace によるパフォーマンスチューニング

Solaris 10 DTrace を使用できる場合は、$SGE_ROOT/dtrace/monitor.sh スクリプトを使用して、Grid Engine マスターを監視し、パフォーマンス上の問題点を探すことができます。monitor.sh スクリプトは次のオプションをサポートしています。

-interval value

統計間隔を指定します。デフォルトは 15sec です。間隔が広いほど統計精度は低く、狭いほど高くなります。特に有用な値の範囲は 1sec から 24hours です。

-cell cell-name

$SGE_CELL が「デフォルト」でない場合は必須です。

-spooling

統計に加えて qmaster スプールのプローブ情報も表示します。このオプションによって、推定されるスプールの問題点に関するより具体的な情報を表示できます。

-requests

外部からの qmaster 要求のプローブを表示します。このオプションによって、qmaster の処理が滞る原因になっているインスタンスを評価するためのより具体的な情報を表示できます。

重大なメッセージやエラー、警告メッセージがあると、 monitor.sh 出力に表示されます。

Grid Engine マスターのパフォーマンス上の問題の分析

効果的なパフォーマンスチューニングを実現するには、分散システムのパフォーマンス上の問題点を理解する必要があります。$SGE_ROOT/dtrace/monitor.sh スクリプトは、稼働中の Grid Engine マスターのスループット関連データを測定し、そのデータをいくつかのインデックスにまとめて 1 間隔当たり 1 行の形式で出力します。この表示の情報は 4 つの主要カテゴリに分かれます。

• スプーリング — qmaster プロセスにスプールされたオペレーション数と経過時間を示します。

• 要求処理 — レポート、GDI 要求、ACK メッセージなどの、さまざまな種類の送受信メッセージ数を示します。

• スケジューリング — schedd プロセスに送信されたスケジューリング要求数と経過時間を示します。

• Qmaster 処理 — qmaster/schedd 交信、qmaster 要求 I/O 活動、qmaster ロックおよびロック解除要求に関する情報で構成されます。

詳細は、下記の例を参照してください。

問題分析のための DTrace 出力例

ここでは、Grid Engine マスターの問題点を検出可能な事例の監視出力例を示します。この例には、次の情報が含まれます。

• qmaster のスプール活動:

  • #wrt — spool_write_object() および spool_delete_object() を使用した qmaster の書き込みオペレーション数。重要な書き込みオペレーションのほぼすべてが、この関数を通ります。

  • wrt/ms — 各スレッドが spool_write_object() に費やした時間の合計 (ミリ秒単位)。

• qmaster のメッセージ処理:

  • #rep — sge_c_report() 経由で qmaster が処理したレポート数。ここには、execd 関数から qmaster に送信された大部分のデータが反映されます。

  • #gdi — do_gdi_request() 経由で qmaster 処理した GDI 要求数。クライアントコマンドから送信されたもののほぼすべてが、 GDI 要求として受信されます。ただし、exexd 関数やスケジューラから GDI 要求が送られてくることもあります。

  • #ack — do_c_ack() 経由で qmaster が処理した ACK メッセージ数。ACK メッセージ数が多いということは、ジョブシグナリングが考えられます。ただし、ACK メッセージはほかの目的にも使用されます。

• schedd のスケジューリング活動:

  • #dsp — schedd での dispatch_jobs() 呼び出し回数。dispatch_jobs() の呼び出し 1 回は、スケジューリングの実行 1 回とみなすことができます。

  • dsp/ms — スケジューラが dispatch_jobs() の各呼び出しに費やした時間の合計

  • #sad — select_assign_debit() の呼び出し回数。select_assign_debit() の呼び出し 1 回は、スケジューラがジョブの割り当てまたは予約を 1 回試み たとみなすことができます。

• qmaster 処理:

  • #snd — qmaster が schedd に送信したイベントパッケージ数。この数値が長い時間をかけてゼロにまでなった場合は、どこかに問題があり、qmaster/schedd の同期が失われていることを意味します。

  • #rcv — schedd が qmaster から受信したイベントパッケージ数。この数値が長い時間をかけてゼロにまでなった場合は、どこかに問題があり、qmaster/schedd の同期が失われていることを意味します。

  • #in++ — qmaster 受信メッセージバッファーに追加されたメッセージ数。

  • #in-- — qmaster 受信メッセージバッファーから削除されたメッセージ数。1 間隔中に追加されたメッセージが削除されたメッセージより多い場合は、未処理メッセージの総数が増えることを意味します。

  • #out++ — qmaster 送信メッセージバッファーに追加されたメッセージ数。

  • #out-- — qmaster 送信メッセージバッファーから削除されたメッセージ数。1 間隔中に追加されたメッセージが削除されたメッセージより多い場合は、未配信メッセージの総数が増えることを意味します。

  • #lck0/#ulck0 — qmaster の “global” ロック関係の sge_lock()/sge_unlock() 呼び出し回数。qmaster の内部リスト (ジョブリスト、キューリストなど) にアクセスする場合は、必ずこのロックを取得する必要があります。

  • #lck0/#ulck0 — qmaster の “master_config” ロック関係の sge_lock()/sge_unlock() 呼び出し回数。このロックは二次的なロックですが、同じく重要です。

実際のシステムに表示されるコラムは、下記の例と異なることがあります。

この例では、17:40:32 から 17:41:05 の間にパフォーマンスが低下しています。

CPU     ID      FUNCTION:NAME
  0      1             :BEGIN                 Time |   #wrt  wrt/ms |#rep #gdi #ack|   #dsp  dsp/ms    #sad|   #snd    #rcv|  #in++   #in--  #out++  #out--|  #lck0  #ulck0   #lck1  #ulck1
  0  36909         :tick-3sec 2006 Nov 24 17:39:23 |      43       3|   0    8    4|      3     691     121|      4       4|     11      11      15      15|     68      68     289     288
  0  36909         :tick-3sec 2006 Nov 24 17:39:26 |      83      16|   0   10    3|      3     699     122|      3       3|     14      13      17      17|     90      90     681     681
  0  36909         :tick-3sec 2006 Nov 24 17:39:29 |     117      24|   0    9    4|      4    1092     198|      4       4|     13      13      17      17|     71      71     591     591
  0  36909         :tick-3sec 2006 Nov 24 17:39:32 |      19       4|   0    9    3|      3     591     147|      3       3|     12      12      15      15|     44      43     249     249
  0  36909         :tick-3sec 2006 Nov 24 17:39:35 |     144      28|   0    9    4|      4    1012     173|      4       4|     13      13      17      17|     61      62    1246    1247
  0  36909         :tick-3sec 2006 Nov 24 17:39:38 |      46       5|   0    8    3|      3     705     122|      3       3|     11      11      14      14|     67      67     293     293
  0  36909         :tick-3sec 2006 Nov 24 17:39:41 |     154      31|   0    9    3|      4     894     198|      3       3|     13      13      16      16|     73      72     968     969
  0  36909         :tick-3sec 2006 Nov 24 17:39:44 |      46       5|   0   10    4|      4     971     162|      4       4|     13      13      17      17|     71      72     304     304
  0  36909         :tick-3sec 2006 Nov 24 17:39:47 |     154      29|   0    8    3|      3     739     158|      3       3|     11      11      14      14|     67      67     990     990
  0  36909         :tick-3sec 2006 Nov 24 17:39:50 |      46       5|   0   10    4|      4     815     162|      4       4|     14      14      18      18|     76      76     692     693
  0  36909         :tick-3sec 2006 Nov 24 17:39:53 |      74      15|   0    8    3|      3     746     136|      3       3|     12      12      15      15|     54      53     571     571
  0  36909         :tick-3sec 2006 Nov 24 17:39:56 |     116      20|   0   11    4|      4     992     184|      4       4|     14      14      18      18|     80      81     669     669
  0  36909         :tick-3sec 2006 Nov 24 17:39:59 |      87      18|   0   11    4|      4     851     176|      5       4|     15      15      21      21|     77      76     670     670
  0  36909          :tick-3sec 2006 Nov 24 17:40:02 |     109      20|   0   12    5|      4     930     184|      4       5|     17      17      20      20|     77      78     624     624
   0  36909         :tick-3sec 2006 Nov 24 17:40:05 |      88      15|   0    9    3|      4     995     176|      3       3|     12      12      15      15|     71      71    1026    1026
  0  36909          :tick-3sec 2006 Nov 24 17:40:08 |     112      20|   0   12    4|      4     927     184|      5       4|     16      16      22      22|     81      81     652     652
  0  36909          :tick-3sec 2006 Nov 24 17:40:11 |      32       6|   0    7    4|      3     618     121|      3       4|     11      11      13      13|     54      53     336     336
  0  36909          :tick-3sec 2006 Nov 24 17:40:14 |     145      30|   0   11    4|      4     988     199|      4       4|     15      15      19      19|     64      65     827     827
  0  36909          :tick-3sec 2006 Nov 24 17:40:17 |      43       3|   0    7    3|      3     618     121|      3       3|     10      10      13      13|     64      64     286     286
  0  36909          :tick-3sec 2006 Nov 24 17:40:20 |     157      31|   0   11    4|      4     977     199|      4       4|     15      15      19      19|     80      80    1406    1408
  0  36909          :tick-3sec 2006 Nov 24 17:40:23 |      43       4|   0    7    3|      3     701     121|      3       3|     10      10      13      13|     64      64     285     285
  0  36909          :tick-3sec 2006 Nov 24 17:40:26 |      73      18|   0   11    4|      4     948     171|      4       4|     15      15      19      19|     77      77     700     700
  0  36909          :tick-3sec 2006 Nov 24 17:40:29 |     127      31|   0   10    4|      4     968     189|      4       4|     14      14      18      18|     74      74     584     584
  0  36909          :tick-3sec 2006 Nov 24 17:40:32 |      10       3|   0    6    0|      1     203      41|      0       0|     58       8      62      62|     23      22     106     106
  0  36909          :tick-3sec 2006 Nov 24 17:40:35 |      19       5|   0    5    0|      0       0       0|      0       0|      8       5      13      13|     30      30     200     200
  0  36909          :tick-3sec 2006 Nov 24 17:40:38 |      16       5|   0    5    1|      0       0       0|      0       0|      5       6      10      10|     27      26     558     559
  0  36909          :tick-3sec 2006 Nov 24 17:40:41 |       1       0|   0    4    0|      0       0       0|      0       0|      7       4      11      11|      9       9      34      34
  0  36909          :tick-3sec 2006 Nov 24 17:40:44 |       0       0|   0    4    0|      0       0       0|      0       0|      7       4      11      11|      8       8      28      28
  0  36909          :tick-3sec 2006 Nov 24 17:40:47 |       0       0|   0    6    0|      1     744      81|      1       1|     10       6      15      15|     14      14      33      33
  0  36909          :tick-3sec 2006 Nov 24 17:40:50 |       1       0|   0    5    1|      0       0       0|      0       0|      8       6      14      14|     11      11      49      49
  0  36909          :tick-3sec 2006 Nov 24 17:40:53 |       0       0|   0    4    0|      0       0       0|      0       0|      9       4      12      12|      6       7      28      28
  0  36909          :tick-3sec 2006 Nov 24 17:40:56 |       0       0|   0    5    0|      0       0       0|      0       0|      8       5      13      13|     12      12     420     420
  0  36909          :tick-3sec 2006 Nov 24 17:40:59 |       0       0|   0    4    0|      0       0       0|      0       0|      8       4      12      12|      9       8      30      30
  0  36909          :tick-3sec 2006 Nov 24 17:41:02 |       0       0|   0    4    1|      0       0       0|      0       0|     12       5      16      16|      7       8      25      25
  0  36909          :tick-3sec 2006 Nov 24 17:41:05 |     165      41|   0   48   60|      0       0       0|      1       1|     23     106      71      71|     96      97    1236    1236
  0  36909          :tick-3sec 2006 Nov 24 17:41:08 |     178      28|   0   15   53|      4     965     206|      4       4|     68      68      75      75|    130     130    1336    1336
  0  36909          :tick-3sec 2006 Nov 24 17:41:11 |     106      23|   0   27   35|      4     855     166|      4       4|     82      82      91      91|    115     114    1040    1040
  0  36909          :tick-3sec 2006 Nov 24 17:41:14 |     198      37|   0   41   70|      4    1189     196|      4       4|    185     185     185     185|    134     135    1327    1327
  0  36909          :tick-3sec 2006 Nov 24 17:41:17 |      16       5|   0    9    5|      4     940     161|      3       3|     17      17      20      20|     43      42     234     234
  0  36909          :tick-3sec 2006 Nov 24 17:41:20 |     162      35|   0   13    8|      4     958     200|      4       4|     23      23      28      28|     80      81    1018    1018
  0  36909          :tick-3sec 2006 Nov 24 17:41:23 |      44       6|   0    6    3|      2     544      81|      3       3|      8       8      11      11|     63      63     747     747
  0  36909          :tick-3sec 2006 Nov 24 17:41:26 |     150      34|   0   13    6|      4     921     199|      4       4|     21      21      25      25|     73      72     923     923
  0  36909          :tick-3sec 2006 Nov 24 17:41:29 |      43       3|   0    5    2|      2     506      81|      2       2|      7       7       9       9|     57      57     260     260
  0  36909          :tick-3sec 2006 Nov 24 17:41:32 |     157      37|   0    9    3|      4     978     199|      3       3|     13      13      16      16|     73      72     970     970
  0  36909          :tick-3sec 2006 Nov 24 17:41:35 |      43       3|   0    7    3|      2     512      85|      3       3|      9       9      12      12|     61      62     274     274
  0  36909          :tick-3sec 2006 Nov 24 17:41:38 |     127      29|   0    8    3|      4     994     185|      3       3|     11      11      14      14|     68      68    1265    1265
  0  36909          :tick-3sec 2006 Nov 24 17:41:41 |      66      11|   0   10    4|      4     973     171|      4       4|     14      14      18      18|     67      67     354     354
  0  36909          :tick-3sec 2006 Nov 24 17:41:44 |      48      10|   0    8    3|      3     785     128|      3       3|     11      11      14      14|     52      51     399     399
  0  36909          :tick-3sec 2006 Nov 24 17:41:47 |     142      31|   0   12    4|      4     913     192|      5       4|     17      17      23      23|     89      90     830     830
  0  36909          :tick-3sec 2006 Nov 24 17:41:50 |      64      13|   0   11    5|      4     853     168|      4       5|     15      15      18      18|     75      75     542     542

Grid Engine ソフトウェアのエラーレポートの取得方法

Grid Engine ソフトウェアは、特定のファイルにメッセージを記録するか、電子メールを送信する (または両方の手段) でエラーや警告を報告します。ログファイルには、メッセージ ファイルとジョブ STDERR 出力が含まれます。

ジョブが開始されるとただちに、ジョブスクリプトの標準的なエラー (STDERR ) 出力がファイルにリダイレクトされます。デフォルトのファイル名と位置が使用されますが、qsub コマンドのある種のオプションを使用してファイル名と位置を指定することもできます。詳細については、Grid Engine システムのマニュアルページを参照してください。

sge_qmaster、sge_schedd、および sge_execd のそれぞれに messages ファイルがあります。各ファイルには同じファイル名、 messages が付けられています。sge_qmaster ログファイルは、マスタースプールディレクトリに存在します。sge_schedd メッセージ ファイルは、スケジューラスプールディレクトリに存在します。実行デーモンのログファイルは、実行デーモンのスプールディレクトリに存在します。スプールディレクトリの詳細については、『Sun N1 Grid Engine 6.1 インストールガイド』の「ルートディレクトリの下のスプールディレクトリ」を参照してください。

各メッセージは、ファイル内の 1 行を使用します。各メッセージは、縦線記号 (|) で区切られた 5 つのコンポーネントに再分割されます。

メッセージのコンポーネントは、次のとおりです。

1. 最初のコンポーネントは、メッセージのタイムスタンプです。

2. 2 つ目のコンポーネントは、メッセージを生成するデーモンを指定します。

3. 3 つ目のコンポーネントは、デーモンが動作しているホスト名です。

4. 4 つ目はメッセージの種類です。メッセージの種類は、次のいずれかです。

   • 通知の N (情報提供が目的)

   • 情報の I (情報提供が目的)

   • 警告の W

   • エラーの E (エラー状態の検出)

   • 重大の C (プログラムの異常終了になる可能性あり)

   クラスタ構成で loglevel パラメータを使用して、グローバルまたはローカルにどのメッセージの種類を記録するかを指定します。

5. 5 つ目のコンポーネントは、メッセージのテキストです。

   ---

   注 –

   何らかの理由でエラーログファイルにアクセスできない場合、Grid Engine システムは、対応するホストのファイル /tmp/sge_qmaster_messages 、/tmp/sge_schedd_messages、または /tmp/sge_execd_messages にエラーメッセージを記録しようとします。

   ---

状況によっては、Grid Engine システムは電子メールでユーザーか管理者、またはその両方にエラーイベントを通知します。Grid Engine システムにより送信される電子メールメッセージには、メッセージ本文は含まれません。メッセージテキストは、メールの件名フィールドにすべて含まれます。

さまざまなエラーまたは終了コードの意味

次の表に、ジョブ関連のさまざまエラーコードまたは終了コードの意味を示します。これらのコードは、あらゆる種類のジョブに該当します。

次の表に、並列環境 (PE) 構成関連のジョブのエラーコードまたは終了コードの意味を示します。

次の表に、キュー構成関連のジョブのエラーコードまたは終了コードの意味を示します。これらのコードは、対応する方法が書き換えられた場合にのみ該当します。

次の表に、チェックポイント設定関連のジョブのエラーコードまたは終了コードの意味を示します。

デバッグモードでの Grid Engine システムのプログラムの実行

重大なエラー状態が発生した場合に、問題の特定に十分な情報がエラー記録機構によって生成されないことがあります。このため、Grid Engine システムには、ほぼすべての補助プログラムとデーモンをデバッグモードで実行する機能が用意されています。デバッグのレベルは、提供される情報の量および深さに応じて異なります。デバッグのレベルは、0 から10 の範囲で、10 はもっとも詳細な情報を提供するレベル、0 はデバッグ無効です。

デバッグレベルを設定するため、Grid Engine システムの配布には、ユーザーの .cshrc または .profile リソースファイルに対する拡張が用意されています。csh または tcsh のユーザーには、ファイル sge-root/util/dl.csh が含まれています。sh または ksh のユーザーに対応するファイルの名前は sge-root/ util/dl.sh です。標準のリソースファイルに、これらのファイルを取り込む必要があります。csh または tcsh のユーザーの場合は、.cshrc ファイルに次の行を含めます。

source sge-root/util/dl.csh

sh または ksh のユーザーの場合は、.profile ファイルに次の行を含めます。

. sge-root/util/dl.sh

いったんログアウトして、ログインし直すと、次のコマンドを使用してデバッグレベルの level を設定できるようになります。

% dl level

level が 0 より大きい場合、Grid Engine システムのコマンドを開始すると、トレース出力が STDOUT に書き込むようコマンドに強制します。このトレース出力には、警告メッセージ、ステータスメッセージ、エラーメッセージばかりでなく、内部的に呼び出されたプログラムモジュール名が含まれます。メッセージには、ユーザーが指定するデバッグレベルに応じて、エラーの報告に役立つ行番号情報も含まれます。

デバッグトレースを監視するには、大きなサイズのスクロール行バッファーを持つウィンドウを使用する必要があります。たとえば、1000 行のスクロール行バッファーを使用します。

ウィンドウが xterm の場合、 xterm のログ記録機構を使用してあとでトレース出力を調べることができます。

デバッグモードで Grid Engine システムデーモンの 1 つを実行すると、デーモンが端末接続を維持して、トレース出力を書き出します。こうした端末接続は、使用している端末エミュレーションの割り込み文字を入力することによって打ち切ることができます。たとえば、Control-C などを使用します。

デバッグモードを無効にするには、デバッグレベルを 0 に戻します。

dbwriter デバッグレベルの設定

sgedbwriter スクリプトは、dbwriter プログラムを開始します。このスクリプトの位置は、sge_root /dbwriter/bin/sgedbwriter です。sgedbwriter スクリプトは、dbwriter の構成ファイルである dbwriter.conf を読み取ります。この構成ファイルの位置は、sge_root/cell /common/dbwriter.conf です。この構成ファイルは、dbwriter のデバッグレベルを設定します。たとえば、次のように指定します。

#
# Debug level
# Valid values: WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL
#
DBWRITER_DEBUG=INFO

dbwriter コマンドの –debug オプションを使用すると、dbwriter により作成されるメッセージの数を変更できます。通常は、デフォルトのデバッグレベル info を使用する必要があります。より詳細なデバッグレベルを使用する場合は、dbwriter により出力されるデータ量を大幅に増やします。

次のデバッグレベルを指定できます。

warning

重大なエラーと警告のみが表示されます。

info

情報メッセージの数が追加されます。info はデフォルトのデバッグレベルです。

config

たとえば規則の処理に関する、dbwriter 構成に関連する追加の情報が得られます。

fine

さらに多くの情報が作成されます。このデバッグレベルを選択すると、dbwriter により実行されるすべての SQL 文が出力されます。

finer

デバッグ用に使用します。

finest

デバッグ用に使用します。

all

すべてのレベルの情報を表示します。デバッグ用に使用します。

問題の診断

Grid Engine システムには、問題の診断に役立つ、報告手段がいくつか用意されています。次の節では、これらの使用方法を説明します。

保留中のジョブが振り分けられない

保留中のジョブが実行可能な状態であることが明らかであるにもかかわらず、振り分けられないことがあります。Grid Engine システムには、その理由を調べる手段として qstat -j job-id と qalter-w v job-id のユーティリティーとオプションのペアがあります。

• qstat -j job-id

  有効である場合、qstat -j job-id は、最後のスケジューリング実行で特定のジョブが振り分けられなかった理由のリストを提供します。この監視機能は、有効または無効にすることができます。この監視機能は、sge_schedd デーモンと sge_qmaster との間の通信で望ましくないオーバーヘッドを生む可能性があるため、無効にすることができます。sched_conf (5) のマニュアルページの schedd_job_info を参照してください。ID が 242059 のジョブの出力を次の例に示します。

  % qstat -j 242059 scheduling info: queue "fangorn.q" dropped because it is temporarily not available queue "lolek.q" dropped because it is temporarily not available queue "balrog.q" dropped because it is temporarily not available queue "saruman.q" dropped because it is full cannot run in queue "bilbur.q" because it is not contained in its hard queuelist (-q) cannot run in queue "dwain.q" because it is not contained in its hard queue list (-q) has no permission for host "ori"

  この情報は、sge_schedd デーモンによって直接生成されます。この情報の生成には、クラスタの現在の使用量が考慮されます。この情報には、必要な情報が含まれないことがあります。たとえば、ほかのユーザーのジョブによってすべてのキュースロットがすでに占有されている場合、問題のジョブに関する詳細なメッセージは生成されません。

• qalter -w v job-id

このコマンドは、基本的にジョブが振り分けられない理由を一覧表示します。この目的のため、ドライスケジューリングが実行されます。スロットを含めて消費可能なすべてのリソースが、そのジョブ用に完全に利用可能であるとみなされます。負荷値は変化するため、すべての負荷値は無視されます。

ジョブまたはキューがエラー状態 E と報告される

ジョブまたはキューのエラーが、qstat 出力で、大文字の E で示されます。

ジョブがエラー状態になるのは、Grid Engine システムがジョブを実行しようとして、そのジョブに固有の理由で実行に失敗した場合です。

キューがエラー状態になるのは、Grid Engine システムがジョブを実行しようとして、そのキューに固有の理由で実行に失敗した場合です。

Grid Engine システムには、ジョブ実行エラーが発生した場合に、ユーザーおよび管理者がその診断情報を収集するための一群の機能が用意されています。キューおよびジョブのエラー状態のどちらも、原因はジョブの実行失敗にあります。そのため、診断機能は両方の種類のエラー状態に適用できます。

• ユーザー宛て中止メール。qsub -m a コマンドを使用してジョブが発行された場合は、-M user[@host] オプションで指定されたアドレスに中止メールが送信されます。中止メールには、ジョブのエラーに関する診断情報が含まれており、情報源として利用することを推奨します。

• qacct アカウンティング情報。 中止メールが得られない場合、qacct -j コマンドを実行できます。このコマンドにより、Grid Engine システムのジョブアカウンティング機能からジョブのエラーに関する情報を入手できます。

• 管理者宛て中止メール。管理者は、適切な電子メールアドレスを指定することによって、ジョブ実行時の問題に関する管理者宛てメールを送信するよう指示できます。sge_conf(5) のマニュアルページの administrator_mail の下を参照してください。管理者宛てのメールには、ユーザー宛ての中止メールよりも詳しい診断情報が含まれ、ジョブ実行エラーがよく発生する場合に利用することを推奨します。

• Messages ファイル。 管理者宛てのメールが得られない場合は、まず qmaster の messagesファイルを調べてください。適切なジョブ ID を検索することによって特定のジョブに関するエントリを見つけることができます。デフォルトの設定でインストールした場合、sge_qmaster messages ファイルは sge-root/cell/spool/qmaster/messages にあります。

  ジョブの起動元の sge_execd デーモンのメッセージに、補足情報が含まれていることもあります。qacct -j job-id を使用してジョブの起動元のホストを確認し、sge-root /cell/spool/host/messages でジョブ ID を検索します。

一般的な問題の障害追跡

この節では、一般的な問題の原因と対処に役立つ情報を説明します。

• 問題 — ジョブの出力ファイルに「Warning: no access to tty; thus no job control in this shell...」というメッセージが出力される。

  • 原因 — 少なくとも 1 つのログインファイルに stty コマンドが含まれていることが考えられます。stty コマンドが役立つのは、端末が存在する場合だけです。

  • 対策 — バッチジョブは端末に関連付けられません。すべての stty コマンドをログインファイルから削除するか、if 文でstty コマンドを囲う必要があります。if 文は、処理前に端末の有無をチェックします。次の例に if 文を示します。

    /bin/csh: stty -g # checks terminal status if ($status == 0) # succeeds if a terminal is present <put all stty commands in here> endif

• 問題 — ジョブの標準エラーログファイルに「`tty`:Ambiguous」というメッセージが出力される。しかし、ジョブスクリプトで呼び出されるユーザーのシェルには tty に対する参照はない。

  • 原因 — デフォルトでは、shell_start_mode は posix_compliant です。このため、すべてのジョブスクリプトは、キュー定義で指定されたシェルで実行されます。スクリプトは、ジョブスクリプトの先頭行に指定されたシェルでは実行されません。

  • 対策 — qsub コマンドに -S フラグを使用するか、shell_start_mode を unix_behavior に変更してください。

• 問題 — コマンド行からジョブスクリプトを実行できるが、qsub コマンドを使用して実行しようとすると、ジョブスクリプトが失敗する。

  • 原因 — ジョブに対するプロセス数が制限されている可能性があります。制限が設定されているかどうかをテストするには、limit と limit -h 機能を実行するテストスクリプトを記述します。シェルプロンプトから qsub コマンドを使用して両方の関数を対話的に実行し、結果を比較します。

  • 対策 — 構成ファイルから、シェルで制限を設けるすべてのコマンドを削除してください。

• 問題 — 実行ホストから負荷 99.99 が報告される。

  1. 原因 — ホストで sge_execd デーモンが動作していません。

     対策 — 実行ホストで root になり、sge-root/ cell/common/sgeexecd スクリプトを実行することによって sge_execd デーモンを起動します。

  2. 原因 — デフォルトドメインの指定に誤りがあります。

     対策 — Grid Engine システムの管理者として、qconf -mconf コマンドを実行し、default_domain 変数の値を none に変更します。

  3. 原因 — sge_qmaster ホストが認識している実行ホスト名と、その実行ホストが認識している自身の名前とが異なります。

     対策 — 計算クラスタのホスト名の解決に DNS を使用している場合は、主ホスト名として絶対パスによるドメイン名 (FQDN) が返されるように /etc/hosts と NIS を構成します。このように構成しても、当然、168.0.0.1 myhost.dom.com myhost というように短い別名を定義、使用することができます。

     DNS を使用していない場合は、/etc/hosts のすべてのファイルと NIS テーブルに矛盾がないようにします (例: 168.0.0.1 myhost.corp myhost または 168.0.0.1 myhost)。

• 問題 — 次のような警告が 30 秒おきに cell/spool/ host/messages に出力される。

  Tue Jan 23 21:20:46 2001|execd|meta|W|local configuration meta not defined - using global configuration

  しかし、cell/common/local_conf には、各ホスト用のファイルがあり、それぞれに FDQN が存在する。

  • 原因 — 使用しているマシン meta では、ホスト名解決でショート名が返されるのに対し、マスターマシンでは、FDQN 付きの meta が返されます。

  • 対策 — この点に関して、/etc/hosts のすべてのファイルと NIS テーブルの間に矛盾がないようにしてください。この例では、ホスト meta の /etc/hosts ファイルに、誤って次のようなテキストの行が含まれている可能性があります。

    168.0.0.1 meta meta.your.domain

    正しくは、この行は次のようにします。

    168.0.0.1 meta.your.domain meta.

• 問題 — デーモンの messages ファイルに CHECKSUM ERROR、WRITE ERROR、または READ ERROR というメッセージが出力されることがある。

  • 原因 — 1 秒間隔で出力されるのでないかぎり、何もする必要はありません。一般にこれらのメッセージは、1 日に 1 回から 30 回、出力されます。

• 問題 — ジョブが特定のキューで完了し、qmaster/messages に次のメッセージを返す。

  Wed Mar 28 10:57:15 2001|qmaster|masterhost|I|job 490.1 finished on host exechost

  しかし、実行ホストの exechost/messages ファイルには次のエラーメッセージが出力される。

  Wed Mar 28 10:57:15 2001|execd|exechost|E|can't find directory "active_jobs/490.1" for reaping job 490.1

  Wed Mar 28 10:57:15 2001|execd|exechost|E|can't remove directory "active_jobs/490.1": opendir(active_jobs/490.1) failed: Input/output error

  • 原因 — 自動マウントされる sge-root ディレクトリがマウント解除されたために、sge_execd デーモンが現在の作業ディレクトリを失った可能性があります。

  • 対策 — sge_execd ホストにローカルのスプールディレクトリを使用してください。QMON または qconf コマンドを使用して、execd_spool_dir パラメータを設定します。

• 問題 — qrsh ユーティリティーを使用して対話形式のジョブを発行しようとすると、次のエラーメッセージが表示される。

  % qrsh -l mem_free=1G error: error: no suitable queues

  しかし、qsub コマンドを使用したバッチジョブの発行に対してキューを使用できる。これらのキューは、qhost -l mem_free=1G および qstat -f -l mem_free=1G を使用して照会できる。

  • 原因 — 「error: no suitable queues」というメッセージの原因は、qrsh などの対話形式のジョブに対してデフォルトで有効になる submit の -w e オプションにあります。qrsh(1) のマニュアルページの -w e を参照してください。現在のクラスタ構成に従ってジョブが振り分け可能であるかどうかを sge_qmaster が確実に判断できない場合、このオプションがあると、submit コマンドで問題が発生します。この仕組みの意図は、許可できないジョブ要求を事前に拒否することにあります。

  • 対策 — この場合は、mem_free が消費可能リソースに設定されているにもかかわらず、ユーザーが各ホストで使用可能にするメモリーサイズを指定しなかったことが原因です。メモリー負荷値はそれぞれに異なるため、この検査では、メモリー負荷値は意図的に考慮されません。このため、クラスタ構成の一部では表示されません。この問題を解決するには、次のいずれかを行います。

    • qrsh のデフォルトオプション -w e を、-w n オプションを使用して明示的に無効にすることでこの検査を全般的に省略する。このコマンドを、 sge-root/cell/common/sge_request に配置することもできます。

    • mem_free を消費可能リソースとして管理する場合は、qconf -me hostname を使用して、host_conf の complex_values にあるホストに対し mem_free の容量を指定する。

    • mem_free を消費可能リソースとして管理しない場合は、qconf -me hostname を使用することで、complex(5) の consumable カラムで mem_free を消費不可リソースに戻す。

• 問題 — qrsh が、自身が動作しているのと同じノードに振り分けない。このとき qsh シェルから次のメッセージが返される。

  host2 [49]% qrsh -inherit host2 hostname error: executing task of job 1 failed: host2 [50]% qrsh -inherit host4 hostname host4

  • 原因 — gid_range が十分ではないことが考えられます。gid_range には、1 つの数字ではなく範囲として指定してください。Grid Engine システムは、ホスト上の各ジョブに固有の gid を割り当てます。

  • 対策 — qconf -mconf コマンドまたは QMON を使用して gid_range を調整してください。推奨する範囲は次のとおりです。

    gid_range 20000-20100

• 問題 — 並列ジョブ内で使用すると、qrsh -inherit -V が機能しない。次のメッセージが返される。

  cannot get connection to "qlogin_starter"

  • 原因 — この問題は入れ子にされた qrsh 呼び出しで発生します。原因は -V オプションです。最初の qrsh -inherit 呼び出しでは、環境変数 TASK_ID が設定されます。TASK_ID は、並列ジョブ内の密接に統合されたタスクの ID です。2 つ目の qrsh -inherit 呼び出しでは、このタスクの登録に環境変数を使用します。すでに実行中の最初のタスクと同じ ID を持つタスクを開始しようとするため、このコマンドは失敗します。

  • 対策 — qrsh -inherit を呼び出す前に TASK_ID を設定解除するか、-V ではなく -v オプションを使用します。このオプションにより、実際に必要な環境変数だけエクスポートされます。

• 問題 — qrsh がまったく機能していないように見える。次のようなメッセージが返される。

  host2$ qrsh -verbose hostname local configuration host2 not defined - using global configuration waiting for interactive job to be scheduled ... Your interactive job 88 has been successfully scheduled. Establishing /share/gridware/utilbin/solaris64/rsh session to host exehost ... rcmd: socket: Permission denied /share/gridware/utilbin/solaris64/rsh exited with exit code 1 reading exit code from shepherd ... error: error waiting on socket for client to connect: Interrupted system call error: error reading return code of remote command cleaning up after abnormal exit of /share/gridware/utilbin/solaris64/rsh host2$

  • 原因 — qrsh に対する権限が正しく設定されていない可能性があります。

  • 対策 — sge-root/utilbin/ にある次のファイルの権限を調べてください。rlogin および rsh は setuid であり、かつ root により所有されている必要があることに注意してください。

    -r-s--x--x 1 root root 28856 Sep 18 06:00 rlogin* -r-s--x--x 1 root root 19808 Sep 18 06:00 rsh* -rwxr-xr-x 1 sgeadmin adm 128160 Sep 18 06:00 rshd*

    ---

    注 –

    sge-root ディレクトリも、setuid オプションで NFS マウントされている必要があります。sge-root が発行クライアントから nosuid でマウントされている場合、qrsh と、関係するコマンドは機能しません。

    ---

• 問題 – 分散 make を起動しようとすると、次のエラーメッセージで qmake が終了する。

  qrsh_starter: executing child process qmake failed: No such file or directory

  • 原因 — Grid Engine システムは、実行ホストで qmake のインスタンスを起動します。Grid Engine システム環境 (特に PATH 変数) がユーザーのシェルリソースファイル (.profile または .cshrc) に設定されていない場合、この qmake の呼び出しは失敗します。

  • 対策 — -v オプションを使用して、PATH 環境変数を qmake ジョブにエクスポートしてください。次は、一般的な qmake の呼び出し例です。

    qmake -v PATH -cwd -pe make 2-10 --

• 問題 — qmake ユーティリティーを使用する際、次のエラーメッセージが返される。

  waiting for interactive job to be scheduled ...timeout (4 s) expired while waiting on socket fd 5 Your "qrsh" request could not be scheduled, try again later.

  • 原因 — qmake の呼び出し元であるシェルに ARCH 環境変数が正しく設定されていない可能性があります。

  • 対策 – クラスタで使用可能なホストに一致するサポート値を ARCH 変数に設定するか、発行時に適切な値を指定してください (例: qmake -v ARCH=solaris64 ...)。

• 問題 — 次のジョブが SuSE Linux システムに割り当てられると、-cwd オプションが機能しないで、ユーザーのホームディレクトリに cwd-test が作成される。

  qsub -l arch=lx24-x86 -cwd -b y -o /dev/null -e /dev/null -V "hostname | tee -a cwd-test"

  • 原因 — SuSE Linux システムの場合、/etc/csh.login ファイルには、現在の作業ディレクトリをユーザーのホームディレクトリに変更する cd コマンドが含まれています。通常、シェルはシステム全体のプロファイルファイルを参照します。Linux の(t)csh の場合、システム全体のファイルは /etc/csh.login です。

  • 対策 – -noshell オプションを使用してください。この場合は、プロファイルファイルを参照することが可能な中間のシェルが存在しないため、~/.login または ~/.cshrc のどちらも参照されません。

    バッチスクリプトを使用するときは、あらゆるプログラムの実行前に、PWD 環境変数を使用して、そのバッチスクリプト内の現在の作業用ディレクトリを変更してください。

    これ以外の回避策は、ユーザーが tcsh または csh のどちらも使用しないことです。cd コマンドは /etc/csh.login にのみ現れるため、問題が起きなくなります。