第 8 章 公平配分スケジューラ (概要)

作業負荷データを解析することによって、特定の作業負荷または作業負荷のグループが CPU 資源を占有しているかどうかを判定できます。作業負荷が CPU 使用量の制限を超えていない場合は、システム上での CPU 時間の割り当て方針を変更することができます。この章で説明する公平配分スケジューリングクラスを使用すると、タイムシェアリング (TS) スケジューリングクラスの優先順位方式ではなく、配分に基づいて CPU 時間を割り当てることができます。

この章の内容は次のとおりです。

• 「スケジューラの紹介」

• 「CPU 配分の定義」

• 「CPU 配分とプロセスの状態」

• 「CPU 配分と使用率」

• 「CPU 配分の例」

• 「FSS の構成」

• 「FSS とプロセッサセット」

• 「FSS とほかのスケジューリングクラスの併用」

• 「システムのスケジューリングクラスの設定」

• 「ゾーンがインストールされているシステムでのスケジューリングクラス」

• 「FSS で使用するコマンド」

公平配分スケジューラの使用を開始する方法については、第 9 章公平配分スケジューラの管理 (手順)を参照してください。

スケジューラの紹介

オペレーティングシステムの基本的な仕事は、どのプロセスがシステム資源へのアクセスを取得できるようにするか調整することです。プロセススケジューラ (別名、ディスパッチャー) は、カーネルの一部であり、プロセスへの CPU の割り当てを制御します。スケジューラには、スケジューリングクラスという概念があります。各スケジューリングクラスでは、クラス内のプロセスのスケジューリングに使用するスケジューリング方針を定義します。TS スケジューラは Solaris オペレーティングシステムにおけるデフォルトのスケジューラであり、使用可能な CPU へのアクセスをすべてのプロセスに相対的に等しく与えます。ただし、特定のプロセスにより多くの資源を与えたい場合もあります。

公平配分スケジューラ (FSS) では、各作業負荷に対する使用可能な CPU 資源の割り当てを、その作業負荷の重要性に基づいて制御します。この重要性は、各作業負荷に割り当てる CPU 資源の「配分」で表します。

各プロジェクトに CPU 配分を与えて、CPU 資源に対するプロジェクトの使用権を制御します。FSS では、プロジェクトに属するプロセス数ではなく、割り当てられた配分に基づいて、プロジェクト間に CPU 資源が公平に配分されることが保証されています。FSS は、ほかのプロジェクトとの比較に基づいて、CPU 資源を多く使用するプロジェクトの CPU 使用権を減らし、CPU 資源の使用が少ないプロジェクトの CPU 使用権を増やすことで公平さを実現します。

FSS は、カーネルスケジューリングクラスモジュールとクラス固有のバージョンの dispadmin(1M) および priocntl(1) コマンドから構成されます。FSS が使用するプロジェクト配分は、project(4) データベース内の project.cpu-shares プロパティーで指定します。

ゾーンがインストールされているシステムで project.cpu-shares 資源制御を使用する場合は、「ゾーン構成データ」、「非大域ゾーンで使用される資源制御」、および 「ゾーンがインストールされている Solaris システムでの公平配分スケジューラの使用」を参照してください。

CPU 配分の定義

「配分」という用語は、プロジェクトに割り当てられる CPU 資源の配分を定義するために使用されます。プロジェクトに割り当てる CPU 配分をほかのプロジェクトよりも多くすると、そのプロジェクトが公平配分スケジューラから受け取る CPU 資源も多くなります。

CPU 配分は、CPU 資源の比率ではありません。配分は、ほかの作業負荷との比較に基づいた作業負荷の相対的な重要性を定義します。プロジェクトに CPU 配分を割り当てる場合に重要なことは、プロジェクトが持つ配分自体ではありません。ほかのプロジェクトと比較して、そのプロジェクトが配分をいくつ持っているかを把握することが重要です。また、そのプロジェクトが CPU 資源について、ほかのいくつのプロジェクトと競合しているかということも考慮に入れる必要があります。

配分がゼロのプロジェクトに属するプロセスは、常に最下位のシステム優先順位 (0) で実行されます。このようなプロセスが実行されるのは、配分がゼロでないプロジェクトが CPU 資源を使用していないときだけです。

CPU 配分とプロセスの状態

Solaris システムでは、プロジェクトの作業負荷は一般に複数のプロセスから構成されます。公平配分スケジューラの観点からは、各プロジェクトの作業負荷は、「アイドル」状態か「アクティブ」状態のどちらかです。プロジェクトのどのプロセスも CPU 資源を使用していないとき、プロジェクトはアイドル状態であるといいます。このような場合、プロセスは一般にスリープ (入出力の完了を待機している状態) または停止状態にあります。プロジェクトの 1 つ以上のプロセスが CPU 資源を使用しているとき、プロジェクトはアクティブ状態であるといいます。すべてのアクティブなプロジェクトが持つ配分の合計が、プロジェクトに割り当てられる CPU 資源の配分の計算に使用されます。

