パート II Solaris 9 リソースマネージャ (トピック)

以下の章で、Solaris オペレーティング環境における資源管理について説明します。

第 4 章「Solaris 9 リソースマネージャの紹介」

資源管理の概要について説明し、システムに備わっている機能の利用方法について検討します。

第 5 章「プロジェクトとタスク」

プロジェクトおよびタスク機能について解説し、作業負荷にラベル付けを行い、区別する方法について説明します。

第 6 章「拡張アカウンティング」

容量計画や課金についての詳細な資源消費統計情報を取得するのに使用する拡張アカウンティング機能について説明します。

第 7 章「資源制御」

システム上で実行されるアプリケーションが使用する資源量に制限を設けるための資源制御機能について説明します。

第 8 章「フェアシェアスケジューラ」

シェアを使用して、システム上で実行されるプロセスに割り当てる CPU 時間を指定するフェアシェアスケジューラについて説明します。

第 9 章「資源上限デーモンによる物理メモリーの制御」

資源上限デーモン rcapd(1M) について説明します。このデーモンは、資源上限が定義されたプロジェクト内で動作しているプロセスが消費する物理メモリーを規制します。

第 10 章「資源プール」

システム資源を分割し、システム上で実行される特定の作業負荷に対して常に一定量の資源の使用を保証する資源プールについて説明します。

第 11 章「資源管理の構成例」

仮想的なサーバー統合プロジェクトについて説明します。

第 12 章「Solaris 管理コンソールの資源制御機能」

Solaris 管理コンソールで利用できる資源管理機能について説明します。

第 4 章 Solaris 9 リソースマネージャの紹介

資源管理機能を利用すると、アプリケーションが利用可能なシステム資源をどのように使用するかを制御できます。次のような制御が可能になります。

• プロセッサ時間などのコンピュータ資源を割り当てる

• 割り当てた資源の使用状況を監視し、必要に応じて調整する

• 分析、課金、および容量計画のために拡張アカウンティング情報を生成する

概要

今日のコンピューティング環境では、システム上で実行されるアプリケーションによって生成されるさまざまな作業負荷に柔軟に対応できる能力が求められます。資源管理機能を使用しない場合、Solaris オペレーティング環境は、新しいアプリケーションの要求に動的に適応することによって作業負荷の要求に対応しています。このデフォルトの動作は、通常、システムのすべてのアクティビティに対して資源へのアクセスを同等に与えることを意味します。Solaris の資源管理機能を使用すると、作業負荷を個別に扱うことができるようになります。次のような制御が可能になります。

• 特定の資源へのアクセスを制限する

• 優先順位に基づいて作業負荷に資源を提供する

• 作業負荷を互いに分離する

作業負荷が相互に影響し合うことによるパフォーマンスの低下を最小限に抑える機能と、資源の使用状況や使用率を監視する機能を総称して「資源管理機能」といいます。資源管理機能は、いくつかのアルゴリズムの集合として実装されます。 これらのアルゴリズムは、アプリケーションがその実行過程で発行する一連の資源要求を処理します。

資源管理機能を使用すると、さまざまな作業負荷に対してオペレーティングシステムのデフォルトの動作を変更できます。この場合の「動作」とは、主に、アプリケーションが 1 つ以上の資源要求をシステムに発行したときに、オペレーティングシステムのアルゴリズムが行う一連の決定処理のことです。 資源管理機能は、次の目的で使用できます。

• あるアプリケーションに対して、資源の割り当てを拒否したり、他のアプリケーションに許可されているよりも大きい割り当てを与えたりする

• 特定の割り当てを個別にではなく一括して行う

次のような目的を達成したいときは、資源管理機能を使用できるようにシステムを構成します。次のような制御が可能になります。

• アプリケーションが際限なく資源を浪費するのを防止する

• 外部イベントに基づいてアプリケーションの優先順位を変更する

• 一連のアプリケーションに資源の使用を保証する一方で、システムの使用率を最大限に高める

資源管理機能をシステム構成に組み込むときは、次のような作業が事前に必要です。

• システム上で競合する作業負荷を特定する

• 競合しない作業負荷と、主要な作業負荷に影響を与えるようなパフォーマンス要件を伴った作業負荷を区別する

競合しない作業負荷と競合する作業負荷を特定したら、システムの能力が許す範囲内で、業務サービスへの影響を最小限に抑えた資源構成を構築できます。

効率のよい資源管理を実現するために、Solaris 環境には制御メカニズム、通知メカニズム、および監視メカニズムが用意されています。これらの機能の多くは、proc(4) ファイルシステム、プロセッサセット、スケジューリングクラスなどの既存メカニズムの拡張機能として提供されます。その他の機能は資源管理に固有です。これらの機能については、以降の章で説明します。

資源の分類

資源は、アプリケーションの動作を変更する目的で操作されるコンピューティングシステムのあらゆる側面を意味します。つまり、資源は、アプリケーションが暗黙的または明示的に要求する機能です。 この機能が拒否または制限された場合は、堅固に作成されているアプリケーションの実行速度が低下します。

資源の分類は、資源の識別とは対照的に、多くの基準に基づいて行うことができます。たとえば、資源は、暗黙的な要求か明示的な要求か、時間ベース (CPU 時間など) の要求か時間に無関係な要求 (割り当てられた CPU シェアなど) か、などを基準に行うことができます。

通常、スケジューラベースの資源管理は、アプリケーションが暗黙的に要求する資源に適用されます。たとえば、実行を継続するときは、アプリケーションは暗黙的に追加の CPU 時間を要求します。 ネットワークソケットにデータを書き込むときは、アプリケーションは暗黙的に帯域幅を要求します。 暗黙的に要求される資源の総使用量に対して制約を設けることができます。

帯域幅または CPU サービスのレベルを明示的に折衝できるように、インタフェースを追加することもできます。追加スレッドの要求のように明示的に要求される資源は、制約によって管理できます。

資源管理の制御メカニズム

Solaris オペレーティング環境では、制約、スケジューリング、パーティション分割の 3 種類の制御メカニズムを使用できます。

制約

制約を使用すると、管理者やアプリケーション開発者は、作業負荷が使用する特定の資源の消費にいくつかの制限を設定できます。 制限を設定すると、資源の消費シナリオを簡単にモデル化できます。また、制限を設定することにより、無秩序に資源を要求してシステムのパフォーマンスや可用性に悪影響を及ぼす可能性がある悪質なアプリケーションを制御できます。

制約は、アプリケーションに制限を課します。アプリケーションとシステムの関係は、アプリケーションが動作できないところまで悪化してしまう可能性があります。そのような事態を回避する方法の 1 つは、資源に関する動作が不明なアプリケーションに対する制約を徐々に強めていくことです。第 7 章「資源制御」で説明する資源制御機能は、制約メカニズムを提供します。 新たに作成するアプリケーションであれば、資源の制約をアプリケーションが認識するようにすることもできます。ただし、すべての開発者がこの機能を使用するとは限りません。

スケジューリング

スケジューリングとは、一定の間隔で割り当てを決定することです。この決定は、予測可能なアルゴリズムに基づいて行われます。現在割り当てられている必要としないアプリケーションは、他のアプリケーションが使用できるように、その資源を解放します。スケジューリングに基づいて資源管理を行うと、資源に余裕がある構成の場合は使用率を最大限にできると同時に、資源が限界まで、あるいは過剰に使用されている場合には、割り当てを制御できます。スケジューリングのアルゴリズムにより、「制御」という用語の意味が決まります。場合によっては、スケジューリングアルゴリズムは、すべてのアプリケーションが資源にある程度アクセスできることを保証します。第 8 章「フェアシェアスケジューラ」で説明するフェアシェアスケジューラ (FSS) は、アプリケーションが制御された方法で CPU 資源にアクセスするように管理します。

パーティション分割

パーティション分割は、作業負荷をシステム上で使用可能な資源のサブセットに結合 (バインド) するために使用されます。資源と結合することにより、作業負荷は常に一定量の資源を使用できることが保証されます。第 10 章「資源プール」で説明する資源プール機能は、マシンの特定のサブセットに結合する作業負荷を制限します。パーティション分割を使用する構成では、システム全体が過剰使用されるのを防ぐことができます。ただし、この方法では、高い使用率の達成は難しくなります。 プロセッサなど、予約済みの資源に結合されている作業負荷がアイドル状態になっている場合でも、別の作業負荷がその資源を使用することはできないためです。

資源管理構成

資源管理構成の一部をネットワークのネームサービスに置くことができます。この機能により、管理者は、資源管理制約をマシンごとに排他的に適用するのではなく、複数のマシンに対して一括して適用できます。関連する作業は共通識別子を共有でき、その作業の使用状況はアカウンティングデータに基づいて表形式で表すことができます。

資源管理構成と作業負荷識別子の詳細については、第 5 章「プロジェクトとタスク」を参照してください。これらの識別子をアプリケーションの資源使用状況と結び付ける拡張アカウンティング機能については、第 6 章「拡張アカウンティング」を参照してください。

資源管理機能の効率的な使用

資源管理機能を使用して、アプリケーションが必要な応答時間を確保できるようにします。

また、資源管理機能により、資源の使用率を向上させることができます。使用状況を分類して優先付けすることにより、オフピーク時に余った資源を効率よく使用でき、処理能力を追加する必要がなくなります。また、負荷の変動が原因で資源を無駄にすることもなくなります。

サーバーを統合する場合

資源管理機能は、多くのアプリケーションを 1 台のサーバー上で統合できる環境で使用すると最も高い効果を発揮します。

多数のマシンの管理は複雑でコストがかかるため、より大規模で拡張性の高いサーバーにアプリケーションを統合することが望まれます。個々の作業負荷を別々のシステムで実行して、そのシステムの資源へのフルアクセスを与える代わりに、資源管理ソフトウェアを使用すれば、システム内の作業負荷を分離できます。資源管理機能を使用すると、1 つの Solaris システムで複数の異なるアプリケーションを実行して制御することにより、システムの総保有コスト (TCO) を低減することができます。

インターネットサービスやアプリケーションサービスを提供する場合は、資源管理を使用すると、次のことが可能になります。

• 1 台のマシンに複数の Web サーバーを配置する。各 Web サイトの資源消費を制御し、各サイトを他のサイトで起こる可能性のある過剰使用から保護する

• 欠陥のある CGI (Common Gateway Interface) スクリプトが CPU 資源を浪費するのを防止する

• 不正な動作をするアプリケーションによって引き起こされる、仮想メモリーのリークを防止する

• 顧客のアプリケーションが、同じサイトで実行されている別の顧客のアプリケーションの影響を受けないようにする

• 同一マシン上で異なるレベルまたはクラスのサービスを提供する

• 課金目的でアカウンティング情報を取得する

大規模で多様なユーザーが利用するシステムをサポートする場合

資源管理機能は、特に、教育機関のように大規模で多様なユーザーが利用するシステムでその効果を発揮します。さまざまな作業負荷が混在している場合は、特定のプロジェクトに高い優先順位を与えるようにソフトウェアを構成できます。

たとえば、大きな証券会社のトレーダは、データベースのクエリーや計算を実行するために、一時的に高速なアクセスが必要になる場合があります。一方、他のユーザーの作業負荷は、一定しています。トレーダのプロジェクトに、作業量に応じてより高い処理能力を割り当てれば、トレーダは必要とする応答性を確保できます。

また、資源管理機能は、シン (thin) クライアントシステムをサポートするのにも適しています。これらのプラットフォームは、スマートカードのようなフレームバッファーと入力デバイスを持つステートレスなコンソールを備えています。実際の処理は共有サーバー上で行われるため、タイムシェアリング型の環境とみなすことができます。資源管理機能を使ってサーバー上のユーザーを分離してください。こうすることで、過剰な負荷を引き起こしたユーザーがハードウェア資源を占有し、システムを使用する他のユーザーに重大な影響を与えることがなくなります。

資源管理の設定 (作業マップ)

次の作業マップに、システム上で資源管理機能を設定する際に必要となる作業の概要を示します。

第 5 章 プロジェクトとタスク

この章では、Solaris の資源管理機能のうち、プロジェクトおよびタスク機能について説明します。プロジェクトとタスクは、作業負荷にラベル付けを行い、他の作業負荷と区別するために使用されます。プロジェクトは、関連した作業に対してネットワーク全体で適用される管理識別子を与えます。タスクは、プロセスのグループを、作業負荷コンポーネントを表す管理しやすいエンティティにまとめます。

概要

作業負荷の応答性を最適化するには、まず分析対象のシステム上で実行中の作業負荷を特定できなければなりません。この情報は、プロセス指向の手法とユーザー指向の手法のどちらか一方だけを使用して取得できるものではありません。Solaris 環境では、作業負荷を区別して特定するための 2 つの追加機能、プロジェクトとタスクを利用できます。

実行中のプロセスは、そのプロセスのプロジェクトメンバーシップまたはタスクメンバーシップに基づいて、Solaris の標準コマンドを使って操作できます。 拡張アカウンティング機能は、プロセスとタスクの両方の使用状況についてレポートを作成し、各レコードに管理用プロジェクト識別子のタグを付けることができます。この処理により、オフラインで行う作業負荷分析作業をオンラインでの監視作業と関連付けることができます。プロジェクト識別子は、project ネームサービスデータベースを介して複数のマシンで共有できます。したがって、最終的には、複数のマシン上で実行される (つまり複数のマシンにわたる) 関連した作業負荷の資源消費をすべてのマシンについて分析できます。

プロジェクト

プロジェクト識別子は、関連する作業を特定するために使用される管理識別子です。プロジェクト識別子は、ユーザー識別子やグループ識別子と同様な、作業負荷に付けられているタグと考えることができます。ユーザーまたはグループは 1 つ以上のプロジェクトに所属できます。プロジェクトは、ユーザーまたはユーザーグループが参加することを許可されている作業負荷を表すために使用します。このメンバーシップは、たとえば、使用状況や初期資源割り当てに基づくチャージバックの根拠となります。ユーザーにはデフォルトのプロジェクトを割り当てる必要がありますが、ユーザーが起動するプロセスは、ユーザーが属しているプロジェクトであれば、どのプロジェクトにでも関連付けることができます。

ユーザーのデフォルトプロジェクトの判定

システムにログインするには、そのユーザーにデフォルトのプロジェクトが割り当てられている必要があります。

