test

Sun N1 Grid Engine 6.1 管理ガイド

スケジューラの構成

Grid Engine システムのリソース共有ポリシーのスケジューリング管理の詳細については、「QMON を使用したポリシーに基づくリソース管理の構成」を参照してください。次の節では、スケジューラ構成 sched_conf の管理とそれに関連する問題に焦点を当てます。

デフォルトのスケジューリング

デフォルトのスケジューリングは、FIFO 方式です。すなわち、最初に発行されたジョブが、最初にスケジューラによって調べられ、キューに振り分けられます。保留中のジョブのリストの最初のジョブが、適切で使用可能なジョブを見つけると、そのジョブがまず開始されます。最初のジョブよりも下位のランクのジョブが開始できるのは、最初のジョブが適切な空きリソースを見つけられなかった場合のみです。

デフォルト戦略では、ジョブのリソース要求に対してキューが適切なサービスを提供するかぎり、最も負荷の低いホスト上のキューインスタンスを選択します。複数の適切なキューが同じ負荷を共有する場合、どのキューが選択されるか予測できません。

そのほかのスケジューリング方法

次のようなさまざまな方法で、ジョブのスケジューリングとキュー選択の戦略を変更できます。

次では、これらの代替方法を詳しく説明します。

スケジューリングアルゴリズムの変更

スケジューラ構成パラメータ 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 を使用した実行ホストの構成」を参照してください。

重要性は二次的なものとなりますが、ソートではホストの負荷も考慮されます。共有ツリーポリシーを使用しているサイトでは、このソート方法を選択してください。

ユーザー 1 人またはグループ 1 つあたりのジョブ数の制限

管理者は、ユーザーまたは UNIX グループが任意の時点で実行できるジョブ数に上限を割り当てることができます。この機能を使用するには、次のいずれかを実行します。