アクティブなプロジェクトが増えると、各プロジェクトの CPU 割り当ては減りますが、プロジェクト間の CPU 割り当て比率は変わりません。

CPU 配分と使用率

配分割り当ては、使用率とは異なります。CPU 資源の 50% が割り当てられているプロジェクトの CPU 使用率は、平均するとわずか 20% ほどです。その上、配分が CPU 使用量を制限するのは、ほかのプロジェクトと競合するときだけです。プロジェクトに対する割り当てが低い場合でも、そのプロジェクトがシステムで単独に実行されているときは、常に 100% の処理能力を CPU から受け取ります。使用可能な CPU サイクルが浪費されることはありません。つまり、使用可能な CPU サイクルはプロジェクト間に配分されます。

動作中の作業負荷に小さい配分を割り当てると、性能が低下します。ただし、システムが過負荷にならないかぎり、配分割り当て数が原因で作業が完了しないことはありません。

CPU 配分の例

2 つの CPU を搭載したシステムがあり、それらの CPU は CPU にバインドされた 2 つの作業負荷 A および B を並列に実行しているとします。各作業負荷は別個のプロジェクトとして実行されています。各プロジェクトは、プロジェクト A に S_A 配分が割り当てられ、プロジェクト B に S_B 配分が割り当てられるように構成されています。

従来の TS スケジューラを使用した場合、システムで実行されている各作業負荷には、平均して同じ量の CPU 資源が与えられます。つまり、各作業負荷にはシステム容量の 50% が割り当てられます。

FSS スケジューラの制御で実行する場合でも、S _A = S_B の配分を割り当てると、各プロジェクトにほぼ等量の CPU 資源が与えられます。これに対して、プロジェクトに異なる配分を与えた場合、CPU 資源の割り当て量は異なります。

次に示す 3 つの例は、さまざまな構成での配分の働きを示しています。これらの例に示されているとおり、配分は、要求が使用可能な資源量と同じまたはそれを超えている場合にのみ使用量を数学的に正確に表します。

例 1: CPU にバインドされた 2 つの プロセスが各プロジェクトに存在する場合

プロジェクト A と B がそれぞれ CPU に結合されたプロセスを 2 つ持ち、かつ S _A = 1、S _B = 3 である場合、配分の合計数は 1 + 3 = 4 になります。この構成で、十分な数の CPU 要求があると、A と B には、それぞれ CPU 資源の 25%、75% が割り当てられます。

例 2: プロジェクト間に競合がない場合

プロジェクト A と B がそれぞれ CPU に結合されたプロセスを「1 つ」だけ持ち、かつ S _A = 1、S _B = 100 である場合、配分の合計数は 101 になります。各プロジェクトは、実行中のプロセスを 1 つしか持たないため、CPU を 1 つしか使用できません。この構成では、CPU 資源を得るための競合がプロジェクト間に存在しないので、プロジェクト A および B には、それぞれ全 CPU 資源の 50% が割り当てられます。この構成の場合、CPU 配分は CPU 資源の割り当てに影響しません。プロジェクトへの割り当ては同じ (50/50) になります。これは、両方のプロジェクトに割り当てられる配分がゼロの場合でも同様です。

例 3: 一方のプロジェクトが実行されない場合

プロジェクト A と B がそれぞれ CPU に結合されたプロセスを 2 つ持ち、かつ A に 1 配分、B に 0 配分が与えられている場合、プロジェクト B には CPU 資源がまったく割り当てられず、プロジェクト A にすべての CPU 資源が割り当てられます。プロジェクト B のプロセスは常にシステム優先順位 0 で実行されるため、実行される可能性はまったくありません。これは、プロジェクト A のプロセスの方が常に高い優先順位を持っているためです。

FSS の構成

プロジェクトとユーザー

プロジェクトは、FSS スケジューラの作業負荷コンテナです。プロジェクトに割り当てられているユーザーのグループは、個別の管理可能なブロックとして扱われます。個人ユーザー用に独自の配分を持つプロジェクトを作成できます。

ユーザーは、異なる配分が割り当てられているさまざまなプロジェクトのメンバーになることができます。プロセスをあるプロジェクトから別のプロジェクトに移動すると、プロセスに割り当てられる CPU 資源量は変化します。

project(4) データベースとネームサービスの詳細については、「project データベース」を参照してください。

CPU 配分の構成

CPU 配分の構成は project データベースのプロパティーとして、ネームサービスによって管理されます。