システム上の各プロセスはプロジェクトのメンバーシップを所有しているため、ログインやその他の初期処理にデフォルトのプロジェクトを割り当てるアルゴリズムが必要です。デフォルトプロジェクトを判定するアルゴリズムは、4 つの手順から成ります。デフォルトプロジェクトが見つからない場合、ユーザーのログインまたはプロセスの開始要求は拒否されます。

システムは、次の手順でユーザーのデフォルトプロジェクトを判定します。

1. ユーザーが、/etc/user_attr 拡張ユーザー属性データベースで定義されている project 属性のエントリを持っている場合は、その project 属性の値がデフォルトプロジェクトになります (user_attr(4) 参照)。

2. user.user-id という名前のプロジェクトが project(4) データベースにある場合は、そのプロジェクトがデフォルトプロジェクトになります。

3. group.group-name というプロジェクトが project データベースにあり、group-name がユーザーのデフォルトのグループ名 (passwd(4) で指定されている) である場合は、そのプロジェクトがデフォルトプロジェクトになります。

4. project データベースに default という特別なプロジェクトがある場合は、そのプロジェクトがデフォルトプロジェクトになります。

このロジックは getdefaultproj() ライブラリ関数が提供します (getprojent(3PROJECT) 参照)。

project データベース

プロジェクトのデータは、ローカルファイル、ネットワーク情報サービス (NIS) のプロジェクトマップ、または LDAP (Lightweight Directory Access Protocol) ディレクトリサービスに保存できます。/etc/project データベースまたはネームサービスは、ログイン時、および PAM (Pluggable Authentication Module) によるアカウント管理に対する要求があったときに使用され、ユーザーをデフォルトのプロジェクトに結合します。

プロジェクトデータベース内のエントリに対する更新は、/etc/project ファイルまたはネットワークネームサービスのデータベース表現のどちらに対するものであっても、現在アクティブなプロジェクトには適用されません。 更新内容は、login(1) または newtask(1) が使用されたときに、プロジェクトに新たに参加するタスクに適用されます。

PAM サブシステム

アカウント情報の変更や設定を行う操作には、システムへのログイン、rcp または rsh コマンドの呼び出し、ftp の使用、su の使用などがあります。 アカウント情報の変更や設定が必要な場合は、設定可能なモジュール群を使用して、認証、アカウント管理、資格管理、セッション管理などを行います。

プロジェクト用のアカウント管理 PAM モジュールについては、pam_projects(5) のマニュアルページを参照してください。PAM システムについては、pam(3PAM)、pam.conf(4) および pam_unix(5) のマニュアルページを参照してください。

ネームサービス構成

資源管理は、ネームサービス project データベースをサポートします。project データベースが格納されている場所は、/etc/nsswitch.conf で指定されます。デフォルトでは files が最初に指定されていますが、ソースは任意の順序で指定できます。

project: files [nis] [ldap]

プロジェクト情報に対して複数のソースが指定されている場合、ルーチンは最初に指定されているソースで情報を検索し、次にその後に続くデータベースを検索します。

/etc/nsswitch.conf の詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「ネームサービススイッチ (概要)」および nsswitch.conf(4) のマニュアルページを参照してください。

ローカルの project ファイルの形式

nsswitch.conf で project データベースとして files を選択した場合、ログインプロセスはプロジェクト情報を /etc/project ファイルで検索します (projects(1) および project(4) 参照)。project ファイルには、システムによって認識されるプロジェクトごとにエントリが 1 行ずつ、次の形式で記述されています。

projname:projid:comment:user-list:group-list:attributes

フィールドの定義は次のとおりです。

projname

プロジェクト名。英数字、下線 (_)、ハイフン (-) から成る文字列を指定します。最初の文字は英字でなければなりません。projname に、ピリオド (.)、コロン (:)、または改行文字を使用することはできません。

projid

システムでプロジェクトに割り当てられる一意の数値 ID (PROJID)。projid フィールドの最大値は UID_MAX (2147483647) です。

comment

プロジェクトの説明です。

user-list

プロジェクトへの参加を許可されたユーザーをコンマで区切ったリストです。

このフィールドではワイルドカードを使用できます。アスタリスク (*) を指定した場合、すべてのユーザーにプロジェクトへの参加を許可します。感嘆符に続けてアスタリスクを指定した場合 (!*)、すべてのユーザーのプロジェクトへの参加を拒否します。 感嘆符 (!) に続けてユーザー名を指定した場合、指定されたユーザーのプロジェクトへの参加を拒否します。

group-list

プロジェクトへの参加を許可されたユーザーのグループをコンマで区切ったリストです。

このフィールドではワイルドカードを使用できます。アスタリスク (*) を指定した場合、すべてのグループにプロジェクトへの参加を許可します。 感嘆符に続けてアスタリスクを指定した場合 (!*)、すべてのグループのプロジェクトへの参加を拒否します。 感嘆符 (!) に続けてグループ名を指定した場合、指定されたグループのプロジェクトへの参加を拒否します。

attributes

名前と値の組をセミコロンで区切ったリストです (第 7 章「資源制御」参照)。name は、オブジェクトに関連する属性を指定する任意の文字列です。また value はその属性のオプション値です。

name[=value]

名前と値の組で、名前に使用できるのは、文字、数字、下線、ピリオドに制限されます。rctl のカテゴリとサブカテゴリの区切り文字にはピリオドを使用します。属性名の最初の文字は英字にする必要があります。名前については大文字と小文字は区別されます。

値を、コンマと括弧を使用して構造化することにより、優先順位を設定できます。セミコロンは、名前と値の組を区切るために使用されるので、値の定義には使用できません。コロンは、プロジェクトフィールドを区切るために使用されるので、値の定義には使用できません。

このファイルを読み取るルーチンは、無効なエントリを検出すると停止します。 このため、無効なエントリの後に指定されているプロジェクトの割り当ては実行されません。

次に、デフォルトの /etc/project ファイルの例を示します。

system:0:System:::
user.root:1:Super-User:::
noproject:2:No Project:::
default:3::::
group.staff:10::::

次に、デフォルトの/etc/project ファイルの最後にプロジェクトエントリを追加した例を示します。

system:0:System:::
user.root:1:Super-User:::
noproject:2:No Project:::
default:3::::
group.staff:10::::
user.ml:2424:Lyle Personal:::
booksite:4113:Book Auction Project:ml,mp,jtd,kjh::

/etc/project ファイルに資源制御を追加する方法については、資源制御の使用を参照してください。

NIS のネームサービス構成

NIS を使用している場合は、NIS マップ内でプロジェクトを検索するように、/etc/nsswitch.conf ファイルで指定できます。

project: nis files 

NIS マップの project.byname と project.bynumber はどちらも、次に示すように /etc/project ファイルと同じ形式です。

projname:projid:comment:user-list:group-list:attributes

詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

LDAP のディレクトリサービス構成

LDAP を使用している場合は、LDAP エントリでプロジェクトを検索するように、/etc/nsswitch.conf ファイルで指定できます。

project: ldap files

LDAP データベースにおけるプロジェクトエントリのスキーマの詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス: DNS、NIS、LDAP 編)』の「Solaris スキーマ」を参照してください。

タスク

プロジェクトへのログインが成功するたびに、ログインプロセスを含む新しい「タスク」が作成されます。タスクは、時間をかけて行われる一連の作業を表すプロセスです。また、タスクは作業負荷コンポーネントと考えることもできます。

各プロセスは、1 つのタスクのメンバーであり、各タスクは 1 つのプロジェクトに関連付けられています。

図 5–1 プロジェクトとタスクのツリー

シグナル送信のようなセッション上のすべての操作も、タスクでサポートされています。タスクをプロセッサセットに結合して、スケジューリングの優先順位とクラスを設定することにより、タスク内の現在のプロセスとそれに続くすべてのプロセスを変更することもできます。

タスクは、ログイン時に作成されるほか (login(1) 参照)、cron(1M)、newtask(1)、および setproject(3PROJECT) によっても作成されます。

拡張アカウンティング機能は、タスクレベルで集計されたプロセスのアカウンティングデータを提供できます。

プロジェクトとタスクの管理に使用するコマンド

プロジェクトとタスクで使用するコマンドオプション

ps

タスクおよびプロジェクトの ID を表示するには、ps -o を使用します。たとえば、プロジェクト ID を表示するには、次のように入力します。

# ps -o user,pid,uid,projid
USER PID   UID  PROJID
jtd  89430 124  4113

id

ユーザーおよびグループ ID に加えて、現在のプロジェクト ID を表示するには、id -p を使用します。user オペランドを指定した場合、そのユーザーの通常のログインに関連付けられたプロジェクトが表示されます。

#  id -p
uid=124(jtd) gid=10(staff) projid=4113(booksite)

pgrep と pkill

特定のリスト内のプロジェクト ID と一致するプロセスだけを表示するには、次のように入力します。

# pgrep -J projidlist
# pkill -J projidlist

特定のリスト内のタスク ID と一致するプロセスだけを表示するには、次のように入力します。

# pgrep -T taskidlist
# pkill -T taskidlist

prstat

システムで現在実行中のプロセスとプロジェクトのさまざまな統計情報を表示するには、次のように入力します。

% prstat -J
	  PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 21634 jtd      5512K 4848K cpu0    44    0   0:00.00 0.3% prstat/1
   324 root       29M   75M sleep   59    0   0:08.27 0.2% Xsun/1
 15497 jtd        48M   41M sleep   49    0   0:08.26 0.1% adeptedit/1
   328 root     2856K 2600K sleep   58    0   0:00.00 0.0% mibiisa/11
  1979 jtd      1568K 1352K sleep   49    0   0:00.00 0.0% csh/1
  1977 jtd      7256K 5512K sleep   49    0   0:00.00 0.0% dtterm/1
   192 root     3680K 2856K sleep   58    0   0:00.36 0.0% automountd/5
  1845 jtd        24M   22M sleep   49    0   0:00.29 0.0% dtmail/11
  1009 jtd      9864K 8384K sleep   49    0   0:00.59 0.0% dtwm/8
   114 root     1640K  704K sleep   58    0   0:01.16 0.0% in.routed/1
   180 daemon   2704K 1944K sleep   58    0   0:00.00 0.0% statd/4
   145 root     2120K 1520K sleep   58    0   0:00.00 0.0% ypbind/1
   181 root     1864K 1336K sleep   51    0   0:00.00 0.0% lockd/1
   173 root     2584K 2136K sleep   58    0   0:00.00 0.0% inetd/1
   135 root     2960K 1424K sleep    0    0   0:00.00 0.0% keyserv/4
PROJID    NPROC  SIZE   RSS MEMORY      TIME  CPU PROJECT
    10       52  400M  271M    68%   0:11.45 0.4% booksite
     0       35  113M  129M    32%   0:10.46 0.2% system

Total: 87 processes, 205 lwps, load averages: 0.05, 0.02, 0.02

システムで現在実行中のプロセスとタスクのさまざまな統計情報を表示するには、次のように入力します。

% prstat -T
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 23023 root       26M   20M sleep   59    0   0:03:18 0.6% Xsun/1
 23476 jtd        51M   45M sleep   49    0   0:04:31 0.5% adeptedit/1
 23432 jtd      6928K 5064K sleep   59    0   0:00:00 0.1% dtterm/1
 28959 jtd        26M   18M sleep   49    0   0:00:18 0.0% .netscape.bin/1
 23116 jtd      9232K 8104K sleep   59    0   0:00:27 0.0% dtwm/5
 29010 jtd      5144K 4664K cpu0    59    0   0:00:00 0.0% prstat/1
   200 root     3096K 1024K sleep   59    0   0:00:00 0.0% lpsched/1
   161 root     2120K 1600K sleep   59    0   0:00:00 0.0% lockd/2
   170 root     5888K 4248K sleep   59    0   0:03:10 0.0% automountd/3
   132 root     2120K 1408K sleep   59    0   0:00:00 0.0% ypbind/1
   162 daemon   2504K 1936K sleep   59    0   0:00:00 0.0% statd/2
   146 root     2560K 2008K sleep   59    0   0:00:00 0.0% inetd/1
   122 root     2336K 1264K sleep   59    0   0:00:00 0.0% keyserv/2
   119 root     2336K 1496K sleep   59    0   0:00:02 0.0% rpcbind/1
   104 root     1664K  672K sleep   59    0   0:00:03 0.0% in.rdisc/1
TASKID    NPROC  SIZE   RSS MEMORY      TIME  CPU PROJECT                     
   222       30  229M  161M    44%   0:05:54 0.6% group.staff                 
   223        1   26M   20M   5.3%   0:03:18 0.6% group.staff                 
    12        1   61M   33M   8.9%   0:00:31 0.0% group.staff                 
     1       33   85M   53M    14%   0:03:33 0.0% system                      

Total: 65 processes, 154 lwps, load averages: 0.04, 0.05, 0.06	

-J オプションと -T オプションを一緒に使用することはできません。

プロジェクトとタスクでの cron と su の使用

cron

cron コマンドは、settaskid を発行し、実行を要求したユーザーの適切なデフォルトプロジェクトを使用して、cron、at、および batch の各ジョブが別のタスクで実行されるようにします。また、at および batch コマンドは、現在のプロジェクト ID を取得して at ジョブを実行するときにプロジェクト ID が復元されるようにします。

su

ユーザーのデフォルトプロジェクトを切り替え、その結果として新しいタスクを作成する (ログインのシミュレーションの一環として) には、次のように入力します。

# su - user

呼び出し側のプロジェクト ID を保持するには、- フラグを付けずに su コマンドを発行します。

# su user

プロジェクト管理の例

プロジェクトを定義して現在のプロジェクトを表示する方法

次の例は、projadd および projmod コマンドを使用する方法を示します。

1. スーパーユーザーになります。

2. システムのデフォルトの /etc/project ファイルを表示します。

   # cat /etc/project system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10::::

3. booksite というプロジェクトを追加し、追加したプロジェクトを mark という名前のユーザーにプロジェクト ID 番号 4113 で割り当てます。

   # projadd -U mark -p 4113 booksite

4. 再度 /etc/project ファイルを表示し、プロジェクトが追加されていることを確認します。

   # cat /etc/project system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: booksite:4113::mark::

5. comment フィールドにプロジェクトを説明するコメントを追加します。

   # projmod -c `Book Auction Project` booksite

