この節では、Grid Engine システムが実行用にジョブをどのようにスケジューリングするかを説明します。また、さまざまな種類のスケジューリング戦略と、スケジューラを構成する方法についても説明します。
Grid Engine システムでは、次のジョブスケジューリング処理が行われます。
振り分け前の決定。キューがいっぱいであるか過負荷状態であるためキュー削除する、現在実行には適切でないジョブをスプールする、優先順位の高いジョブにリソースを要約するなどの処理
振り分け。そのほかの保留中のジョブおよび実行中のジョブを考慮したジョブの重要性の決定、クラスタ内の全てのマシン上の負荷の検知、および構成済みの選択基準に基づいて選択されたマシン上のキューへのジョブの送信
振り分け後の監視。 ジョブがリソースを取得した時点、および独自の相対的な重要性を持つそのほかのジョブがシステムに出入りした時点での、ジョブの相対的な重要性の調整
Grid Engine ソフトウェアは、次の基準に基づいて、コンピュータの異機種システム混在クラスタでジョブをスケジューリングします。
クラスタの現在の負荷
ジョブの相対的な重要性
ホストの相対的なパフォーマンス
CPU、メモリー、および I/O 帯域幅など、ジョブのリソース要求
スケジューリングに関する決定は、サイトの戦略と、クラスタ内の各コンピュータの瞬間的な負荷の特性に基づいて行われます。サイトのスケジューリング戦略は、Grid Engine システムの構成パラメータを介して表されます。負荷特性は、動作中のシステムのパフォーマンスデータを収集することによって確認されます。
管理者は、次のスケジューリング業務について戦略を立てることができます。
動的リソース管理。Grid Engine システムは、実行中のジョブに割り当てられるリソースのエンタイトルメントを動的に制御および調整します。つまり、システムが CPU の配分を変更します。
リソース予約およびバックフィリング。リソース予約は、ジョブのリソースを予約し、 低優先順位のジョブによる使用をブロックします。バックフィリングにより、リソースを使用しても予約に干渉しない場合は、低優先順位のジョブが、ブロックされたリソースを使用できます。
Grid Engine ソフトウェアは、次の 3 つのチケットに基づくポリシーの重み付けされた組み合わせを使用して、ジョブスケジューリング戦略の自動化を実現します。
共有ベース
機能 (プライオリティと呼ばれる場合もあり)
優先
Grid Engine システムを設定して、日常的に共有ベースポリシーと機能ポリシーのいずれか、またはその両方を使用するよう構成できます。これらのポリシーは、任意に組み合わせることができます。たとえば、1 つのポリシーにゼロの重みを与え、2 つ目のポリシーのみを使用することができます。また、両方のポリシーに同じ重みを与えることもできます。
日常的なポリシーとともに、管理者は共有ベースおよび機能スケジューリングを一時的に無効にしたり、エクスプレスキューなどの目的のために永続的に無効にすることができます。優先は、1 つのジョブに対して適用することも、ユーザー、部署、プロジェクト、ジョブクラス (すなわち、キュー) に関連付けられているすべてのジョブに適用することもできます。
Grid Engine システムには、すべてのジョブ間の調停をするためのこれら 3 つのポリシーのほかに、ユーザーが自分のジョブに優先順位を設定する機能もあります。たとえば、あるユーザーには、ジョブ 1 と 2 の重要性は同じであり、ジョブ 3 はジョブ 1 と 2 よりも重要である場合があります。ユーザーは、ポリシーの組み合わせに共有ベースポリシー、機能ポリシー、またはその両方が含まれる場合、独自のジョブの優先順位を設定することができます。また、ジョブには機能チケットを付与する必要があります。
共有ベース、機能、および優先スケジューリングポリシーは、チケットを使用することで実現されます。各ポリシーにはチケットのプールがあります。ジョブが複数のマシンから成る Grid Engine システムに入力された時点で、ポリシーはチケットをジョブに割り当てます。有効である日常的な各ポリシーは、一部のチケットを新しい各ジョブに割り当てます。ポリシーは、各スケジューリング間隔で、実行中のジョブにチケットを再割り当てする場合もあります。
チケットは、3 つのポリシーに重みを与えます。たとえば、機能ポリシーにチケットが割り当てられていない場合、そのポリシーは使用されません。機能チケットプールと共有ベースチケットプールに同じ数のチケットがある場合、ジョブの重要性を決定する際、両方のポリシーは等しい重みを持ちます。
チケットは、Grid Engine システム管理者によるシステム構成で、定期ポリシーに割り当てられます。管理者とオペレータは任意の時点でチケットの割り当てを変更でき、この変更はただちに効力を持ちます。優先を指示するには、システムに一時的に追加チケットを注入します。ポリシーはチケットの割り当てによって組み合わせられます。複数のポリシーにチケットが割り当てられている場合、ジョブは各ポリシーのチケットの一部を受け取ります。このことは、有効な各ポリシーにおけるジョブの重要性を示します。
Grid Engine システムは、システムに入るジョブにチケットを付与することによって、有効な各ポリシーにおけるその重要性を指示します。各スケジューリング間隔で、実行中の各ジョブはチケットを取得したり、チケットを失ったり、また同じ数のチケットを維持することができます。たとえば、ジョブは優先からチケットを取得する場合があります。ジョブは、正当なリソースの配分以上のチケットを取得しているため、チケットを失う場合があります。ジョブが保持するチケット数は、 Grid Engine システムが各スケジューリング間隔時にそのジョブに付与しようとするリソース配分を表します。
インストール時には、サイトの動的リソース管理戦略を構成します。まず、管理者は共有ベースポリシーと機能ポリシーにチケットを割り当てます。続いて、共有ツリーと機能配分を定義します。共有ベースチケットの割り当てと機能チケットの割り当ては、任意の時点で自動的に変更できます。管理者は、手動でチケットを割り当てたり、削除したりします。
Grid Engine システムがキューを埋める順番を決定するために、次の手段が用意されています。
負荷レポート。 管理者は、ホストの負荷状態とそのキューインスタンスを比較するためにどの負荷パラメータを使用するかを選択できます。使用可能な幅広い標準的な負荷パラメータ、およびサイト固有の負荷センサーを使用してこのセットを拡張するためのインタフェースは、「負荷パラメータ」で説明されています。
負荷スケーリング。さまざまなホストからの負荷レポートを正規化して、負荷状況を比較できるようにします。「QMON を使用した実行ホストの構成」を参照してください。
負荷調整。ホストにジョブを振り分けたときに、前回報告された負荷を Grid Engine ソフトウェアが自動的に修正するよう構成することができます。修正された負荷は、最近のジョブの実行開始で発生すると予想される負荷状況の増加を表します。この人為的に増加された負荷は、それらのジョブの負荷に対する影響が明らかになると、自動的に減少させることができます。
Grid Engine システムがジョブの振り分けを開始する前、ジョブは優先順位の高い順に、優先順位に組み入れられます。続いてシステムは、優先順位の順番でジョブに適したリソースを見つけようとします。
管理者の操作がなければ、順序は先入れ先出し (FIFO) です。管理者には、ジョブの順序を制御する次の手段があります。
チケットに基づくジョブ優先順位。ジョブは常に、ジョブが有するチケットの数により定義される相対的な重要性にしたがって扱われます。保留中のジョブはチケット順にソートされます。管理者がチケットポリシーに適用するすべての変更は、ソート順も変更します。
緊急度に基づくジョブ優先順位。ジョブには、その相対的な重要性を決定する緊急度の値を割り当てることができます。保留中のジョブは、緊急度の値に従ってソートされます。緊急度ポリシーに適用されるすべての変更により、ソート順序も変更されます。
POSIX 優先順位。 qsub コマンドに –p オプションを使用すると、サイト固有の優先順位ポリシーを実現できます。–p オプションにより、–1023 から 1024 の範囲の優先順位が指定されます。数字が大きければ、優先順位も高くなります。 ジョブのデフォルトの優先順位はゼロです。
ユーザーまたはユーザーグループジョブの最大数。ユーザーまたは UNIX ユーザーグループが並行して実行可能なジョブの最大数を制限できます。制限を超えていないユーザーのジョブは優先されるため、この制限は保留中のジョブリストのソート順序に影響します。
各優先順位の種類に対して、重み付け係数を指定できます。この重み付け係数は、各種類の優先順位がジョブ全般の優先順位に影響を与える程度を決定します。各優先順位の種類の値の範囲を制御しやすくするため、生のチケットの値、緊急度の値、および POSIX 優先順位の値の代わりに、正規化された値が使用されます。
ジョブの優先順位値がどのように決定されるかは、次の式で表されます。
job_priority = weight_urgency * normalized_urgency_value + weight_ticket * normalized_ticket_value + weight_priority * normalized_POSIX_priority_value |
ジョブの優先順位の監視には qstat コマンドを使用できます。
POSIX 優先順位を含む、ジョブ優先順位全般を監視するには、qstat –pri を使用します。
チケットポリシーに基づいてジョブ優先順位を監視するには、qstat –ext を使用します。
緊急度ポリシーに基づいてジョブ優先順位を監視するには、qstat –urg を使用します。
緊急度ポリシー、チケットに基づくポリシー、および-p <priority> を同時に使用した場合のジョブの優先順位に関する問題を診断するには、qstat –pri を使用します。
エラー状態に基づいてさまざまなキューインスタンスを診断するには、qstat –explain を使用します。
緊急度ポリシーは各ジョブの緊急度の値を定義します。緊急度の値は、次の 3 つの情報の合計から得られます。
リソース要求の情報
待機時間の情報
締め切りの情報
リソース要求の情報は、すべてのハードリソースの要求の合計から得られ、各要求に関する 1 つの加数になります。
リソース要求が型 numeric である場合、リソース要求の加数は、次の 3 つの要素の積になります。
コンプレックスで定義されているリソースの緊急度の値。詳細については、「QMON を使用したコンプレックスリソース属性の構成」を参照してください。
ジョブの、想定されているスロット割り当て。
qsub –l コマンドにより指定されるスロットごとの要求。
リソース要求が型 string である場合、リソース要求の加数は、コンプレックスで定義されているリソースの緊急度の値になります。
待機時間の情報は、秒単位でのジョブの待機時間と、「Policy Configuration」ダイアログボックスで指定されている waiting-weight 値の積になります。
締め切りの情報は、締め切りのないジョブではゼロになります。締め切りのあるジョブの場合、締め切りの情報は、(締め切り開始時間までの) 秒単位の空き時間で除算された、「Policy Configuration」ダイアログボックスで定義されている waiting-weight 値です。
緊急度ポリシーの構成の詳細については、「緊急度ポリシーの構成」を参照してください。
リソース予約を使用すると、指定した保留中のジョブに、システムリソースを予約できます。ジョブに対してリソースを予約する場合、このようなリソースは優先順位の低いジョブには使用されません。
リソース要求、ジョブ優先順位、待機時間、リソース配分エンタイトルメントなどの基準に応じて、ジョブはリソースを予約できます。最も優先順位の高いジョブが一番早く使用可能なリソース割り当てを取得するよう、スケジューラは予約を強制します。これにより、「ジョブ枯渇」というよく知られた問題を回避できます。
リソース予約を使用すると、ジョブ優先順位の順序でリソースがジョブに振り分けられるようにすることができます。
次の例を考えます。ジョブ A はサイズの大きな保留中のジョブで、並列ジョブの可能性もあり、特定のリソースを大量に必要とします。比較的小さなジョブ B(i) のストリームは、同じリソースを必要としますが、比較的少量です。リソース予約がなければ、B(i) ジョブのストリームが停止しないという前提では、ジョブ A に対するリソース割り当てを保証できません。ジョブ A が B(i) ジョブよりも高い優先順位を持っている場合であっても、リソースを保証できません。
リソース予約により、ジョブ A は、低優先順位ジョブ B(i) をブロックする予約を取得します。可能なかぎり早い段階で、リソースはジョブ A に使用できるよう保証されます。
バックフィリングを使用すると、低優先順位ジョブは、リソース予約によりブロックされたリソースを使用できるようになります。バックフィリングが機能するのは、見込みの実行時間が十分短いため、元の予約に干渉することなくブロックされたリソースを使用できる、実行可能なジョブが存在する場合のみです。
上記の例では、期間が非常に短いジョブ C は、バックフィリングを使用してジョブ A の前に実行可能です。
リソース予約によりスケジューラはルックアヘッドを行うため、リソース予約を使用するとシステムのパフォーマンスに影響を与えます。小規模なクラスタでは、保留中のジョブがごく少数である場合、パフォーマンスへの影響は無視できる程度です。ただし、大規模なクラスタでは、多くの保留中のジョブがあるクラスタであれば、パフォーマンスへの影響は大きくなる場合があります。
発生しうるこのパフォーマンスの低下を相殺するために、スケジューリング間隔中に作成可能なリソース予約の総数を制限することができます。リソース予約は次の 2 つの方法で制限できます。
スケジューリング間隔時に作成可能な予約の絶対数を制限するには、「Scheduler Configuration」ダイアログボックスで Maximum Reservation パラメータを設定します。たとえば、Maximum Reservation を 20 に設定した場合、間隔内では 20 までの予約しか作成できません。
重要なジョブに対してのみ予約スケジューリングを制限するには、qsub コマンドの –R y オプションを使用します。上記の例では、ジョブ A のリソース予約を保証するためには B(i) ジョブをスケジュールする必要はありません。–R y オプションを使用して発行しなければならないジョブは、ジョブ A だけです。
スケジューラを構成して、スケジューラがリソース予約によりどのような影響を受けるかを監視することができます。スケジューラを監視する場合は、各スケジューリング実行に関する情報はファイル sge-root/ cell/common/schedule に記録されます。
次の例に、スケジュール監視の実行内容を示します。グローバル license の消費可能リソースが 5 ライセンスに制限されているクラスタに、次のジョブのシーケンスが発行されると仮定します。
qsub -N L4_RR -R y -l h_rt=30,license=4 -p 100 $SGE_ROOT/examples/jobs/sleeper.sh 20 qsub -N L5_RR -R y -l h_rt-30,license=5 $SGE_ROOT/examples/jobs/sleeper.sh 20 qsub -N L1_RR -R y -l h_rt=31,license=1 $SGE_ROOT/examples/jobs/sleeper.sh 20 |
スケジューラ構成では、デフォルトの優先順位設定が使用されると仮定します。
weight_priority 1.000000 weight_urgency 0.100000 weight_ticket 0.010000 |
ジョブ L4_RR の –p 100 の優先順位は、ライセンスに基づく緊急度に取って代わるため、次の優先順位付けが行われます。
job-ID prior name --------------------- 3127 1.08000 L4_RR 3128 0.10500 L5_RR 3129 0.00500 L1_RR |
この場合、6 つのスケジュール間隔で、これらのジョブのトレースが schedule ファイルに見つかります。
:::::::: 3127:1:STARTING:1077903416:30:G:global:license:4.000000 3127:1:STARTING:1077903416:30:Q:all.q@carc:slots:1.000000 3128:1:RESERVING:1077903446:30:G:global:license:5.000000 3128:1:RESERVING:1077903446:30:Q:all.q@bilbur:slots:1.000000 3129:1:RESERVING:1077903476:31:G:global:license:1.000000 3129:1:RESERVING:1077903476:31:Q:all.q@es-ergb01-01:slots:1.000000 :::::::: 3127:1:RUNNING:1077903416:30:G:global:license:4.000000 3127:1:RUNNING:1077903416:30:Q:all.q@carc:slots:1.000000 3128:1:RESERVING:1077903446:30:G:global:license:5.000000 3128:1:RESERVING:1077903446:30:Q:all.q@es-ergb01-01:slots:1.000000 3129:1:RESERVING:1077903476:31:G:global:license:1.000000 3129:1:RESERVING:1077903476:31:Q:all.q@es-ergb01-01:slots:1.000000 :::::::: 3128:1:STARTING:1077903448:30:G:global:license:5.000000 3128:1:STARTING:1077903448:30:Q:all.q@carc:slots:1.000000 3129:1:RESERVING:1077903478:31:G:global:license:1.000000 3129:1:RESERVING:1077903478:31:Q:all.q@bilbur:slots:1.000000 :::::::: 3128:1:RUNNING:1077903448:30:G:global:license:5.000000 3128:1:RUNNING:1077903448:30:Q:all.q@carc:slots:1.000000 3129:1:RESERVING:1077903478:31:G:global:license:1.000000 3129:1:RESERVING:1077903478:31:Q:all.q@es-ergb01-01:slots:1.000000 :::::::: 3129:1:STARTING:1077903480:31:G:global:license:1.000000 3129:1:STARTING:1077903480:31:Q:all.q@carc:slots:1.000000 :::::::: 3129:1:RUNNING:1077903480:31:G:global:license:1.000000 3129:1:RUNNING:1077903480:31:Q:all.q@carc:slots:1.000000 |
スケジュール間隔に関して、各セクションでは、考慮されたすべてのリソース利用量が示されます。RUNNING エントリは、間隔の開始時点ですでに実行中であったジョブの利用量を示しています。STARTING エントリは、間隔内で決定された即時の利用量を示しています。RESERVING エントリは、将来計画されている使用、つまり予約を示しています。
スケジュールファイルの書式は次のとおりです。
ジョブ ID
配列タスク ID (通常のジョブの場合は 1)
RUNNING、SUSPENDED、 MIGRATING、STARTING、RESERVING を取ります
1.1.1070 以降の秒単位での開始時刻
想定されている秒単位でのジョブの継続時間
P (並列環境の場合)、G (グローバルの場合)、H (ホストの場合)、または Q (キューの場合) を取ります
並列環境、ホスト、またはキューの名前
消費可能リソースの名前
そのジョブにより発生するリソース使用率
行 :::::::: は、新しいスケジュール間隔の開始のマークとなります。
schedule ファイルは、切り捨てられません。ファイルを切り捨てるように設定されている自動手続きがない場合は、必ず監視をオフにしてください。
スケジューラは、間隔での作業をスケジューリングします。スケジューリングアクションの間、Grid Engine システムは次の要素などの、重要なイベントに関する情報を保持します。
ジョブの発行
ジョブの完了
ジョブの取り消し
クラスタ構成の更新
クラスタでの新しいマシンの登録
スケジューリングが行われる際には、スケジューラはまず次の処理を実行します。
すべての重要なイベントの考慮
管理者の指定に従ったジョブとキューのソート
すべてのジョブのリソース要求の考慮
将来に備えたスケジュールでのジョブに関するリソースの予約
必要に応じて、Grid Engine システムは次のタスクを実行します。
新しいジョブの振り分け
実行中のジョブの一時停止
実行中のジョブに割り当てられているリソースの増減
現状の維持
共有ベーススケジューリングが使用されている場合、そのユーザーまたはプロジェクトに対してすでに発生している利用量が、計算では考慮されます。
少なくとも一部でもスケジューリングが共有ベーススケジューリングでない場合は、計算では実行中および実行待ちのすべてのジョブがランク付けされます。クラスタ内のリソース (CPU、メモリー、および I/O 帯域幅) が可能なかぎり使用されるようになるまで、計算では最も重要なジョブが処理されます。
ジョブが開始しない理由が不明である場合、そのジョブに対して qalter -w v コマンドを発行します。Grid Engine ソフトウェアでは、クラスタが空であることが仮定されていて、またジョブに適したキューが使用可能であるかどうかチェックされます。
詳細な情報は、qstat -j job-id コマンドを実行することで取得できます。このコマンドは、ジョブの要求プロファイルの要約を出力します。要約には、前回のスケジューリング実行でジョブがスケジューリングされなかった理由も含まれます。ジョブ ID を使用せずに qstat -j コマンドを実行すると、前回のスケジューリング間隔でスケジューリングされなかったすべてのジョブに関する理由が要約されます。
スケジューラ構成 sched_conf(5) では、ジョブスケジューリング情報の収集をオンにする必要があります。sched_conf(5) のマニュアルページの schedd_job_info パラメータの説明、または 「QMON を使用したスケジューラ構成の変更」を参照してください。
スケジューラ sge_schedd の決定に関する詳細な情報を取得するには、qconf コマンドの -tsm オプションを使用します。このコマンドを使用すると、sge_schedd は強制的にファイルにトレース出力を書き込みます。
Grid Engine システムのリソース共有ポリシーのスケジューリング管理の詳細については、「QMON を使用したポリシーに基づくリソース管理の構成」を参照してください。次の節では、スケジューラ構成 sched_conf の管理とそれに関連する問題に焦点を当てます。
デフォルトのスケジューリングは、FIFO 方式です。すなわち、最初に発行されたジョブが、最初にスケジューラによって調べられ、キューに振り分けられます。保留中のジョブのリストの最初のジョブが、適切で使用可能なジョブを見つけると、そのジョブがまず開始されます。最初のジョブよりも下位のランクのジョブが開始できるのは、最初のジョブが適切な空きリソースを見つけられなかった場合のみです。
デフォルト戦略では、ジョブのリソース要求に対してキューが適切なサービスを提供するかぎり、最も負荷の低いホスト上のキューインスタンスを選択します。複数の適切なキューが同じ負荷を共有する場合、どのキューが選択されるか予測できません。
次のようなさまざまな方法で、ジョブのスケジューリングとキュー選択の戦略を変更できます。
スケジューリングアルゴリズムの変更
システム負荷のスケーリング
連続番号によるキューの選択
配分によるキューの選択
ユーザー 1 人またはグループ 1 つあたりのジョブ数の制限
次では、これらの代替方法を詳しく説明します。
スケジューラ構成パラメータ algorithm は、使用するスケジューリングアルゴリズムを選択できるようにします。詳細については、sched_conf(5) のマニュアルページを参照してください。ただし、現在指定できる設定は default だけです。
ジョブを実行するキューを選択するため、Grid Engine システムは、キューインスタンスをホスティングするマシンのシステム負荷情報を使用します。このキュー選択方式によって負荷分散状態が確立され、クラスタ内の使用可能なリソースの有効利用が保証されます。
ただし、システム負荷が常に真実を伝えるとはかぎりません。たとえば複数 CPU のマシンとシングル CPU のシステムを比較すると、通常、多くの場合マルチプロセッサシステムの方が実行しているプロセス数が多いため、マルチプロセッサシステムが報告する負荷値の方が大きくなります。システム負荷は、CPU へのアクセス権を取得しようとするプロセス数に大きく左右される測定値です。しかし、複数 CPU システムは、シングル CPU マシンに比べてはるかに大きな負荷に対処することができます。この問題は、sge_execd からデフォルトで報告される負荷値をプロセッサ数で調整することによって対処します。すなわち、生の負荷値ではなく、負荷パラメータを使用することによって、上記の問題に対処することができます。詳細については、「負荷パラメータ」 および sge-root/doc/load_parameters.asc ファイルを参照してください。
負荷値が正しく判断されない可能性があるもう 1 つの例として、システムで潜在的なパフォーマンスあるいは価格パフォーマンス比に著しい差がある場合があります。どちらの場合も、負荷値が同じであるからといって、ジョブの実行用にどちらのホストを選択してもよいわけではありません。こうした場合、管理者は、実行ホストと負荷パラメータに対する負荷スケーリング係数を定義する必要があります。「QMON を使用した実行ホストの構成」および関連の節を参照してください。
スケーリングした負荷パラメータは、負荷しきい値リストの load-thresholds および migr-load-thresholds とも照合されます。詳細については、queue_conf(5) のマニュアルページを参照してください。
負荷パラメータに関連するもう 1 つの問題は、値とその相対的な重要性を、アプリケーションおよびサイトに依存して解釈する必要があることです。特定のサイトで一般的なある種のアプリケーションでは CPU 負荷が圧倒的であるのに対し、別のサイトや、サイトの計算クラスタが専門に扱うアプリケーションプロファイルでは、メモリー負荷がずっと重要であることがあります。この問題に対処するため、Grid Engine システムでは、管理者はスケジューラ構成ファイル sched_conf で負荷の式を指定できます。詳細については、sched_conf(5) のマニュアルページを参照してください。負荷の式でサイト定義の負荷パラメータと消費可能リソースを使用することによって、リソース使用率と容量計画に関するサイト固有の情報を考慮することができます。「サイト固有の負荷パラメータの追加」および 「消費可能リソース」の各節を参照してください。
最後に、負荷パラメータの時間依存も考慮する必要があります。システムで実行中のジョブによって課される負荷は時間とともに変化します。しばしば、CPU 負荷などの負荷は、オペレーティングシステムが適切な報告するのにかなりの時間が必要になることがあります。ジョブの開始直後の場合、報告される負荷は、ジョブによってホストに課されている負荷を正確に表していないことがあります。報告される負荷は時間とともに実際の負荷に近づいていきます。しかし、報告される負荷が低すぎる間は、そのホストが過剰な予約を受ける可能性があります。Grid Engine システムでは、管理者は、スケジューラでこの問題の補正に使用される負荷調整係数を指定することができます。このような負荷調整係数の設定方法の詳細については、sched_conf(5) のマニュアルページを参照してください。
負荷調整は、ジョブが振り分けられたあとに、測定される負荷を仮想的に増加させるために使用します。過剰な予約が発生したマシンの場合、これは負荷しきい値との調整に役立ちます。負荷調整が必要でない場合は、負荷調整をオフにする必要があります。負荷調整は、ホストのソートと負荷しきい値の検証を伴って、スケジューラに追加の作業を課すことになります。
負荷調整を使用不可にするには、「Scheduler Configuration」ダイアログボックスの「Load Adjustment」でタブで「Decay Time」をゼロに設定し、テーブル内のすべての負荷調整の値を削除します。「QMON を使用したスケジューラ構成の変更」を参照してください。
デフォルトのキュー選択方法を変更するもう 1 つの方法は、グローバルクラスタ構成パラメータqueue_sort_method をデフォルトの load から seq_no に変更する方法です。この設定にすると、キュー選択の第一の手段としてシステム負荷が使用されなくなります。その代わりに、キュー構成パラメータ seq_no によりキューに割り当てられた連続番号が、キュー選択の固定順序を定義します。キューは、検討対象のジョブに適切で、使用可能である必要があります。詳細については、queue_conf(5) および sched_conf (5) のマニュアルページを参照してください。
このキュー選択方法は、サイトでバッチサービスを提供するマシンが、ジョブ 1 つあたりの単純な価格の順序でランク付けされている場合に役立ちます。たとえば、マシン A であるジョブを実行すると 1 単位のコストがかかるとします。同じジョブは、マシン B では 10 単位、マシン C では 100 単位のコストがかかります。この場合の望ましいスケジューリング方法は、最初にホスト A を一杯にして、次にホスト B、そして代わりが残っていない場合だけホスト C を使用するという方法です。
キュー選択方法を seq_no に変更して、検討対象のすべてのキューの連続番号が同じ場合、キューはデフォルトの load により選択されます。
この方法の目標は、すべてのジョブに対して目標とするグロバールシステムリソース配分が達成されるようにジョブを配置することにあります。この方法では、すべてのシステムリソースとの関係で各ホストが表すリソース容量を考慮します。またこの方法では、各ホストのチケットの割合 (すなわち、ホストで実行中のすべてのジョブの総チケット数) と、特定のホストがシステムに対して表すリソース能力の割合のバランスを取ろうとします。ホストの容量の定義方法については、「QMON を使用した実行ホストの構成」を参照してください。
重要性は二次的なものとなりますが、ソートではホストの負荷も考慮されます。共有ツリーポリシーを使用しているサイトでは、このソート方法を選択してください。
管理者は、ユーザーまたは UNIX グループが任意の時点で実行できるジョブ数に上限を割り当てることができます。この機能を使用するには、次のいずれかを実行します。
sched_conf(5) のマニュアルページで説明されているように、maxujobs か maxgjobs、またはその両方を設定します。
「Scheduler Configuration」ダイアログボックスの「General Parameters」タブで、「Max Jobs/User」フィールドを使用して、ユーザーまたはユーザーグループが並行して実行できるジョブの最大数を設定します。
「QMON Main Control」ウィンドウで、「Scheduler Configuration」ボタンをクリックします。
「Scheduler Configuration」ダイアログボックスが表示されます。このダイアログには、2 つのタブがあります。
「General Parameters」タブ
「Load Adjustment」タブ
一般的なスケジューリングパラメータを変更するには、「General Parameters」タブをクリックします。「General Parameters」タブは次の図のようになっています。
「General Parameters」タブを使用して、次のパラメータを設定します。
Algorithm。スケジューリングアルゴリズムです。「スケジューリングアルゴリズムの変更」を参照してください。
Schedule Interval。スケジューラ実行の定期的な時間間隔です。
Reprioritize Interval。ジョブを実行するための現在のチケット量に基づき、実行ホストに対してジョブの優先順位を再決定する定期的な時間間隔です。優先順位を再決定しない場合は、このパラメータをゼロに設定します。
Max Jobs/User。1 人のユーザーおよび 1 つの UNIX グループにつき並行して実行可能なジョブの最大数です。「ユーザー 1 人またはグループ 1 つあたりのジョブ数の制限」を参照してください。
Sort by。負荷によるソート、または連続番号によるソートの、キューソート方法。「連続番号によるキューの選択」を参照してください。
Job Scheduling Information。qstat -j によりジョブスケジューリング情報へアクセス可能であるかどうか、またはジョブ ID 範囲に関してのみこの情報が収集されるかどうかを指定します。ジョブスケジューリング情報の一般的な収集は、保留中のジョブ数がきわめて多い場合にのみ一時的に使用してください。
スケジューラ監視は、一部のジョブが振り分けられない理由を調べるのに役立ちます。ただし、すべてのジョブに関してこの情報を常に提供すると、リソースを消費することがあります。通常、このような情報は必要ありません。
Load Formula。ホストとキューをソートするために使用する負荷の式です。
Flush Submit Seconds。ジョブが発行されてから、スケジューラがトリガーされるまで、スケジューラが待機する秒数です。ジョブが発行されたあとのフラッシュを使用不可にするには、このパラメータをゼロに設定します。
Flush Finish Seconds。ジョブが完了してから、スケジューラがトリガーされるまで、スケジューラが待機する秒数です。ジョブが完了したあとのフラッシュを使用不可にするには、このパラメータをゼロに設定します。
Maximum Reservation。スケジューリング間隔内でスケジューリング可能なリソース予約の最大数です。「リソース予約およびバックフィリング」を参照してください。
Params。この設定を使用して、スケジューラに渡す追加のパラメータを指定します。Params は、PROFILE または MONITOR になります。PROFILE を指定した場合、スケジューラは各スケジューリング実行を要約したプロファイリング情報を記録します。MONITOR を指定した場合、スケジューラは各実行スケジューリングに関する情報を、ファイル sge-root/ cell/common/schedule に記録します。
デフォルトでは、Grid Engine システムは、固定スケジュール間隔でジョブ実行をスケジューリングします。「Flush Submit Seconds」および「Flush Finish Seconds」パラメータを使用すると、ただちにスケジュールを行うよう構成できます。詳細については、「直接スケジューリング」を参照してください。
負荷調整パラメータを変更するには、「Load Adjustment」タブをクリックします。「Load Adjustment」タブは次の図のようになっています。
「Load Adjustment」タブを使用して、次のパラメータを設定します。
Decay Time。負荷調整の減少時間です。
現在調整値が定義されているすべての負荷および消費可能属性を一覧表示する、負荷調整値のテーブルです。
リストに負荷値を追加するには、「Load」または「Value」カラムヘッダーをクリックします。ホストに関連付けられているすべてのリソース属性とともに、選択リストが表示されます。
図 1–2 に「Attribute Selection」ダイアログボックスを示します。「Consumable/Fixed Attributes」テーブルの「Load」カラムにリソース属性を追加するには、いずれかの属性を選択してから「OK」をクリックします。
既存の値を変更するには、「Value」フィールドをダブルクリックします。
リソース属性を削除するには、属性を選択してから Control + D キーを押すか、マウスボタン 3 をクリックします。削除を確認するダイアログボックスが表示されます。
内容説明については、「システム負荷のスケーリング」を参照してください。スケジューラ構成の詳細については、sched_conf(5) のマニュアルページを参照してください。