プロジェクトに関連付けられている最初のタスクまたはプロセスが setproject(3PROJECT) ライブラリ関数を使って作成されると、project データベース内で資源制御 project.cpu-shares として定義されている CPU 配分がカーネルに渡されます。資源制御 project.cpu-shares が定義されていないプロジェクトには、1 配分が割り当てられます。

次の例では、/etc/project ファイル内のこのエントリでプロジェクト x-files の配分に 5 が設定されています。

x-files:100::::project.cpu-shares=(privileged,5,none)

プロジェクトに割り当てられている CPU 配分を、プロセスの実行中にデータベースで変更しても、プロジェクトの配分は、その時点では変更されません。変更内容を有効にするには、プロジェクトを再起動する必要があります。

project データベース内のプロジェクトの属性を変更することなくプロジェクトに割り当てられている配分を一時的に変更するには、prctl コマンドを使用します。たとえば、x-files プロジェクトに関連付けられているプロセスの実行中に、そのプロジェクトの資源制御 project.cpu-shares の値を 3 に変更するには、次のように入力します。

# prctl -r -n project.cpu-shares -v 3 -i project x-files

詳細は、prctl(1) のマニュアルページを参照してください。

-r

指定された資源制御の現在の値を置き換えます。

-n name

資源制御の名前を指定します。

-v val

資源制御の値を指定します。

-i idtype

ID タイプを指定します。

x-files

変更対象を指定します。この例では、プロジェクト x-files が変更対象です。

プロジェクト ID 0 のプロジェクト system には、起動時の初期化スクリプトで起動されるすべてのシステムデーモンが含まれます。system は、無制限の配分を持つプロジェクトとしてみなされます。したがって、プロジェクト system は、ほかのプロジェクトに与えられている配分とは関係なく、常に最初にスケジュールされます。プロジェクト system に無制限の配分を割り当てない場合は、project データベースでこのプロジェクトの配分を変更します。

前述のように、配分がゼロのプロジェクトに属するプロセスには、常にシステム優先順位 0 が与えられます。配分が 1 以上のプロジェクトは、優先順位 1 以上で実行されます。したがって、配分がゼロのプロジェクトは、ゼロ以外の配分を持つプロジェクトが CPU 資源を要求していないときにだけスケジュールされます。

1 つのプロジェクトに割り当てられる配分の最大数は 65535 です。

FSS とプロセッサセット

プロセッサセットに FSS を連携して使用すると、連携させない場合よりも、各プロセッサセット上で実行するプロジェクト間の CPU 資源の割り当てをよりきめ細かく制御できます。FSS スケジューラは、プロセッサセットを完全に独立したパーティションとして処理します。つまり、各プロセッサセットは、CPU 割り当てについてそれぞれ個別に制御されます。

1 つのプロセッサセットで実行されるプロジェクトの CPU 割り当てが、別のプロセッサセットで実行されるプロジェクトの CPU 配分や動作によって影響を受けることはありません。なぜなら、異なるプロセッサセットで実行されるプロジェクトが同じ資源について競合することはないからです。競合が発生するのは、プロジェクトが同じプロセッサセット内で実行されている場合だけです。

プロジェクトに割り当てられている配分はシステム全体に適用されます。どのプロセッサセットで実行されようと、プロジェクトの各部分には同じ配分が与えられます。

プロセッサセットが使用されている場合、プロジェクトの CPU 割り当ては、各プロセッサセット内で実行されるアクティブなプロジェクトに対して算出されます。

異なるプロセッサセット内で実行されるプロジェクトのパーティションは、異なる CPU 割り当てを持つことになります。1 つのプロセッサセット内の各プロジェクトパーティションに対する CPU 割り当ては、同じプロセッサセット内で実行されるほかのプロジェクトの割り当てにだけ依存します。

プロセッサセット境界内で実行されるアプリケーションの性能と可用性が、新しいプロセッサセットの導入によって影響を受けることはありません。また、ほかのプロセッサセットで実行されるプロジェクトの配分割り当ての変更によって、アプリケーションが影響を受けることもありません。

空のプロセッサセット (プロセッサが存在しないセット) や、プロセッサセットにバインドされたプロセスを持たないプロセッサセットは、FSS スケジューラの動作にまったく影響を与えません。

FSS とプロセッサセットの例

8 つの CPU を持つサーバーがプロジェクト A、B、および C 内で CPU にバインドされたアプリケーションをいくつか実行しているものとします。プロジェクト A には 1 配分、プロジェクト B には 2 配分、プロジェクト C には 3 配分がそれぞれ割り当てられています。