6. /etc/project ファイルに加えた変更を確認します。

   # cat /etc/project system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: booksite:4113:Book Auction Project:mark::

/etc/project ファイルからプロジェクトを削除する方法

次の例は、projdel コマンドを使ってプロジェクトを削除する方法を示します。

1. スーパーユーザーになります。

2. projdel コマンドを使ってプロジェクト booksite を削除します。

   # projdel booksite

3. /etc/project ファイルを表示します。

   # cat /etc/project system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10::::

4. ユーザー名 mark でログインし、projects と入力して、割り当てられているプロジェクトを表示します。

   # su - mark # projects default

ユーザーおよびプロジェクトのメンバーシップ情報を取得する方法

-p フラグを付けて id コマンドを使用し、起動中のプロセスの現在のプロジェクトメンバーシップを表示します。

$ id -p
uid=100(mark) gid=1(other) projid=3(default)

新しいタスクを作成する方法

1. スーパーユーザーになります。

2. システムのタスク ID を取得するための -v (冗長) オプションを付けた newtask コマンドを使用して、booksite プロジェクトに新しいタスクを作成します。

   # newtask -v -p booksite 16

   newtask を実行すると、指定したプロジェクト内に新しいタスクが作成され、そのタスクにユーザーのデフォルトのシェルが置かれます。

3. 起動中のプロセスの現在のプロジェクトメンバーシップを表示します。

   # id -p uid=100(mark) gid=1(other) projid=4113(booksite)

   今度は、プロセスが新しいプロジェクトのメンバーになっています。

実行中のプロセスを新しいタスクに移動する方法

次の例は、実行中のプロセスを別のタスクとプロジェクトに関連付ける方法を示します。このタスクを実行するには、スーパーユーザーでなければなりません。または、プロセスの所有者で、かつ新しいプロジェクトのメンバーでなければなりません。

1. スーパーユーザーになります。

2. book_catalog プロセスのプロセス ID を取得します。

   # pgrep book_catalog 8100

3. プロセス 8100 を、新しいタスク ID を使って booksite プロジェクトに関連付けます。

   # newtask -v -p booksite -c 8100 17

   -c オプションは、newtask が指定された既存のプロセスに対して動作することを指定します。

4. タスクとプロセス ID の対応を確認します。

   # pgrep -T 17 8100

第 6 章 拡張アカウンティング

プロジェクトおよびタスク機能 (第 5 章「プロジェクトとタスク」で説明) を使って作業負荷にラベル付けを行い、分離することにより、作業負荷ごとの資源消費を監視できます。「拡張アカウンティング」サブシステムを使用すると、プロセスとタスクの両方について詳細な資源消費統計情報を取得できます。 拡張アカウンティングサブシステムでは、行われた作業の対象プロジェクトの使用状況レコードにラベル付けします。 また、拡張アカウンティングを IPQoS (Internet Protocol Quality of Service、IP サービス品質) フローアカウンティングモジュールと組み合わせて、システム上のネットワークフロー情報を取得することもできます。 IPQoS フローアカウンティングモジュールについては、『IPQoS の管理』の「フローアカウンティングの使用と統計情報の収集 (手順)」を参照してください。

拡張アカウンティングを開始する方法については、プロセス、タスク、およびフローの拡張アカウンティングを起動する方法を参照してください。

概要

資源管理メカニズムを適用する前に、まず、さまざまな作業負荷がシステムに対して行う資源消費要求の特徴をつかむ必要があります。Solaris オペレーティング環境の拡張アカウンティング機能を利用すると、タスクベース、プロセスベース、または IPQoS が提供するセレクタベース (ipqos(7IPP) 参照) で、システムやネットワークの資源消費を記録する柔軟性が得られます。システムの使用状況をリアルタイムで計測するオンライン監視ツールとは異なり、拡張アカウンティング機能を使用すると、使用状況の履歴を調べることができます。 その上で、将来の作業負荷の容量要件を算定できます。

拡張アカウンティングのデータを使用すれば、資源についての課金、作業負荷の監視、容量計画などの目的でソフトウェアを開発したり購入したりできます。

拡張アカウンティングの動作

Solaris 環境の拡張アカウンティング機能は、アカウンティングデータを含めるために、バージョン番号が付けられた拡張可能なファイル形式を使用します。このデータ形式を使用するファイルは、添付のライブラリ libexacct(3LIB) で提供される API を使ってアクセスまたは作成できます。作成されたファイルは、拡張アカウンティング機能を使用できる任意のプラットフォーム上で分析でき、データを容量計画やチャージバックに使用できます。

拡張アカウンティングを起動すると、libexacct API で調べることができる統計情報が収集されます。libexacct は、exacct ファイルを前後どちらの方向からでも検査できます。API は、カーネルが作成するファイルだけでなく、 libexacct によって生成されたサードパーティ製のファイルもサポートします。libexact に対する Practical Extraction and Report Language (Perl) インタフェースがあり、これによってレポートおよび抽出用のカスタムスクリプトを作成できます。 libexacct に対する Perl インタフェース を参照してください。

拡張アカウンティングを有効にすると、タスクは、自分のメンバープロセスの総資源使用状況を追跡します。タスクのアカウンティングレコードは、そのタスクの完了時に書き込まれます。中間レコードを書き込むこともできます。タスクの詳細については、第 5 章「プロジェクトとタスク」を参照してください。.

図 6–1 拡張アカウンティング起動時のタスクの追跡

拡張可能な形式

拡張アカウンティングの形式は、古い SunOS システムのアカウンティングソフトウェアの形式に比べて拡張性があります (『Solaris のシステム管理 (上級編)』の「システムアカウンティング」を参照)。拡張アカウンティングでは、システムアカウンティングメトリックスのシステムへの追加や削除をシステムの解放時またはシステムの操作中に行うことができます。

拡張アカウンティングと古いシステムのアカウンティングソフトウェアの両方をシステム上で同時に起動できます。

exacct レコードとその形式

exacct レコードを作成するルーチンは、次の 2 つの目的で使用できます。

• サードパーティ製の exacct ファイルを作成できるようにする

• putacct システムコールを使ってカーネルアカウンティングファイルに組み込まれるタグ付けレコードを作成できるようにする (getacct(2) 参照)

  ---

  注 –

  Perl インタフェースから putacct システムコールを利用することもできます。

  ---

この形式では、すべての変更を明示的なバージョン変更にしなくても、さまざまな形式のアカウンティングレコードを取得できます。アカウンティングデータを使用するアプリケーションは、認識不可能なレコードを無視するように作成する必要があります。

libexacct ライブラリは、ファイルを exacct 形式に変換し、exacct でファイルを作成します。このライブラリは、exacct 形式のファイルに対するインタフェースとしてサポートされている唯一のインタフェースです。

getacct、putacct、wracct の各システムコールは、フローには適用されません。 IPQoS フローアカウンティングの構成時には、カーネルによってフローレコードが作成され、ファイルに書き込まれます。

拡張アカウンティング構成

/etc/acctadm.conf ファイルには、現在の拡張アカウンティング構成が含まれます。このファイルは、ユーザーが直接編集するのではなく、acctadm インタフェースを介して編集します。

拡張アカウンティングデータは、デフォルトでは /var/adm/exacct ディレクトリに置かれます。acctadm(1M) コマンドを使用すると、プロセスやタスクのアカウンティングデータファイルの格納場所を変更できます。

拡張アカウンティングで使用されるコマンド

タスクおよびプロジェクト関連のコマンドについては、プロジェクトとタスクの管理に使用するコマンドを参照してください。IPQoS フローアカウンティングについては、ipqosconf (1M) のマニュアルページを参照してください。

libexacct に対する Perl インタフェース

Perl インタフェースによって、exacct フレームワークで作成されたアカウンティングファイルを読み取ることのできる、Perl スクリプトを作成できます。exacct ファイルを書き出す Perl スクリプトも作成できます。

このインタフェースの機能は、基礎となる C 言語の API と同様です。可能な場合は、基礎となる C 言語の API から取得したデータを Perl データタイプとして表示します。この機能によって、データアクセスが容易になり、バッファのパック/アンパック操作が不要になります。さらに、あらゆるメモリー管理が Perl ライブラリによって実行されます。

各種のプロジェクト、タスク、exacct 関連機能はいくつかのグループに分けられます。各機能グループは、別々の Perl モジュールに配置されます。各モジュールは、サンの標準である Sun::Solaris:: Perl パッケージ接頭辞から始まります。Perl exacct ライブラリが提供するクラスはすべて、Sun::Solaris::Exacct モジュールの下にあります。

配下の libexacct(3LIB) ライブラリは、exacct 形式のファイル、カタログタグ、および exacct オブジェクトに対する操作を実行します。exacct オブジェクトは、次の 2 つのタイプに分けられます。

• アイテム (単一データ値 [スカラー])

• グループ (項目のリスト)

次の表に各モジュールの概要を示します。

表で説明したモジュールの使用例については、libexacct に対する Perl インタフェースの使用 を参照してください。

拡張アカウンティング機能の使用

プロセス、タスク、およびフローの拡張アカウンティングを起動する方法

タスク、プロセス、およびフローの拡張アカウンティング機能を起動するには、acctadm(1M) コマンドを使用します。 acctadm の最後に付けられたオプションのパラメータは、このコマンドが、拡張アカウンティング機能のプロセスアカウンティングコンポーネント、システムタスクアカウンティングコンポーネント、フローアカウンティングコンポーネントのいずれに作用するかを示します。

1. スーパーユーザーになります。

2. プロセスの拡張アカウンティングを起動します。

   # acctadm -e extended -f /var/adm/exacct/proc process

3. タスクの拡張アカウンティングを起動します。

   # acctadm -e extended,mstate -f /var/adm/exacct/task task

4. フローの拡張アカウンティングを起動します。

   # acctadm -e extended -f /var/adm/exacct/flow flow

起動スクリプトを使って拡張アカウンティングを起動する方法

/etc/init.d/acctadm スクリプトへのリンクを /etc/rc2.d に作成することにより、実行中に拡張アカウンティングを起動できます。

# ln -s /etc/init.d/acctadm /etc/rc2.d/Snacctadm
# ln -s /etc/init.d/acctadm /etc/rc2.d/Knacctadm

変数 n は番号で置き換えられます。

アカウンティング構成の詳細については、拡張アカウンティング構成を参照してください。

拡張アカウンティング状態を表示する方法

引数なしで acctadm と入力すると、拡張アカウンティング機能の現在の状態が表示されます。

# acctadm
                 Task accounting: active
            Task accounting file: /var/adm/exacct/task
          Tracked task resources: extended
        Untracked task resources: none
              Process accounting: active
         Process accounting file: /var/adm/exacct/proc
       Tracked process resources: extended
     Untracked process resources: host,mstate
                 Flow accounting: active
            Flow accounting file: /var/adm/exacct/flow
          Tracked flow resources: extended
        Untracked flow resources: none

この例では、システムタスクアカウンティングが拡張モードと mstate モードで動作しています。プロセスアカウンティングとフローアカウンティングは、拡張モードで動作しています。

拡張アカウンティングの文脈では、マイクロステート (mstate) は、プロセス状態の微小な変化を反映した拡張データを意味し、このデータはプロセス使用状況ファイルで利用できます (proc(4) 参照)。このデータは、プロセスの活動に関して、基本レコードや拡張レコードよりも詳細な情報を提供します。

使用可能なアカウンティング資源を表示する方法

使用可能な資源は、システムやプラットフォームによってさまざまです。-r オプションを使用すると、システム上の使用可能なアカウンティング資源を表示できます。

# acctadm -r
process:
extended pid,uid,gid,cpu,time,command,tty,projid,taskid,ancpid,wait-status,flag
basic    pid,uid,gid,cpu,time,command,tty,flag
task:
extended taskid,projid,cpu,time,host,mstate,anctaskid
basic    taskid,projid,cpu,timeprocess:
extended pid,uid,gid,cpu,time,command,tty,projid,taskid,ancpid,wait-status,flag
basic    pid,uid,gid,cpu,time,command,tty,flag
task:
extended taskid,projid,cpu,time,host,mstate,anctaskid
basic    taskid,projid,cpu,time
flow:
extended 
saddr,daddr,sport,dport,proto,dsfield,nbytes,npkts,action,ctime,lseen,projid,uid
basic    saddr,daddr,sport,dport,proto,nbytes,npkts,action

プロセス、タスク、およびフローアカウンティングを停止する方法

プロセス、タスク、およびフローアカウンティングを停止するには、それぞれを個別にオフにします。

1. スーパーユーザーになります。

2. プロセスアカウンティングをオフにします。

   # acctadm -x process

3. タスクアカウンティングをオフにします。

   # acctadm -x task

4. フローアカウンティングをオフにします。

   # acctadm -x flow

5. タスクアカウンティング、プロセスアカウンティング、およびフローアカウンティングがオフになったことを確認します。

   # acctadm Task accounting: inactive Task accounting file: none Tracked task resources: extended Untracked task resources: none Process accounting: inactive Process accounting file: none Tracked process resources: extended Untracked process resources: host,mstate Flow accounting: inactive Flow accounting file: none Tracked flow resources: extended Untracked flow resources: none

libexacct に対する Perl インタフェースの使用

exacct オブジェクトの内容を再帰的に出力する方法

exacct オブジェクトの内容を再帰的に出力するには、次のコードを使用します。この機能は、ライブラリによって Sun::Solaris::Exacct::Object::dump() 関数として提供されています。ea_dump_object() という簡易関数でこの機能を利用することもできます。

sub dump_object
     {
             my ($obj, $indent) = @_;
             my $istr = '  ' x $indent;

             #
             # Retrieve the catalog tag.  Because we are 
             # doing this in an array context, the
             # catalog tag will be returned as a (type, catalog, id) 
             # triplet, where each member of the triplet will behave as 
             # an integer or a string, depending on context.
             # If instead this next line provided a scalar context, e.g.
             #    my $cat  = $obj->catalog()->value();
             # then $cat would be set to the integer value of the 
             # catalog tag.
             #
             my @cat = $obj->catalog()->value();

             #
             # If the object is a plain item
             #
             if ($obj->type() == &EO_ITEM) {
                     #
                     # Note: The '%s' formats provide s string context, so
                     # the components of the catalog tag will be displayed
                     # as the symbolic values. If we changed the '%s'
                     # formats to '%d', the numeric value of the components
                     # would be displayed.
                     #
                     printf("%sITEM\n%s  Catalog = %s|%s|%s\n", 
                        $istr, $istr, @cat);
                     $indent++;

                     #
                     # Retrieve the value of the item.  If the item contains
                     # in turn a nested exacct object (i.e., an item or
                     # group),then the value method will return a reference
                     # to the appropriate sort of perl object
                     # (Exacct::Object::Item or Exacct::Object::Group).
                     # We could of course figure out that the item contained
                     # a nested item orgroup by examining the catalog tag in
                     # @cat and looking for a type of EXT_EXACCT_OBJECT or
                     # EXT_GROUP.
                     #
                     my $val = $obj->value();
                     if (ref($val)) {
                             # If it is a nested object, recurse to dump it.
                             dump_object($val, $indent);
                     } else {
                             # Otherwise it is just a 'plain' value, so
                             # display it.
                             printf("%s  Value = %s\n", $istr, $val);
                     }

             #
             # Otherwise we know we are dealing with a group.  Groups
             # represent contents as a perl list or array (depending on
             # context), so we can process the contents of the group
             # with a 'foreach' loop, which provides a list context.
             # In a list context the value method returns the content
             # of the group as a perl list, which is the quickest
             # mechanism, but doesn't allow the group to be modified.
             # If we wanted to modify the contents of the group we could
             # do so like this:
             #    my $grp = $obj->value();   # Returns an array reference
             #    $grp->[0] = $newitem;
             # but accessing the group elements this way is much slower.
             #
             } else {
                     printf("%sGROUP\n%s  Catalog = %s|%s|%s\n",
                         $istr, $istr, @cat);
                     $indent++;
                     # 'foreach' provides a list context.
                     foreach my $val ($obj->value()) {
                             dump_object($val, $indent);
                     }
                     printf("%sENDGROUP\n", $istr);
             }
     }

新しいグループレコードを作成してファイルに書き込む方法

新しいグループレコードを作成して /tmp/exacct というファイルに書き込むには、次のスクリプトを使用します。

#!/usr/perl5/5.6.1/bin/perl