プロジェクト A は、プロセッサセット 1 だけで実行されています。プロジェクト B は、プロセッサセット 1 および 2 で実行されています。プロジェクト C は、プロセッサセット 1、2、および 3 で実行されています。各プロジェクトには、使用可能なすべての CPU 処理能力を利用するだけの十分な数のプロセスが存在しているものとします。したがって、CPU 資源を得るための競合が各プロセッサセットで常に発生します。

このようなシステムでは、システム全体でのプロジェクトの CPU 割り当ての合計は次のようになります。(pset = プロセッサセット)

これらの割合は、プロジェクトに与えられている CPU 配分値とは一致しません。ただし、各プロセッサセット内では、プロジェクトごとの CPU 割り当て比率はプロジェクトのそれぞれの配分に比例します。

このシステム上にプロセッサセットが存在しない場合、CPU 資源の配分は、次に示すように、異なったものになります。

FSS とほかのスケジューリングクラスの併用

デフォルトでは、FSS スケジューリングクラスは、タイムシェアリング (TS)、対話型 (IA)、および固定優先順位 (FX) の各スケジューリングクラスと同じ範囲の優先順位 (0 から 59) を使用します。そのため、これらのスケジューリングクラスのプロセスが同じプロセッサセットを共有しないようにする必要があります。FSS、TS、IA、および FX の各クラスにプロセスが混在すると、予期せぬスケジューリング処理が実行される場合があります。

プロセッサセットを使用する場合は、1 つのシステム内で TS、IA、および FX を FSS と混在させることができます。ただし、各プロセッサセットで実行されるすべてのプロセスは、「1 つの」スケジューリングクラスに所属している必要があります。このようにすると、これらのプロセスが同じ CPU について競合することはありません。プロセッサセットを使用しない場合は、特に FX スケジューラを FSS スケジューリングクラスと併用しないようにしてください。これにより、FX クラスのアプリケーションが高い優先順位を使用して、FSS クラスのアプリケーションの実行を妨げることはありません。

TS クラスと IA クラスのプロセスは、同じプロセッサセット内で、またはプロセッサセットが存在しない同じシステム内で混在させることができます。

Solaris システムでは、スーパーユーザー権限を持つユーザーは、リアルタイム (RT) スケジューラも利用できます。デフォルトでは、RT スケジューリングクラスは FSS とは異なる範囲のシステム優先順位 (通常は 100 から 159) を使用します。RT と FSS は「互いに素」な範囲 (重複しない範囲) の優先順位を使用しているので、FSS は同じプロセッサセット内の RT スケジューリングクラスと共存できます。ただし、FSS スケジューリングクラスは、RT クラスで実行するプロセスを制御することはできません。

たとえば、4 つのプロセッサから構成されるシステムで、CPU に結合されているシングルスレッドの RT プロセスは 1 つのプロセッサを占有できます。システムが FSS も実行している場合、通常のユーザープロセスは、RT プロセスが使用していない残りの 3 つの CPU について競合します。RT プロセスは CPU を使い続けることはありません。RT プロセスがアイドル状態になったとき、FSS は 4 つのプロセッサをすべて使用します。

次のコマンドを入力して、プロセッサセットが実行しているスケジューリングクラスを特定し、各プロセッサセットが TS、IA、FX、または FSS のプロセスのいずれかを実行するように構成されていることを確認します。

$ ps -ef -o pset,class | grep -v CLS | sort | uniq
1 FSS
1 SYS
2 TS
2 RT
3 FX

システムのスケジューリングクラスの設定

システムにデフォルトのスケジューリングクラスを設定するには、「FSS をデフォルトのスケジューラクラスにする方法」、「ゾーンのスケジューリングクラス」、および dispadmin(1M) を参照してください。実行中のプロセスを別のスケジューリングクラスに移動するには、「FSS の構成」と priocntl(1) を参照してください。

ゾーンがインストールされているシステムでのスケジューリングクラス

非大域ゾーンでは、システムのデフォルトのスケジューリングクラスが使用されます。システムのデフォルトスケジューリングクラスの設定が更新された場合、非大域ゾーンでは、起動時または再起動時にこの新しい設定が取得されます。

この場合に望ましい FSS の使用方法は、dispadmin コマンドを使用して、FSS をシステムのデフォルトのスケジューリングクラスに設定する方法です。このようにすると、すべてのゾーンがシステムの CPU 資源の公平配分を受けることができます。ゾーンが使用されている場合のスケジューリングクラスの詳細については、「ゾーンのスケジューリングクラス」を参照してください。

デフォルトのスケジューリングクラスの変更や再起動を行うことなく、実行中のプロセスを別のスケジューリングクラスに移動する方法については、表 27–5 および priocntl(1) のマニュアルページを参照してください。

FSS で使用するコマンド

次の表に示すコマンドは、公平配分スケジューラを管理するための主要なインタフェースとなります。