use strict;
use warnings;
use Sun::Solaris::Exacct qw(:EXACCT_ALL);
# Prototype list of catalog tags and values.
     my @items = (
             [ &EXT_STRING | &EXC_DEFAULT | &EXD_CREATOR      => "me"       ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_PID     => $$         ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_UID     => $<         ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_GID     => $(         ],
             [ &EXT_STRING | &EXC_DEFAULT | &EXD_PROC_COMMAND => "/bin/rec" ],
     );

     # Create a new group catalog object.
     my $cat = ea_new_catalog(&EXT_GROUP | &EXC_DEFAULT | &EXD_NONE)

     # Create a new Group object and retrieve its data array.
     my $group = ea_new_group($cat);
     my $ary = $group->value();

     # Push the new Items onto the Group array.
     foreach my $v (@items) {
             push(@$ary, ea_new_item(ea_new_catalog($v->[0]), $v->[1]));
     }

     # Open the exacct file, write the record & close.
     my $f = ea_new_file('/tmp/exacct', &O_RDWR | &O_CREAT | &O_TRUNC)
        || die("create /tmp/exacct failed: ", ea_error_str(), "\n");
     $f->write($group);
     $f = undef;

exacct ファイルの内容を出力する方法

exacct ファイルの内容を出力するには、次の Perl スクリプトを使用します。

#!/usr/perl5/5.6.1/bin/perl

     use strict;
     use warnings;
     use Sun::Solaris::Exacct qw(:EXACCT_ALL);

     die("Usage is dumpexacct <exacct file>\n") unless (@ARGV == 1);

     # Open the exact file and display the header information.
     my $ef = ea_new_file($ARGV[0], &O_RDONLY) || die(error_str());
     printf("Creator:  %s\n", $ef->creator());
     printf("Hostname: %s\n\n", $ef->hostname());

     # Dump the file contents
     while (my $obj = $ef->get()) {
             ea_dump_object($obj);
     }

     # Report any errors
     if (ea_error() != EXR_OK && ea_error() != EXR_EOF)  {
             printf("\nERROR: %s\n", ea_error_str());
             exit(1);
     }
     exit(0);

Sun::Solaris::Exacct::Object->dump() からの出力例

新しいグループレコードを作成してファイルに書き込む方法 で作成されたファイルに Sun::Solaris::Exacct::Object->dump() を実行した場合の出力例を示します。

Creator:  root
Hostname: localhost
GROUP
       Catalog = EXT_GROUP|EXC_DEFAULT|EXD_NONE
       ITEM
         Catalog = EXT_STRING|EXC_DEFAULT|EXD_CREATOR
         Value = me
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_PID
         Value = 845523
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_UID
         Value = 37845
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_GID
         Value = 10
       ITEM
         Catalog = EXT_STRING|EXC_DEFAULT|EXD_PROC_COMMAND
         Value = /bin/rec
ENDGROUP

第 7 章 資源制御

第 6 章「拡張アカウンティング」で説明したようにシステム上の作業負荷の資源消費を判定したら、資源の使用方法に制限を設けることができます。制限を設けると、作業負荷による資源の過剰消費を防ぐことができます。資源制御は、UNIX の資源制限の概念を拡張した機能で、資源を制限するために使用される制約メカニズムです。

概要

従来から、UNIX システムには資源制限機能があります (rlimits)。rlimits の機能を使用すると、管理者は、プロセスが使用できる資源の量に対して 1 つ以上の数値制限を設定できます。この制限には、プロセスごとの CPU 使用時間、プロセスごとのコアファイルサイズ、プロセスごとの最大ヒープサイズが含まれます。ヒープサイズは、プロセスのデータセグメントに割り当てられるメモリー領域のサイズです。

Solaris オペレーティング環境では、プロセスごとの資源制限という概念が、第 5 章「プロジェクトとタスク」で説明したタスクおよびプロジェクトに拡張されています。この拡張機能は、「資源制御」 (rctls) 機能によって提供されます。資源制御には、接頭辞 project、task、または process が付きます。資源制御はシステム全体に適用できます。

資源制御機能は、資源制限機能に対する互換インタフェースを提供します。資源制限機能を使用する既存のアプリケーションは、変更せずに、引き続き使用できます。また、既存のアプリケーションは、資源制御機能を利用するように変更されたアプリケーションと同様に監視することができます。

資源制御機能は、システム資源に対する制約メカニズムを提供します。これにより、プロセス、タスク、およびプロジェクトが、指定したシステム資源を過剰消費することを防止できます。このメカニズムは、資源の過剰消費を防ぐことにより、より管理しやすいシステムを実現します。

制約メカニズムは、容量計画を実施するときにも使用できます。制約を設けることにより、アプリケーションへの資源の提供を必ずしも拒否することなく、アプリケーションが必要とする資源量に関する情報を取得できます。

また、資源制御は、資源管理機能のための簡単な属性メカニズムとしても利用できます。たとえば、フェアシェアスケジューラ (FSS) のスケジューリングクラスで動作しているプロジェクトで利用できる CPU のシェア数は、資源制御 project.cpu-shares によって定義されます。プロジェクトは資源制御によって一定のシェア数を割り当てられるため、制御の超過につながる各種のアクションは許可されません。そのため、資源制御 project.cpu-shares の現在値は、指定したプロジェクトの属性とみなすことができます。

また、プロジェクト内のプロセスの集合が消費する物理メモリーを規制するには、別の種類のプロジェクト属性が使用されます。これらの属性には、接頭辞 rcap が付きます (たとえば、rcap.max-rss)。資源制御と同様に、この種類の属性も project データベース中に構成します。資源制御はカーネルによって実行されますが、 rcap プロジェクト属性は rcapd(1M) 資源上限デーモンによってユーザーレベルで実行されます。rcapd については、第 9 章「資源上限デーモンによる物理メモリーの制御」を参照してください。

資源制御の管理

資源制御機能は、project データベース (第 5 章「プロジェクトとタスク」参照) によって構成されます。資源制御の属性は、project データベースエントリの最後のフィールドで設定します。各資源制御に対応付けられる値は、括弧で囲まれ、コンマ区切りのプレーンテキストとして示されます。 括弧内の値は「action 文節」を示します。各 action 文節は、特権レベル、しきい値、および特定のしきい値に対応付けられたアクションで構成されます。各資源制御は複数の action 文節を持つことができ、各 action 文節もコンマで区切られます。 次のエントリは、プロジェクトエンティティにおけるプロセスごとのアドレス空間制限と、タスクごとの軽量プロセス (LWP) 制限を定義します。

development:101:Developers:::task.max-lwps=(privileged,10,deny);
  process.max-address-space=(privileged,209715200,deny)

rctladm(1M) コマンドを使用すると、資源制御機能の実行時に問い合わせや制御機能の変更を広域的に行うことができます。 prctl(1) コマンドを使用すると、資源制御機能の実行時に問い合わせや制御機能の変更をローカルに行うことができます。

使用可能な資源制御

次の表に、このリリースで使用できる標準の資源制御を示します。

この表では、各制御によって制約される資源について説明し、project データベースにおけるその資源のデフォルトの単位を示します。デフォルトの単位には次の 2 種類があります。

• 数量は制限される量を意味します。

• インデックスは最大有効識別子を意味します。

したがって、project.cpu-shares は、プロジェクトで使用することが許可されているシェア数を示します。 一方、process.max-file-descriptor は、open(2) システムコールによってプロセスに割り当てられるファイルの最大数を示します。

資源制御値と特権レベル

資源制御のしきい値は、ローカルアクションやロギングなどの広域アクションをトリガーできる実行ポイントを設定します。

各しきい値は、次の 3 種類の特権レベルのいずれかに対応付ける必要があります。

• 基本値 — 呼び出し元プロセスの所有者が変更できる

• 特権値 — 特権を持っている呼び出し元 (スーパーユーザー) だけが変更できる

• システム値 — オペレーティングシステムによる処理が実行されている間は、固定される

資源制御は、システムまたは資源の提供者によって定義されるシステム値を 1 つ持つことが保証されます。システム値は、オペレーティングシステムが提供できる資源の量を意味します。

特権値はいくつでも定義できます。基本値は 1 つだけ許可されます。特権値を指定しないで実行される操作には、デフォルトで、基本レベルの特権が割り当てられます。

資源制御値の特権レベルは、資源制御ブロックの特権フィールドで、RCTL_BASIC、RCTL_PRIVILEGED、または RCTL_SYSTEM のように定義します。詳細は、getrctl(2) を参照してください。prctl コマンドを使用すると、基本レベルおよび特権レベルに対応付けられている値を変更できます。

資源制御値に対応付けられたアクション

資源制御に設定された各しきい値に対して、1 つ以上のアクションを対応付けることができます。

• しきい値を超える量の資源要求を拒否できる

• しきい値に達した場合は、違反プロセスまたは監視プロセスにシグナルを送信できる

実装上の制限により、しきい値に設定できるアクションは、各制御のグローバルプロパティによって制限されます。次の表に、使用できるシグナルアクションを示します。シグナルの詳細については、signal (3HEAD) を参照してください。

資源制御のフラグとプロパティ

システム上の資源制御には、それぞれ特定のプロパティセットが対応付けられています。このプロパティセットは、一連のグローバルフラグとして定義されます。グローバルフラグは、その資源が制御されているすべてのインスタンスに対応付けられます。グローバルフラグは変更できませんが、rctladm または getrctl システムコールを使って取得できます。

ローカルフラグは、特定のプロセスまたはプロセス集合に対する資源制御の特定のしきい値について、デフォルトの動作と構成を定義します。あるしきい値のローカルフラグが、同じ資源制御で定義されている別のしきい値の動作に影響することはありません。ただし、グローバルフラグは、特定の制御に対応付けられているすべての値の動作に影響します。ローカルフラグは、対応するグローバルフラグによる制約の範囲内で、prctl コマンドまたは setrctl システムコールを使って変更できます (setrctl(2) 参照)。

ローカルフラグ、グローバルフラグ、およびそれらの定義の詳細なリストについては、rctlblk_set_value(3C) を参照してください。

特定の資源制御がしきい値に達したときのシステムの動作を確認するには、rctladm を使ってその資源制御のグローバルフラグを表示します。たとえば、process.max-cpu-time の値を表示するには、次のように入力します。

$ rctladm process.max-cpu-time
	process.max-cpu-time   syslog=off   [ lowerable no-deny cpu-time inf ]

広域フラグは、次のことを示します。

lowerable

この制御の特権値を下げるのに、スーパーユーザー特権を必要としない

no-deny

しきい値を超えても、資源へのアクセスは拒否されない

cpu-time

資源がしきい値に達したとき、SIGXCPU を送信できる

inf

RCTL_LOCAL_MAXIMAL が設定されている値は、実際には無限数を意味し、制約はない

資源制御のローカル値とアクションを表示するには、prctl を使用します。

$ prctl -n process.max-cpu-time $$
	353939: -ksh
	process.max-cpu-time   [ lowerable no-deny cpu-time inf ]
		18446744073709551615 privileged signal=XCPU   [ max ]
		18446744073709551615 system     deny          [ max ]

この例では、2 つのしきい値の両方に max (RCTL_LOCAL_MAXIMAL) フラグが設定されており、資源制御には inf (RCTL_GLOBAL_INFINITE) フラグが設定されています。したがって、設定されているように、両方のしきい値は無限値を意味し、これらの値を上回ることはありません。

資源制御の実行

1 つの資源には、複数の資源制御を設定できます。 資源制御は、プロセスモデルの包含レベルごとに 1 つずつ設定できます。 同じ資源上の異なるコンテナレベルで資源制御がアクティブな場合、まず、最も小さいコンテナの制御が実行されます。したがって、process.max-cpu-time と task.max-cpu-time の両方の制御が同時に検出された場合は、まず process.max-cpu-time に対するアクションが実行されます。

図 7–1 プロセス集合、コンテナの包含関係、およびその資源制御セット

資源制御イベントの広域監視

プロセスの資源消費が不明な場合がよくあります。 資源消費に関する情報を入手するには、rctladm(1M) で利用できる広域資源制御アクションを使用します。 rctladm を使用して、資源制御に syslog アクションを設定します。 その資源制御が管理するエンティティでしきい値が検出されると、設定したログレベルでシステムメッセージが記録されます。

構成

表 7–1 に示されている各資源制御をプロジェクトに割り当てることができるのは、ログイン時、newtask(1) が呼び出されたとき、または at(1)、batch (at(1) を参照)、cron(1M) など、プロジェクトを扱うことができる起動ツールが呼び出されたときです。開始される各コマンドは、呼び出し側のユーザーのデフォルトプロジェクトとは異なるタスクで起動されます。

project データベース内のエントリに対する更新は、/etc/project ファイルまたはネットワークネームサービスのデータベース表現のどちらに対するものであっても、現在アクティブなプロジェクトには適用されません。 更新内容は、新しいタスクが login(1) または newtask によってプロジェクトに参加したときに適用されます。

動作中のシステム上の資源制御値を一時的に更新する

project データベースで変更された値は、プロジェクト内で開始される新しいタスクに対してだけ有効になります。ただし、rctladm および prctl コマンドを使用すると、動作中のシステムの資源制御を更新できます。

ログ状態の更新

rctladm コマンドは、システム全体で、各資源制御の広域ログ状態に影響を与えます。このコマンドは、広域的状態を表示し、制御の限度を超えたときに syslog が記録するログのレベルを設定できます。

資源制御の更新

prctl コマンドを使用すると、プロセスごと、タスクごと、またはプロジェクトごとに資源制御値とアクションを表示したり、一時的に変更したりできます。プロジェクト ID、タスク ID、またはプロセス ID を入力として指定すると、このコマンドは、定義されているレベルで資源制御に対して動作します。

変更した値とアクションはすぐに適用されます。ただし、これらの変更が適用されるのは、現在のセッションだけです。変更内容は、project データベースには記録されません。システムを再起動すると、変更内容は失われます。資源制御を永続的に変更するには、project データベースで変更を行う必要があります。

project データベースで変更できる資源制御設定はすべて、prctl コマンドを使って変更することもできます。基本値と特権値はどちらも、追加、削除が可能で、またアクションも変更できます。デフォルトでは、基本レベルの資源制御はすべての操作の影響を受けます。スーパーユーザー特権があるプロセスとユーザーは、特権レベルの資源制御も変更できます。システム資源の制御は変更できません。

資源制御の使用

プロジェクト内の各タスクの最大 LWP 数を設定する方法

/etc/project データベースで次のエントリを入力し、x-files プロジェクトの各タスクの最大 LWP 数を 3 に設定します。

x-files:100::root::task.max-lwps=(privileged,3,deny)

プロジェクト x-files で newtask と結合することによって新しいタスクを作成したスーパーユーザーは、そのタスクの実行中、LWP を 3 つまでしか作成できません。次の注釈付きのセッション例を参照してください。

# newtask -p x-files csh

# prctl -n task.max-lwps $$
688: csh
task.max-lwps
                            3 privileged deny
                   2147483647 system     deny
# id -p
uid=0(root) gid=1(other) projid=100(x-files)

# ps -o project,taskid -p $$
 PROJECT TASKID
 x-files   236

# csh        /* 2 つ目の LWP を作成 */

# csh        /* 3 つ目の LWP を作成 */

# csh        /* これ以上 LWP を作成することはできない */
Vfork failed

#

プロジェクトに複数の制御を設定する方法

/etc/project ファイルには、各プロジェクトごとに複数の資源制御設定を記述でき、さらに各資源制御ごとに複数のしきい値を記述できます。しきい値は action 文節で定義されます。複数の値はコンマで区切られます。

ファイル内の次の行は、basic (基本) レベルの制御を設定します。この設定では、x-files プロジェクトのタスクごとの最大 LWP 数に対して、アクションは発生しません。また、タスクごとの最大 LWP 数に対して特権レベルの deny 制御を設定しています。この制御により、前述の例のように、最大数を超える数の LWP を作成しようとすると失敗します。最後に、プロセスごとの最大ファイル記述子は basic レベルに制限されており、最大値を超えるオープンコールは失敗します。

x-files:101::root::task.max-lwps=(basic,10,none),(privileged,500,deny);
    process.max-file-descriptor=(basic,128,deny)

prctl を使用する方法

スーパーユーザーは、prctl と入力することにより、実行中の現在のシェルの最大ファイル記述子を表示できます。

# prctl -n process.max-file-descriptor $$
8437:   sh
process.max-file-descriptor              [ lowerable deny ]
                          256 basic      deny
                        65536 privileged deny
                   2147483647 system     deny

prctl コマンドを使って新しい特権値を一時的に追加し、x-files プロジェクトの各タスクで 4 つ以上の LWP の使用を拒否することもできます。結果は プロジェクト内の各タスクの最大 LWP 数を設定する方法の結果と同じです。次の注釈付きサンプルセッションでこれを示します。

# newtask -p x-files

# id -p
uid=0(root) gid=1(other) projid=101(x-files)

# prctl -n task.max-lwps -t privileged -v 3 -e deny -i project x-files

# prctl -n task.max-lwps -i project x-files
670:    sh
task.max-lwps
                            3 privileged deny
                   2147483647 system     deny

prctl -r を使って資源制御の最小値を変更することもできます。

# prctl -n process.max-file-descriptor -r -v 128 $$

rctladm を使用する方法

rctladm を使用すると、資源制御のグローバル syslog 属性を有効にできます。制御が限界を超えたとき、指定された syslog レベルで通知が記録されます。次のコマンドを入力します。

# rctladm -e syslog process.max-file-descriptor

容量に関する警告

資源制御に対してグローバルアクションを設定すると、資源制御値を超えたエンティティに関する通知を受け取ることができます。

たとえば、一般的な作業負荷のための十分な CPU 資源が Web サーバーに割り当てられているかどうかを確認する場合を考えます。この容量は、sar(1) データで CPU のアイドル時間と平均負荷率を分析すれば判定できます。 また、拡張アカウンティングデータを調べて、Web サーバープロセスで同時に実行しているプロセス数を確認することもできます。

より簡単な方法は、Web サーバーをタスクに配置することです。その上で、syslog を使ってグローバルアクションを設定すると、タスクがマシンのパフォーマンスに適した LWP の計画数を上回ったときに、警告が通知されます。

Web サーバーに十分な CPU 容量が割り当てられているかどうかを判定する方法

1. prctl コマンドを使用して、httpd プロセスを含むタスクにスーパーユーザーが所有する特権レベルの資源制御を設定します。各タスクの LWP の総数を 40 に制限し、すべてのローカルアクションを無効にします。

   # prctl -n task.max-lwps -v 40 -t privileged -d all `pgrep httpd`

2. 資源制御 task.max-lwps で、システムログのグローバルアクションを有効にします。

   # rctladm -e syslog task.max-lwps

3. 作業負荷が資源制御を超えるかどうかを監視します。

   作業負荷が資源制御を超えると、次のような内容が /var/adm/messages に記録されます。

   Jan 8 10:15:15 testmachine unix: [ID 859581 kern.notice] NOTICE: privileged rctl task.max-lwps exceeded by task 19

第 8 章 フェアシェアスケジューラ

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

概要

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

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

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

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

CPU シェアの定義

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

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

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

CPU シェアとプロセスの状態

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

次の式から、FSS スケジューラによるプロジェクトごとの CPU 資源の割り当て方法が算出されます。(allocation = 割り当て、project = プロジェクト、shares = シェア)

図 8–1 FSS スケジューラのシェア計算

アクティブなプロジェクトが増えると、各プロジェクトの 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 データベースとネームサービスについては、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(1) を使用します。たとえば、x-files プロジェクトに関連付けられているプロセスの実行中に、そのプロジェクトの資源制御 project.cpu-shares の値を 3 に変更するには、次のように入力します。

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

-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 割り当ては、各プロセッサセット内で実行されるアクティブなプロジェクトに対して算出されます。(allocation = 割り当て、project = プロジェクト、shares = シェア、processor set = プロセッサセット)

図 8–2 プロセッサセットを使用する場合の FSS スケジューラのシェア計算

異なるプロセッサセット内で実行されるプロジェクトのパーティションは、異なる 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 の監視

prstat(1M) を使用して、CPU 使用量をアクティブなプロジェクトごとに監視できます。

タスク用の拡張アカウンティングデータを使用して、長期間使用される CPU 資源の合計量について、プロジェクトごとの統計情報を取得できます。詳細は、第 6 章「拡張アカウンティング」を参照してください。

システムの CPU 使用量をプロジェクトごとに監視する方法

システム上で実行されるプロジェクトの CPU 使用量を監視するには、次のように入力します。

% prstat -J

プロセッサセット内の CPU 使用量をプロジェクトごとに監視する方法

プロセッサセットに登録されているプロジェクトの CPU 使用量を監視するには、次のように入力します。

% prstat -J -C pset-list

pset-list

コンマ区切りのプロセッサセット ID のリスト

FSS の構成例

Solaris 環境における他のスケジューリングクラスと同様に、FSS では、スケジューリングクラスを設定するコマンドや、スケジューラのチューンアップパラメータを設定するコマンド、個々のプロセスのプロパティを設定するコマンドを使用できます。

スケジューリングクラスの設定方法

dispadmin コマンドを使用して、システムのデフォルトのスケジューラとして FSS を設定します。

# dispadmin -d FSS

この変更指定は次の再起動で有効になります。再起動後は、システムのすべてのプロセスが FSS スケジューリングクラスで実行されます。

プロセスを TS から FSS クラスに手動で移動する方法

デフォルトのスケジューリングクラスを変更した後で再起動しなくても、プロセスを TS スケジューリングクラスから FSS スケジューリングクラスに手動で移動できます。

1. スーパーユーザーになります。

2. init プロセス (pid 1) を FSS スケジューリングクラスに移動します。

   # priocntl -s -c FSS -i pid 1

3. すべてのプロセスを TS スケジューリングクラスから FSS スケジューリングクラスに移動します。

   # priocntl -s -c FSS -i class TS

すべてのプロセスは、再起動後には再び TS スケジューリングクラスで実行されます。

プロセスをすべてのユーザークラスから FSS クラスに手動で移動する方法

TS 以外のデフォルトのクラスを使用している場合、たとえば、デフォルトで IA クラスを使用するウィンドウ環境がシステムで実行されている場合があります。デフォルトのスケジューリングクラスを変更した後で再起動しなくても、すべてのプロセスを FSS スケジューリングクラスに手動で移動できます。

1. スーパーユーザーになります。

2. init プロセス (pid 1) を FSS スケジューリングクラスに移動します。

   # priocntl -s -c FSS -i pid 1

3. すべてのプロセスを現在のスケジューリングクラスから FSS スケジューリングクラスに移動します。

   # priocntl -s -c FSS -i all

すべてのプロセスは、再起動後には再びデフォルトのスケジューリングクラスで実行されます。

プロジェクトのプロセスを FSS クラスに移動する方法

特定のプロジェクト内のプロセスを現在のスケジューリングクラスから FSS スケジューリングクラスに手動で移動できます。

1. スーパーユーザーになります。

2. プロジェクト ID 10 で実行するプロセスを FSS スケジューリングクラスに移動します。

# priocntl -s -c FSS -i projid 10

プロジェクトのプロセスは、再起動後には再びデフォルトのスケジューリングクラスで実行されます。

スケジューラのパラメータを調整する方法

dispadmin コマンドを使用して、FSS スケジューラのタイムクォンタム (time quantum) 値を調べ、調整できます。タイムクォンタムとは、スレッドがプロセッサに上で実行を開始してからそのプロセッサを放棄するまでの時間量のことです。FSS スケジューラの現在のタイムクォンタムを表示するには、次のように入力します。

$ dispadmin -c FSS -g
#
# Fair Share Scheduler Configuration
#
RES=1000
#
# Time Quantum
#
QUANTUM=110

-g オプションを使用するときに、同時に -r オプションも指定すると、タイムクォンタム値の表示に使用する最小単位を指定できます。最小単位を指定しないと、タイムクォンタム値はデフォルトのミリ秒で表示されます。次のコマンドを入力します。

$ dispadmin -c FSS -g -r 100
#
# Fair Share Scheduler Configuration
#
RES=100
#
# Time Quantum
#
QUANTUM=11

FSS スケジューリングクラスにスケジューリングパラメータを設定するには、dispadmin -s を使用します。file 内の値は、-g オプションで得られる出力と同じ形式で指定する必要があります。これらの値は、カーネル内の現在の値を上書きします。次のコマンドを入力します。

$ dispadmin -c FSS -s file

関連項目

FSS スケジューラの使用方法については、priocntl(1)、ps(1)、dispadmin(1M)、および FSS(7) を参照してください。

第 9 章 資源上限デーモンによる物理メモリーの制御

資源上限デーモン rcapd は、資源上限が定義されたプロジェクト内で動作するプロセスが消費する物理メモリーを規制します。

資源上限デーモンの概要

資源「上限」とは、物理メモリーなどの資源消費量の上限のことです。物理メモリーの上限はプロジェクトごとに設定します。

資源上限デーモンとその関連ユーティリティは、物理メモリーの資源上限を制限および管理するメカニズムを提供します。

資源制御と同様に、資源上限を定義するには、project データベース内にあるプロジェクトエントリの属性を使用します。資源制御はカーネルによって同期的に実行されますが、物理メモリーの資源上限の制限は資源上限デーモンによってユーザーレベルで非同期的に実行されます。 この資源上限の制限は非同期的に実行されるため、資源上限デーモンがサンプリングを行う間隔の分だけ、短時間の遅延が発生します。

rcapd については、rcapd(1M) のマニュアルページを参照してください。プロジェクトと project データベースについては、 第 5 章「プロジェクトとタスク」および project(4) のマニュアルページを参照してください。資源制御については、第 7 章「資源制御」を参照してください。

資源上限制御のしくみ

資源上限デーモンは、物理メモリー上限が定義されたプロジェクトの資源使用率を定期的にサンプリングします。このサンプリング間隔は管理者が指定できます。詳細は、サンプリング間隔の決定を参照してください。システムの物理メモリー使用率が上限実行しきい値を超え、ほかの条件にも適合する場合、資源上限デーモンは、物理メモリー上限が定義されたプロジェクトの資源消費をその上限以下に減らします。

仮想メモリーシステムは物理メモリーを複数の「ページ」に分割します。「ページ」は、Solaris メモリー管理サブシステムにおける物理メモリーの基礎となる単位です。データをファイルからメモリーに読み取るとき、仮想メモリーシステムは 1 度に 1 ページずつ読み取ります。この動作のことを、ファイルの「ページイン」と呼びます。資源消費を減らすとき、資源上限デーモンは、あまり使用されていないページをスワップデバイス (物理メモリーの外にある領域) に再配置します。この動作のことを「ページアウト」と呼びます。

物理メモリーを管理するために、資源上限デーモンは、プロジェクトの作業負荷の常駐セットのサイズを、作業セットのサイズに対して調節します。常駐セットとは、物理メモリーに常駐するページのことです。作業セットとは、作業負荷がその処理サイクル中にアクティブに使用するページのことです。作業セットは、プロセスが動作するモードや処理するデータの種類に応じて、そのときどきで変化します。すべての作業負荷がその作業セットの常駐に十分な物理メモリーにアクセスできるのが理想です。しかし、作業セットは、物理メモリーのほか、二次ディスク記憶装置にも格納することが可能です。

rcapd は 1 度に 1 つのインスタンスしか実行できません。

物理メモリーの使用率を制限する属性

物理メモリー資源の上限をプロジェクトに対して定義するには、常駐セットサイズ (RSS) の上限を設定します。この属性は project データベースの次のエントリに追加します。

rcap.max-rss

プロジェクト内のプロセスが利用できる物理メモリーの合計 (バイト数)。

たとえば、/etc/project データベース内の次の行は、10G バイトの RSS 上限を db というプロジェクトに対して設定します。

db:100::db,root::rcap.max-rss=10737418240

指定した上限値はシステムによってページのサイズに丸められることがあります。

rcapd の構成

資源上限デーモンを構成するには、rcapadm コマンドを使用します。次のような作業が可能です。

• 上限実行しきい値を設定する

• rcapd が実行する動作間隔を設定する

• 資源上限制御を有効または無効にする

• 構成済みの資源上限デーモンの現在の状態を表示する

資源上限デーモンを構成するには、スーパーユーザーの特権を持っているか、プロファイルの一覧内に Process Management プロファイルが含まれている必要があります。Process Management 役割と System Administrator 役割には、どちらにも Process Management プロファイルが含まれています。『Solaris のシステム管理 (セキュリティサービス)』の「RBAC 要素: 参照情報」を参照してください。

構成の変更を rcapd に適用するには、構成間隔で自動的に行われるのを待つか (rcapd の動作間隔を参照) 、 SIGHUP を手動で送信します (kill(1) のマニュアルページを参照)。

引数なしで使用した場合、rcapadm は資源上限デーモンの現在の状態を表示します (構成されている場合のみ)。

以下の項では、上限の制限、上限値、および rcapd の動作間隔について説明します。

メモリー上限実行しきい値

「メモリー上限実行しきい値 」とは、上限の制限の引き金となる、システム上の物理メモリーの使用率 (パーセンテージ) のことです。システムの物理メモリー使用率がこのしきい値を超えたとき、メモリー上限が制限されます。この使用率には、アプリケーションやカーネルが使用する物理メモリーも含まれます。この使用率は、メモリー上限が制限される方法を決定します。

上限が制限されると、プロジェクトの作業負荷からメモリーがページアウトされることがあります。

• メモリーをページアウトすることによって、作業負荷に定義された上限を超えた分のメモリーのサイズを小さくすることができます。

• メモリーをページアウトすることによって、システム上のメモリー上限実行しきい値を超えた物理メモリーの使用率を下げることができます。

作業負荷は、定義された上限までの物理メモリーを使用することが許可されます。システムのメモリー使用率がメモリー上限実行しきい値を下回っている場合、作業負荷は上限より多くのメモリーを使用できます。

上限実行しきい値を設定する方法については、メモリー上限実行しきい値を設定する方法を参照してください。

上限値の決定

プロジェクトの上限の設定が低すぎると、通常の状態でも、作業負荷が効率的に機能するだけのメモリーを使用できない可能性があります。作業負荷がより多くのメモリーを要求するためページングが発生し、システムのパフォーマンスに悪影響がでます。

プロジェクトの上限の設定が高すぎると、上限に達する前に、利用可能な物理メモリーを使い果たす可能性があります。この場合、物理メモリーは、rcapd ではなくカーネルによって効率的に管理されます。

プロジェクトの上限を決定するときには、次の要素を考慮します。

入出力システムへの影響

サンプリングした使用率がプロジェクトの上限を超えている場合、資源上限デーモンはプロジェクトの作業負荷の物理メモリー使用率を減らそうとします。上限が制限されている間は、作業負荷がマッピングしているファイルには、スワップなどのデバイスが使用されます。上限を頻繁に超える作業負荷の場合、そのパフォーマンスは、スワップデバイスのパフォーマンスに大きく左右されます。このような作業負荷を実行することは、作業負荷の上限と同じサイズの物理メモリーを持つマシン上で作業負荷を実行することと似ています。

CPU 使用率への影響

資源上限デーモンの CPU 使用率は、このデーモンが上限を制限するプロジェクトの作業負荷内のプロセスの数と、作業負荷のアドレス空間のサイズによって変化します。

資源上限デーモンの CPU 時間の一部は、作業負荷の使用率のサンプリングに費やされます。作業負荷にプロセスを追加すると、使用率のサンプリングにかかる時間が増えます。

上限値を超えると上限が制限され、資源上限デーモンの CPU 時間がさらに消費されます。消費される CPU 時間は仮想メモリーの量に比例します。消費される CPU 時間は、作業負荷のアドレス空間の合計サイズの変化によって増減します。この情報は、rcapstat の出力の vm 列に報告されます。詳細は、rcapstat による資源使用率の監視および rcapstat(1) のマニュアルページを参照してください。

共有メモリーの報告

資源上限デーモンは、メモリーのどのページがほかのプロセスと共有されているのか、あるいは、同じプロセス内で複数回マッピングされているのかを判断できません。rcapd は各ページが一意であると仮定するため、報告される常駐セットサイズ (RSS) の推定値と実際値は一致しません。

データベースのような作業負荷は共有メモリーを多用します。このような作業負荷では、次のようにプロジェクトの通常の使用率をサンプリングすることによって、適切な初期上限値を決定できます。prstat コマンドに -J オプションを付けて実行し、その出力を使用します。prstat(1M) のマニュアルページを参照してください。

rcapd の動作間隔

rcapd を定期的に実行するように、rcapd の動作間隔を設定できます。

すべての間隔は秒単位で指定します。次の表に、rcapd の動作とそのデフォルトの間隔値を示します。

間隔を調節する方法については、動作間隔を設定する方法を参照してください。

rcapd スキャン間隔の決定

スキャン間隔とは、rcapd が新しいプロセスを探す頻度のことです。多くのプロセスが動作しているシステムでは、一覧のスキャンに時間がかかるため、スキャン間隔を長くして、消費される CPU 時間の合計を減らしたほうがよい場合もあります。しかし、スキャン間隔は、あるプロセスの存在が上限が定義されている作業負荷に属するとみなされるまでに最低限必要な時間も意味します。生存期間が短いプロセスを数多く実行する作業負荷の場合、スキャン間隔が長いと、rcapd はそれらのプロセスが作業負荷に属さないものとみなす可能性があります。

サンプリング間隔の決定

rcapadm で構成したサンプリング間隔は、作業負荷の使用率をサンプリングして上限を超えていた場合に、rcapd が上限を制限するまでの、最短時間です。サンプリング間隔を短くすると、ほとんどの場合、rcapd が上限を頻繁に制限するため、ページングによる入出力が増えます。しかし、サンプリング間隔を短くすると、特定の作業負荷の物理メモリー使用率が急増した場合に、ほかの作業負荷への影響を抑えることにもなります。サンプリングの合間には、この作業負荷は自由にメモリーを消費でき、上限が定義されているほかの作業負荷のメモリーすらも利用できますが、この合間が狭められることになるのです。

rcapstat に指定したサンプリング間隔が、rcapadm で rcapd に指定したサンプリング間隔よりも短い場合、いくつかの間隔の出力はゼロになることがあります。この状況が発生するのは、rcapd が統計を更新する間隔が、rcapadm で指定した間隔よりも長いためです。rcapadm で指定した間隔は、rcapstat で使用されるサンプリング間隔から独立しています。

rcapstat による資源使用率の監視

上限が定義されたプロジェクトの資源使用率を監視するには、rcapstat を使用します。rcapstat の報告例については、rcapstat による報告の生成を参照してください。

報告用のサンプリング間隔、および統計を繰り返す回数を設定できます。

interval

サンプリング間隔を指定します (秒)。デフォルトの間隔は 5 秒です。

count

統計を繰り返す回数を指定します。デフォルトでは、終了シグナルを受信するまで、あるいは、rcapd プロセスが終了するまで、 rcapstat は統計を報告し続けます。

rcapstat が最初に発行する報告では、ページング統計は資源上限デーモンの起動以降の活動を示します。以後の報告では、前回の報告以降の活動を示します。

次の表に、rcapstat の報告の列見出しを示します。

rcapadm による資源上限デーモンの管理

この節では、rcapadm を使用して資源上限デーモンを構成する手順について説明します。詳細は、rcapd の構成および rcapadm(1) のマニュアルページを参照してください。

引数なしで使用した場合、rcapadm は資源上限デーモンの現在の状態を表示します (構成されている場合のみ)。

メモリー上限実行しきい値を設定する方法

上限は、プロセスが利用できる物理メモリーが少なくなるまで制限されないように構成できます。詳細は、メモリー上限実行しきい値を参照してください。

最小値 (デフォルト) は 0 です。これは、メモリー上限が常に制限されることを意味します。最小値を変更するには、次の手順に従います。

1. スーパーユーザーになります。

2. rcapadm に -c オプションを指定して実行して、メモリー上限を制限するときの物理メモリー使用率を設定します。

   # rcapadm -c percent

   percent は 0 から 100 までの値です。この値を大きくするほど、規制が小さくなります。つまり、上限が定義されたプロジェクトの作業負荷は、システムのメモリー使用率がこのしきい値を超えない限り、上限を適用されることなく実行できます。

現在の物理メモリーの使用率と上限実行しきい値を表示する方法については、メモリー使用率とメモリー上限実行しきい値の報告を参照してください。

動作間隔を設定する方法

rcapd の動作間隔では、rcapd が行う定期的な動作の間隔について説明しています。rcapadm を使用して動作間隔を設定するには、次の手順に従います。

1. スーパーユーザーになります。

2. -i オプションを使用して、動作間隔の値を設定します。

   # rcapadm -i interval=value,...,interval=value

すべての動作間隔の値の単位は秒です。

資源上限制御を有効にする方法

資源上限制御をシステムで有効にする方法は 2 つあります。

1. スーパーユーザーになります。

2. 次のどちらかの方法で資源上限デーモンを有効にします。

   • 資源上限デーモンを有効にして、ただちに起動し、かつ、システムをブートするたびに起動するようにするには、次のように入力します。

     # rcapadm -E

   • 資源上限デーモンをただちには起動せず、次回のブート時に有効にするには、-n オプションも指定します。

     # rcapadm -n -E

資源上限制御を無効にする方法

資源上限制御をシステムで無効にする方法は 2 つあります。

1. スーパーユーザーになります。

2. 次のどちらかの方法で資源上限デーモンを無効にします。

   • 資源上限デーモンを無効にして、ただちに停止し、かつ、システムをブートしても起動しないようにするには、次のように入力します。

     # rcapadm -D

   • 資源上限デーモンを停止せずに無効にするには、-n オプションも指定します。

     # rcapadm -n -D

rcapd を安全に無効にするには、rcapadm -D を使用します。資源上限デーモンを強制終了すると (kill(1) のマニュアルページを参照)、プロセスが停止状態のままになり、手動で再起動しなければならない場合があります。プロセスの実行を再開するには、prun コマンドを使用します。 詳細は、prun(1) のマニュアルページを参照してください。

rcapstat による報告の生成

資源上限制御の統計を報告するには、rcapstat を使用します。rcapstat コマンドを使用して報告を生成する方法については、rcapstat による資源使用率の監視を参照してください。この節では、報告の列見出しについても説明します。また、rcapstat(1) のマニュアルページも参照してください。

この節では、さまざまな目的の報告を生成する方法を、例を使用しながら説明します。

上限とプロジェクトの情報の報告

この例では、2 人のユーザーに関連付けられた 2 つのプロジェクトに、上限が定義されています。user1 の上限は 50M バイトで、user2 の上限は 10M バイトです。

次のコマンドは、5 つの報告を 5 秒間のサンプリング間隔で生成します。

user1machine% rcapstat 5 5
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M   50M    0K 3312K    0K
 78194   user2      1  2368K  1856K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1856K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K 

出力の最初の 3 行は 1 回目の報告です。ここには、2 つのプロジェクトに関する上限とプロジェクトの情報、および rcapd 起動以降のページング統計が記載されています。at と pg の列において、user1 にはゼロより大きな値が入っており、user2 にはゼロが入っています。これは、1 回目の報告の期間中、user1 は上限を超えたが、 user2 は超えなかったことを意味します。

2 回目以降の報告では、目立った活動はありません。

プロジェクトの RSS の監視

この例では、プロジェクト user1 の RSS が上限を超えています。

次のコマンドは、5 つの報告を 5 秒間のサンプリング間隔で生成します。

user1machine% rcapstat 5 5

    id project  nproc    vm   rss   cap    at avgat     pg  avgpg
376565   user1      3 6249M 6144M 6144M  690M  220M  5528K  2764K
376565   user1      3 6249M 6144M 6144M    0M  131M  4912K  1637K
376565   user1      3 6249M 6171M 6144M   27M  147M  6048K  2016K
376565   user1      3 6249M 6146M 6144M 4872M  174M  4368K  1456K
376565   user1      3 6249M 6156M 6144M   12M  161M  3376K  1125K

プロジェクト user1 は 3 つのプロセスを持っており、それぞれがアクティブに物理メモリーを使用しています。pg 列の正の値が示しているとおり、rcapd は、このプロジェクトのプロセスの物理メモリーの使用率を上限に合わせて下げようと、メモリーをページアウトし続けています。しかし、rcapd は RSS を上限値未満に保つことに成功していません。これは、rss 値が相応の減少を示していないことでわかります。作業負荷はメモリーをページアウトするとすぐにまたメモリーを使用しており、その結果、RSS の値がまた上がってしまいます。これは、プロジェクトの常駐メモリーがすべてアクティブに使用されており、かつ、作業セットサイズ (WSS) が上限よりも大きいことを意味します。そのため、rcapd は、上限に合わせて作業セットの一部をページアウトせざるを得ません。この状況では、次のうちのどれかが起きるまで、システムのページフォルト率および関連する入出力は高いままです。

• WSS が小さくなる

• 上限を上げる

• アプリケーションのメモリーアクセスパターンが変わる

この状況では、サンプリング間隔を短くすることで、RSS 値と上限値の差を小さくできる可能性があります。rcapd が作業負荷をサンプリングして上限を制限する頻度が上がるからです。

ページフォルトが発生するのは、新しいページを作成する必要があるとき、あるいは、システムがスワップデバイスからページをコピーする必要があるときです。

プロジェクトの作業セットサイズの決定

この例では、前の例と同じプロジェクトを使用します。

前の例では、プロジェクト user1 が自分に許可された上限よりも多くの物理メモリーを使用しているところを示しました。この例では、どれくらいのメモリーをプロジェクトの作業負荷が必要とするのかを示します。

user1machine% rcapstat 5 5
    id project  nproc    vm   rss   cap    at avgat     pg  avgpg
376565   user1      3 6249M 6144M 6144M  690M    0K   689M     0K
376565   user1      3 6249M 6144M 6144M    0K    0K     0K     0K
376565   user1      3 6249M 6171M 6144M   27M    0K    27M     0K
376565   user1      3 6249M 6146M 6144M 4872K    0K  4816K     0K
376565   user1      3 6249M 6156M 6144M   12M    0K    12M     0K
376565   user1      3 6249M 6150M 6144M 5848K    0K  5816K     0K
376565   user1      3 6249M 6155M 6144M   11M    0K    11M     0K
376565   user1      3 6249M 6150M   10G   32K    0K    32K     0K
376565   user1      3 6249M 6214M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K

サイクルの中ほどで、プロジェクト user1 の上限を 6G バイトから 10G バイトに上げました。値を上げることによって上限の制限が止まり、常駐セットサイズが上昇しました。常駐セットサイズを規制するのは、ほかのプロセスと、マシンのメモリー容量だけになりました。rss 列が、プロジェクトの作業セットサイズ (この例では 6247M バイト) を反映して安定する場合があります。この値が、このプロジェクトのプロセスがページフォルトを頻繁に起こさずに動作できる、上限の最小値です。

次の 2 つの図は、上限が 6G バイトと 10G バイトのときに、rcapd が user1 に与える影響を示しています。 サンプリング間隔である 5 秒ごとに、rcapd が作業負荷のメモリーの一部をページアウトすることによって、RSS が減り、入出力が増えます。ページアウトの直後、これらのページを必要とする作業負荷は、(動作し続ける限り) メモリーをページインします。このサイクルは、例の中ほどで上限を 10G バイトに上げるまで繰り返され、その後、RSS は 6.1G バイトで安定します。作業負荷の RSS が上限より低くなったため、これ以後ページングは発生しません。同様に、ページングに関連する入出力も止まります。このことは、vmstat (vmstat(1M)のマニュアルページを参照) コマンドまたは iostat ( iostat(1M)のマニュアルページ参照) コマンドで確認できます。以上のようにして、観察時にプロジェクトが行なっていた作業の実行には、6.1G バイトが必要であったと推論できます。

図 9–1 user1 の上限を WSS よりも大きくしたあとに RSS 値が安定する様子

図 9–2 ページインとページアウトの関係、および user1 の上限を上げたあとに入出力が安定する様子

メモリー使用率とメモリー上限実行しきい値の報告

rcapstat の -g オプションを使用すると、次のことを報告できます。

• 現在の物理メモリーの使用率 (システムにインストールされている物理メモリーに占めるパーセンテージ)

• rcapadm で設定されたシステムメモリー上限実行しきい値

-g オプションを使用すると、各サンプリング間隔に対応する報告の最後に、メモリー使用率と上限実行しきい値を示す行が出力されます。

# rcapstat -g
    id project   nproc    vm   rss   cap    at avgat   pg  avgpg
376565    rcap       0    0K    0K   10G    0K    0K   0K     0K
physical memory utilization: 55%   cap enforcement threshold: 0%
    id project   nproc    vm   rss   cap    at avgat   pg  avgpg
376565    rcap       0    0K    0K   10G    0K    0K   0K     0K
physical memory utilization: 55%   cap enforcement threshold: 0%

第 10 章 資源プール

この章では、マシン資源のパーティション分割に使用される資源プールについて説明します。資源プールを使用すると、作業負荷によって特定の資源が重複して消費されないように、作業負荷を分離することができます。このような方法で資源を確保すると、さまざまな作業負荷が混在するシステム上で予測どおりのパフォーマンスを得ることができます。

概要

資源プールは、プロセッサセットの構成やスケジューリングクラスの割り当て (オプション) に対して一貫した構成メカニズムを提供します。

図 10–1 資源プールのフレームワーク

資源プールは、複数のパーティションをグループ化することにより、ラベル付けされている作業負荷とハンドルを対応付けることができます。/etc/project データベースにある各プロジェクトのエントリは、そのエントリに対応付けられた資源プールを持つことができます。プロジェクトで開始される新しい作業は、適切なプールに結合されます。

資源プールメカニズムは主に、5 つ以上の CPU を搭載する大規模なマシンで使用されます。ただし、小規模なマシンでもこの機能を活用することができます。小規模なマシンでは、重要でない資源パーティションを共有するプールを作成できます。 重要な資源にだけ、専用のプールが使用されます。

資源プールを使用する場合

資源プールは、以下で説明するように、多くの管理作業に適用できる汎用メカニズムを提供します。

バッチ処理サーバー

プールの機能を使用して、1 つのサーバーを 2 つのプールに分割します。

一方のプールは、ログインセッションとタイムシェアリングユーザーによる対話型作業に使用されます。もう一方のプールは、バッチシステムを介して投入されるジョブに使用されます。

アプリケーションサーバーまたはデータベースサーバー

アプリケーションの要件に基づいて、対話型アプリケーション用の資源をパーティション分割します。

アプリケーションの段階的な調整

ユーザーが期待するサービスレベルを設定します。

最初は、目標とする最終的なサービスの一部だけを実行するマシンを導入することがあります。マシンをオンラインにしたときに、予約方式の資源管理メカニズムが確立していなければ、ユーザーがサービスに不満を持つ可能性があります。

たとえば、フェアシェアスケジューラは CPU の使用率を最適化します。ユーザーから見ると、1 つしかアプリケーションを実行していないマシンの応答時間は、複数のアプリケーションがロードされているマシンの応答時間に比べ、極端に速くなります。アプリケーションごとに個別のプールを用意することにより、各アプリケーションで使用可能な CPU 数の上限をあらかじめ設定してから、すべてのアプリケーションを運用することができます。

複雑なタイムシェアリングサーバー

多数のユーザーをサポートするサーバーをパーティション分割します。

サーバーのパーティション分割によって、ユーザーごとの応答が時間をより確実に予測できる分離メカニズムが提供されます。

ユーザーをグループに分割して個別のプールに結合し、フェアシェアスケジューラ (FSS) 機能を使用すれば、CPU 割り当てを調整して、優先順位を持つユーザーグループをサポートできます。このような割り当ては、ユーザーの役割や課金などに基づいて行えます。

定期的に変動する作業負荷

資源プールを使用して、変動する作業負荷に対応します。

サイトでの作業負荷の変動が月次、四半期、年次などの周期で予想できる場合があります。 このような変動がサイトで予想できる場合は、cron(1M) ジョブで pooladm を実行して、複数のプール構成を使い分けることができます。

リアルタイムアプリケーション

RT スケジューラと専用のプロセッサ資源を使用して、リアルタイムプールを作成します。

資源プールの管理

次の表に示すコマンドは、プール機能に対する主要な管理インタフェースを提供します。

ライブラリの API は、libpool(3LIB) で提供されます。プログラムからプール構成を操作するには、このライブラリを使用します。

プールのフレームワーク

資源プールのフレームワークは、マシンのビューを独自の構成ファイルに格納します。このファイルの格納場所は、プールのフレームワークの実装によって異なります。この構成ファイルは、プールのフレームワークにとってのマシンのビューを表します。この構成ファイルには、構成されたプールとパーティション分割可能な資源の編成に関する情報も含まれます。各プールには次のものが含まれます。

• プロセッサセットまたは CPU 資源のパーティションへの参照

• プールのデフォルトのスケジューリングクラスを示すプロパティ

システム上でのプールの実装

プールをシステム上に実装するには、次のどちらかの方法を使用します。

1. Solaris ソフトウェアが起動すると、init スクリプトは /etc/pooladm.conf ファイルが存在するかどうかをチェックします。このファイルが存在する場合は、pooladm が呼び出され、この構成をアクティブなプール構成にします。システムは、/etc/pooladm.conf で指定されている編成に従って、独自の構成ファイルを作成します。マシンの資源は指定どおりにパーティション分割されます。

2. Solaris 環境が起動しているときは、pooladm コマンドを使用して、プール構成が存在しない場合はプール構成を起動したり、プール構成を変更したりできます。デフォルトでは、pooladm は /etc/pooladm.conf の内容を使用します。ただし、別のディレクトリとファイル名を指定し、そのファイルを使用してプール構成を変更することもできます。

動的再構成の処理と資源プール

動的再構成 (DR) を使用すると、システムの実行中にハードウェアを再構成できます。DR は使用可能な資源量に影響を与えるので、プール機能を DR 操作に含めておく必要があります。DR 処理が開始されると、プールのフレームワークは構成の妥当性を検証します。

現在のプール構成が無効にならないかぎり、DR 処理は、独自の構成ファイルが更新されるまで実行を続けます。無効な構成とは、使用可能な資源でサポートできない構成のことです。

DR 処理によってプール構成が無効になった場合、操作は失敗し、メッセージログにメッセージが書き込まれます。構成処理を強制的に最後まで実行するには、DR の強制オプションを使用します。強制オプションで処理を続行すると、プール構成は、新しい資源構成に合うように変更されます。

プール構成の作成

構成ファイルには、システム上で作成されるプールに関する記述が含まれます。構成ファイルには、操作可能な構成要素と、そのリソースタイプが記述されています。

操作可能な構成要素については、poolcfg(1M) を参照してください。

構成ファイル /etc/pooladm.conf は、次の 2 つの方法で作成できます。

• poolcfg を使って現在のシステム上の資源を検出し、その結果を構成ファイルに記録します。

  この方法では、ファイルを簡単に作成できます。プール機能で操作できるシステム上のアクティブな資源とコンポーネントがすべて記録されます。資源には、既存のプロセッサセットの構成が含まれます。最後に、プロセッサセットの名前を変更したり、必要に応じてプールを作成したりして、構成を変更できます。

• poolcfg を使用して、新しいプール構成を作成します。

  この方法は、他のマシンの構成を作成する場合や、作成済みの構成を後で現在のマシンに適用する場合に使用します。

poolcfg または libpool を使用して、/etc/pooladm.conf ファイルを変更します。このファイルを直接編集しないでください。

検出によって構成を作成する方法

/usr/sbin/poolcfg コマンドの -c オプションに discover を指定して、プール構成ファイルを作成します。作成される /etc/pooladm.conf ファイルには、既存のプロセッサセットが含まれます。

1. スーパーユーザーになります。

2. 次のコマンドを入力します。

   # poolcfg -c discover

デフォルトのファイル名 /etc/pooladm.conf を使用する代わりに別のファイル名を指定することもできます。別のファイル名を指定すると、poolcfg コマンドは指定した別のファイルに対して実行されます。

たとえば、検出された構成を /tmp/foo ファイルに記録するには、次の手順に従います。

1. スーパーユーザーになります。

2. 次のコマンドを入力します。

   # poolcfg -c discover /tmp/foo

新しい構成を作成する方法

/usr/sbin/poolcfg コマンドの -c オプションの引数に create を指定して、tester というシステムに簡単な構成ファイルを作成します。-c オプションの引数に空白が含まれている場合は、引用符で囲んでください。

1. スーパーユーザーになります。

2. 次のコマンドを入力します。

   # poolcfg -c 'create system tester'

3. 構成ファイルの内容を読みやすい形式で表示します。

   # poolcfg -c info system tester int system.version 1 boolean system.bind-default true string system.comment

構成の変更方法

単純な構成を拡張するには、batch というプロセッサセットと batch というプールを作成して、両者を対応付けて結合します。-c オプションの引数に空白が含まれている場合は、引用符で囲んでください。

1. スーパーユーザーになります。

2. batch というプロセッサセットを作成します。

   # poolcfg -c 'create pset batch (uint pset.min = 2; uint pset.max = 10)'

3. batch というプールを作成します。

   # poolcfg -c 'create pool batch'

4. プロセッサセットとプールを対応付けて結合します。

   # poolcfg -c 'associate pool batch (pset batch)'

5. 対応付けた後の構成を表示します。

   # poolcfg -c info system tester int system.version 1 boolean system.bind-default true string system.comment pool batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment pset batch pset batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0

プールをスケジューリングクラスに対応付ける方法

プールをスケジューリングクラスに対応付けることで、プールに結合されているすべてのプロセスがこのスケジューラを使用できるようになります。このためには、pool.scheduler プロパティにスケジューリングクラスの名前を設定します。次の例は、batch というプールを FSS に対応付ける方法を示します。

1. スーパーユーザーになります。

2. batch プールを変更して、FSS に対応付けます。

   # poolcfg -c 'modify pool batch (string pool.scheduler="FSS")'

3. 対応付けた後の構成を表示します。

   # poolcfg -c info system tester int system.version 1 boolean system.bind-default true string system.comment pool batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0

poolcfg でコマンドファイルを使用する方法

poolcfg -f を使用すると、poolcfg コマンドの -c オプションに指定する引数をテキストファイルから入力できます。この手法は、一連の操作を 1 つずつ実行する場合に使用します。複数のコマンドを処理した場合でも、それらのコマンドがすべて正常に終了するまで、構成は更新されません。特に大規模な構成や複雑な構成の場合は、この手法を使用した方が、個々のサブコマンドを起動するよりも便利です。

1. 入力ファイルを作成します。

   $ cat> poolcmds.txt create system tester create pset batch (uint pset.min = 2; uint pset.max = 10) create pool batch associate pool batch (pset batch)

2. スーパーユーザーになります。

3. 次のコマンドを入力します。

   # /usr/sbin/poolcfg -f poolcmds.txt

プール構成の起動と終了

pooladm(1M) を使用して、特定のプール構成を起動したり、実行中のプール構成を終了したりします。

プール構成を起動する方法

デフォルトの静的構成ファイル /etc/pooladm.conf 内の構成を起動するには、「commit configuration」を意味する -c オプションを指定して、pooladm を実行します。

1. スーパーユーザーになります。

2. 次のコマンドを入力します。

   # /usr/sbin/pooladm -c

プール構成を終了する方法

実行中の構成とプロセッサセットなどの関連するすべての資源を削除するには、「remove configuration」を意味する -x オプションを使用します。

1. スーパーユーザーになります。

2. 次のコマンドを入力します。

   # /usr/sbin/pooladm -x

pooladm コマンドの -x オプションを使用すると、独自の動的構成ファイルだけでなく、その動的構成ファイルに対応付けられているすべての資源構成も削除されます。つまり、-x オプションは、無効なプール構成から回復するためのメカニズムを提供します。すべてのプロセスは、マシン上のすべての資源を共有します。

1 つのプロセッサセット内でスケジューリングクラスを混在させると、予期できない結果が生じる可能性があります。pooladm -x を使って無効な構成から回復する場合は、priocntl(1) を使用して、実行中のプロセスを別のスケジューリングクラスに移動する必要があります。

プールへの結合

実行中のプロセスをプールに結合するには、次の 2 つの方法を使用できます。

• poolbind(1M) コマンドを使用して、特定のプロセスを名前付き資源プールに結合する

• project(4) データベース内の project.pool 属性を使用して、新しいログインセッションや newtask(1) で起動されるタスクが結合されているプールを特定する

プロセスをプールに結合する方法

次の手順では、プロセス (現在のシェルなど) を手動で ohare というプールに結合します。

1. スーパーユーザーになります。

2. 次のコマンドを入力します。

   # poolbind -p ohare $$

タスクまたはプロジェクトをプールに結合する方法

タスクまたはプロジェクトをプールに結合するには、poolbind コマンドに -i オプションを指定します。次の例では、airmiles プロジェクト内のすべてのプロセスを laguardia プールに結合します。

1. スーパーユーザーになります。

2. 次のコマンドを入力します。

   # poolbind -i project -p laguardia airmiles

project 属性を使って新しいプロセスをプールに結合する方法

プロジェクト内の新しいプロセスを自動的にプールに結合するには、project.pool 属性を project データベース内の各エントリに追加します。

たとえば、studio と backstage という 2 つのプールを持つ構成が存在するものとします。/etc/project ファイルの内容は、次のとおりです。

user.paul:1024::::project.pool=studio
user.george:1024::::project.pool=studio
user.ringo:1024::::project.pool=backstage
passes:1027::paul::project.pool=backstage

この構成の場合、ユーザー paul によって起動されるプロセスは、デフォルトで studio プールに結合されます。

project 属性を使ってプロセスを別のプールに結合する方法

上記の構成を使用することにより、ユーザー paul は自分が起動したプロセスに結合されているプールを変更できます。newtask を使用して、passes プロジェクトで起動されるプロセスを backstage プールにも結合できます。

1. passes プロジェクトでプロジェクトを起動します。

   $ newtask -l -p passes

2. プロジェクトに結合されているプールを検証します。

   $ poolbind -q $$ process id 6384 : pool 'backstage'

第 11 章 資源管理の構成例

この章では、資源管理のフレームワークについて考察し、仮想的なサーバー統合プロジェクトについて説明します。この例では、5 つのアプリケーションを 1 つのシステムに統合します。対象となるアプリケーションは、それぞれ資源要件、ユーザー数、およびアーキテクチャが異なります。

統合前の構成

現在、各アプリケーションは、それぞれの要件を満たす専用サーバーに置かれています。次の表にアプリケーションとその特性を示します。

統合後の構成

次の構成を使用して、アプリケーションを 1 つのシステムに統合します。

• アプリケーションサーバーは、2 つの CPU から構成されるプロセッサセットを持つ

• アプリケーションサーバーのデータベースインスタンスとスタンドアロンのデータベースインスタンスは、4 つ以上の CPU から構成される 1 つのプロセッサセットに統合される。スタンドアロンのデータベースインスタンスはその資源の 75% が保証される

• テストおよび開発用のアプリケーションサーバーには IA スケジューリングクラスを適用して、UI の応答性を保証する。メモリーを制約して、不正なコードによる影響を低減する

• トランザクション処理サーバーには 2 つ以上の CPU から構成される専用のプロセッサセットを割り当てて、応答時間を短縮する

構成の作成

project データベースファイルを編集します。エントリを追加して必要な資源制御を実装し、ユーザーを資源プールにマップしたら、ファイルを表示します。

# cat /etc/project
.
.
.
user.app_server:2001:Production Application Server:::project.pool=appserver_pool
user.app_db:2002:App Server DB:::project.pool=db_pool;project.cpu-shares=(privileged,1,deny)
development:2003:Test and development::staff:project.pool=dev_pool;
  process.max-address-space=(privileged,536870912,deny)
user.tp_engine:2004:Transaction Engine:::project.pool=tp_pool
user.geo_db:2005:EDI DB:::project.pool=db_pool;project.cpu-shares=(privileged,3,deny)
.
.
.

開発チームはタスクを開発プロジェクトで実行する必要があります。これは、このプロジェクトへのアクセスをユーザーのグループ ID (GID) で制限しているためです。

pool.host という名前で入力ファイルを作成し、必要な資源プールの構成に使用します。次に、ファイルを表示します。

# cat pool.host

create system host
create pset default_pset (uint pset.min = 1)
create pset dev_pset (uint pset.max = 2)
create pset tp_pset (uint pset.min = 2)
create pset db_pset (uint pset.min = 4; uint pset.max = 6)
create pset app_pset (uint pset.min = 1; uint pset.max = 2)
create pool default_pool (string pool.scheduler="TS"; boolean pool.default = true)
create pool dev_pool (string pool.scheduler="IA")
create pool appserver_pool (string pool.scheduler="TS")
create pool db_pool (string pool.scheduler="FSS")
create pool tp_pool (string pool.scheduler="TS")
associate pool default_pool (pset default_pset)
associate pool dev_pool (pset dev_pset)
associate pool appserver_pool (pset app_pset)
associate pool db_pool (pset db_pset)
associate pool tp_pool (pset tp_pset)

次のコマンドを入力します。

# poolcfg -f pool.host

構成をアクティブにします。

# pooladm -c

システム上でフレームワークが有効になっています。

構成の表示

フレームワークの構成を表示するには、次のコマンドを入力します。

# pooladm
system host
        int system.version 1
        boolean system.bind-default true
        string system.comment

        pool default_pool
                boolean pool.default true
                boolean pool.active true
                int pool.importance 1
                string pool.comment
                string pool.scheduler TS
                pset default_pset

        pool dev_pool
                boolean pool.default false
                boolean pool.active true
                int pool.importance 1
                string pool.comment
                string pool.scheduler IA
                pset dev_pset

        pool appserver_pool
                boolean pool.default false
                boolean pool.active true
                int pool.importance 1
                string pool.comment
                string pool.scheduler TS
                pset app_pset

        pool db_pool
                boolean pool.default false
                boolean pool.active true
                int pool.importance 1
                string pool.comment
                string pool.scheduler FSS
                pset db_pset

        pool tp_pool
                boolean pool.default false
                boolean pool.active true
                int pool.importance 1
                string pool.comment
                string pool.scheduler TS
                pset tp_pset

        pset default_pset
                int pset.sys_id -1
                string pset.units population
                boolean pset.default true
                uint pset.max 4294967295
                uint pset.min 1
                string pset.comment
                boolean pset.escapable false
                uint pset.load 0
                uint pset.size 0

        pset dev_pset
                int pset.sys_id 1
                string pset.units population
                boolean pset.default false
                uint pset.max 2
                uint pset.min 0
                string pset.comment
                boolean pset.escapable false
                uint pset.load 0
                uint pset.size 0

        pset tp_pset
                int pset.sys_id 2
                string pset.units population
                boolean pset.default false
                uint pset.max 4294967295
                uint pset.min 2
                string pset.comment
                boolean pset.escapable false
                uint pset.load 0
                uint pset.size 0

        pset db_pset
                int pset.sys_id 3
                string pset.units population
                boolean pset.default false
                uint pset.max 6
                uint pset.min 4
                string pset.comment
                boolean pset.escapable false
                uint pset.load 0
                uint pset.size 0

        pset app_pset
                int pset.sys_id 4
                string pset.units population
                boolean pset.default false
                uint pset.max 2
                uint pset.min 1
                string pset.comment
                boolean pset.escapable false
                uint pset.load 0
                uint pset.size 0

フレームワークのグラフィック表示が続きます。

図 11–1 サーバー統合の構成

上記の図の db_pool では、スタンドアロンのデータベースインスタンスに CPU 資源の 75% が保証されています。

第 12 章 Solaris 管理コンソールの資源制御機能

この章では、Solaris 管理コンソールの資源制御機能とパフォーマンス監視機能について説明します。

このコンソールでは、システムのパフォーマンスを監視したり、プロジェクト、タスク、およびプロセスに資源制御の値を設定したりします。このコンソールは、何台ものシステムに渡って設定されている数百の構成パラメータを管理する際に、コマンド行インタフェース (CLI) の代わりとして使用できる便利で安全なツールです。各システムは個別に管理されます。このコンソールのグラフィカルインタフェースは、ユーザーの経験レベルに合った使い方ができます。

Solaris 管理コンソールの使用 (作業マップ)

概要

資源管理機能は、Solaris 管理コンソールの構成要素です。このコンソールは、GUI ベースの管理ツールのためのコンテナです。管理ツールはツールボックスと呼ばれるコレクションに格納されています。コンソールとその使用方法については、『Solaris のシステム管理 (基本編)』の「Solaris 管理コンソールの操作 (手順)」を参照してください。

コンソールとそのツール群のマニュアルは、コンソールのオンラインヘルプで参照できます。オンラインヘルプで参照できるマニュアルの内容については、『Solaris のシステム管理 (基本編)』の「Solaris 管理コンソール (概要)」を参照してください。

管理範囲

管理範囲とは、選択した管理ツールで使用するネームサービス環境のことです。資源制御機能とパフォーマンスツールを使用するときの管理範囲は、/etc/project ローカルファイルまたは NIS から選択します。

コンソールセッションで選択する管理範囲は、/etc/nsswitch.conf ファイルで特定される最も優先度の高いネームサービスと一致する必要があります。

パフォーマンスツール

パフォーマンスツールは、資源の使用状況を監視するために使用します。資源の使用状況をシステム単位で集計したり、プロジェクト単位または個人ユーザー単位で表示したりできます。

図 12–1 Solaris 管理コンソールのパフォーマンスツール

パフォーマンスツールにアクセスする方法

パフォーマンスツールは、ナビゲーション区画の「System Status」の下にあります。 パフォーマンスツールにアクセスするには、次の手順に従います。

1. ナビゲーション区画の「System Status」コントロール要素をクリックします。

   このコントロール要素は、ナビゲーション区画のメニュー項目を拡張するために使用します。

2. 「パフォーマンス (Performance)」コントロール要素をクリックします。

3. 「システム (System)」コントロール要素をクリックします。

4. 「概要 (Summary)」、「プロジェクト (Projects)」、または「ユーザー (Users)」をダブルクリックします。

   何を選択するかは、監視する対象によって異なります。

システム単位の監視

次の属性の値が表示されます。

プロジェクト単位またはユーザー単位の監視

次の属性の値が表示されます。

「資源制御 (Resource Controls)」タブ

資源制御を使用して、プロジェクトを資源制約の集合と対応付けることができます。これらの制約によって、プロジェクトのコンテキストで実行するタスクまたはプロセスの資源許容量が決定されます。

図 12–2 Solaris 管理コンソールの「資源制御 (Resource Controls)」タブ

「資源制御 (Resource Controls)」タブへのアクセス方法

「資源制御 (Resource Controls)」タブは、ナビゲーション区画の「System Configuration」の下にあります。 「資源制御 (Resource Controls)」にアクセスするには、次の手順に従います。

1. ナビゲーション区画の「System Configuration」コントロール要素をクリックします。

2. 「プロジェクト (Projects)」をダブルクリックします。

3. コンソールのメインウィンドウにあるプロジェクトをクリックして選択します。

4. 「アクション (Action)」メニューから「プロパティ (Properties)」を選択します。

5. 「資源制御 (Resource Controls)」タブをクリックします。

   プロセス、プロジェクト、およびタスクの資源制御の値を表示、編集、または削除します。

設定可能な資源制御

使用可能な資源制御のリストを表示するには、コンソールヘルプの「資源制御」または 使用可能な資源制御を参照してください。

値の設定

プロセス、プロジェクト、およびタスクの資源制御の値を表示、編集、または削除できます。 これらの操作は、コンソールのダイアログボックスで実行します。

資源制御 (Resource Control) と値 (Value) は、コンソールに表形式で表示されます。資源制御 (Resource Control) の欄には、設定可能な資源制御の一覧が表示されます。値 (Value) の欄には、各資源制御に対応付けられているプロパティが表示されます。表内では、これらの値は括弧で囲まれており、コンマで区切られたプレーンテキストとして表示されます。括弧内の値は「action 文節」を示します。各 action 文節は、しきい値、特権レベル、シグナル、および特定のしきい値に対応付けられているローカルアクションで構成されます。 各資源制御は複数の action 文節を持つことができ、各 action 文節もコンマで区切られます。

実行中のシステムでは、コンソールから project データベースに加えた変更は、プロジェクトで起動される新しいタスクに対してだけ有効になります。

関連項目

プロジェクトとタスクについては、第 5 章「プロジェクトとタスク」を参照してください。資源制御については、第 7 章「資源制御」を参照してください。フェアシェアスケジューラ (FSS) については、第 8 章「フェアシェアスケジューラ」を参照してください。