Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)

パート I 資源管理

このパートでは、Solaris 10 資源管理について紹介します。Solaris 10 資源管理を使用すると、利用可能なシステム資源をアプリケーションでどのように使用するかを制御できます。

第 1 章 Solaris 10 資源管理の紹介

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

プロセッサ時間などのコンピュータ資源を割り当てます
割り当てた資源の使用状況を監視し、必要に応じて調整します
解析、課金、および容量計画のために拡張アカウンティング情報を生成します

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

資源管理の概要

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

特定の資源へのアクセスを制限します
優先順位に基づいて作業負荷に資源を提供します
作業負荷を互いに分離します

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

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

あるアプリケーションに対して、資源の割り当てを拒否したり、ほかのアプリケーションに許可されているよりも大きい割り当てを与えたりします
特定の割り当てを個別にではなく一括して行います

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

アプリケーションが際限なく資源を浪費するのを防止します
外部イベントに基づいてアプリケーションの優先順位を変更します
一連のアプリケーションに資源の使用を保証する一方で、システムの使用率を最大限に高めます

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

システム上で競合する作業負荷の特定
競合しない作業負荷と、主要な作業負荷に影響を与えるような性能要件を伴った作業負荷との区別

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

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

資源の分類

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

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

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

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

資源管理の制御機構

Solaris オペレーティングシステムでは、制約、スケジューリング、区分の 3 種類の制御機構を使用できます。

制約機構

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

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

スケジューリング機構

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

区分機構

区分は、作業負荷をシステム上で使用可能な資源の一部に結合 (バインド) するために使用されます。資源と結合することにより、作業負荷は常に一定量の資源を使用できることが保証されます。第 12 章資源プール (概要)で説明する資源プール機能を使用すれば、作業負荷をマシンの特定の部分に制限できます。

区分を使用する構成では、システム全体が過剰使用されるのを防ぐことができます。ただし、この方法では、高い使用率の達成は難しくなります。プロセッサなど、予約済みの資源に結合されている作業負荷がアイドル状態になっている場合でも、別の作業負荷がその資源を使用することはできないためです。

資源管理構成

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

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

Solaris ゾーンとの相互動作

資源管理機能を Solaris ゾーンと組み合わせて使用すると、アプリケーション環境をさらに細かく調整できます。資源管理機能とゾーンの相互動作については、このマニュアルの該当部分で説明します。

資源管理機能を使用する場合

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

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

サーバーを統合する場合

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

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

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

1 台のマシンに複数の Web サーバーを配置します。各 Web サイトの資源消費を制御し、各サイトをほかのサイトで起こる可能性のある過剰使用から保護します。
欠陥のある CGI (Common Gateway Interface) スクリプトが CPU 資源を浪費するのを防止します。
不正な動作をするアプリケーションによって引き起こされる、仮想メモリーのリークを防止します。
顧客のアプリケーションが、同じサイトで実行されている別の顧客のアプリケーションの影響を受けないようにします。
同一マシン上で異なるレベルまたはクラスのサービスを提供します。
課金目的でアカウンティング情報を取得します。

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

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

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

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

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

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

タスク	説明	説明
システム上の作業負荷を特定し、各作業負荷をプロジェクト別に分類します。	`/etc/project` ファイル、NIS マップ、または LDAP ディレクトリサービス内にプロジェクトエントリを作成します。	「`project` データベース」
システム上の作業負荷に優先順位を付けます。	どのアプリケーションが重要かを判定します。重要な作業負荷には資源への優先的なアクセスが必要になる場合があります。	サービスの目的を考慮してください。
システム上で実際のアクティビティーを監視します。	パフォーマンスツールを使用して、システムで実行されている作業負荷の現在の資源消費量を表示します。その上で、特定の資源へのアクセスを制限する必要があるかどうか、あるいは特定の作業負荷をほかの作業負荷から分離する必要があるかどうかを判定できます。	「システム単位の監視」および cpustat(1M)、iostat(1M)、mpstat(1M)、prstat(1M)、sar(1)、および vmstat(1M) のマニュアルページ
システムで実行されている作業負荷を一時的に変更します。	変更可能な設定値を決めるには、Solaris システムで使用できる資源制御を参照します。タスクまたはプロセスが実行している間は、コマンド行から値を更新できます。	「使用可能な資源制御」、「資源制御値に対応付けられた大域アクションと局所アクション」、「動作中のシステム上の資源制御値を一時的に更新する」、および rctladm(1M) と prctl(1) のマニュアルページ
`project` データベースまたはネームサービスプロジェクトデータベース内のプロジェクトエントリごとに資源制御とプロジェクト属性を設定します。	`/etc/project` ファイルまたはネームサービスプロジェクトデータベース内の各プロジェクトエントリには、資源制御または属性を 1 つ以上含めることができます。これらの資源制御は、そのプロジェクトに属するタスクとプロセスを制約します。資源制御で指定する各しきい値に対しては、その値に達したときに行われるアクションを 1 つ以上対応付けることができます。資源制御は、コマンド行インタフェースを使って設定できます。一部の構成パラメータは、Solaris 管理コンソールでも設定できます。	「`project` データベース」、「ローカルの `/etc/project` ファイルの形式」、「使用可能な資源制御」、「資源制御値に対応付けられた大域アクションと局所アクション」、および第 8 章公平配分スケジューラ (概要)
プロジェクト内のプロセスの集合が消費する物理メモリーの容量に上限を設けます。	資源上限デーモンは、`/etc/project` ファイルでプロジェクトの `rcap.max-rss` 属性に指定されたとおり、物理メモリーの資源上限を制限します。	「`project` データベース」および第 10 章資源上限デーモンによる物理メモリーの制御 (概要)
資源プール構成を作成します。	資源プールは、プロセッサなどのシステム資源を区分する手段を提供し、再起動時にもそのパーティションを保持します。`/etc/project` ファイルの各エントリに `project.pool` 属性を 1 つ追加できます。	「`project` データベース」および第 12 章資源プール (概要)
公平配分スケジューラ (FSS) をデフォルトのシステムスケジューラとして設定します。	単一の CPU システムまたはプロセッサセット内のすべてのユーザープロセスが同じスケジューリングクラスに属するようにします。	「FSS の構成」および dispadmin(1M) のマニュアルページ
拡張アカウンティング機能を起動し、タスクまたはプロセスに基づき資源消費を監視して記録します。	拡張アカウンティングデータを使って現在の資源制御を評価し、将来の作業負荷のための容量要件を計画します。システム全体の総使用状況を追跡できます。複数のシステムに渡って相互に関連しあう作業負荷について完全な使用統計を取得するために、プロジェクト名は複数のマシンで共有できます。	「プロセス、タスク、およびフローの拡張アカウンティングを起動する方法」および acctadm(1M) のマニュアルページ
(省略可能) 構成をさらに調整する必要がある場合は、引き続きコマンド行から値を変更できます。値は、タスクまたはプロセスの実行中でも変更できます。	既存のタスクに対しては、プロジェクトを再起動しなくても、変更を一時的に適用できます。満足のいく性能が得られるまで値を調整します。次に、`/etc/project` ファイルまたはネームサービスのプロジェクトデータベースで現在の値を更新します。	「動作中のシステム上の資源制御値を一時的に更新する」および rctladm(1M) と prctl(1) のマニュアルページ
(省略可能) 拡張アカウンティングデータを取得します。	アクティブなプロセスおよびタスクの拡張アカウンティングレコードを書き込みます。作成されるファイルは、計画、チャージバック、および課金のために使用できます。`libexacct` への Perl (Practical Extraction and Report Language) インタフェースを使用して、報告および抽出用のカスタムスクリプトを作成することもできます。	wracct(1M) のマニュアルページおよび「`libexacct` に対する Perl インタフェース」

第 2 章プロジェクトとタスク (概要)

この章では、Solaris の資源管理機能のうち、プロジェクトおよびタスク機能について説明します。プロジェクトとタスクは、作業負荷にラベル付けを行い、ほかの作業負荷と区別するために使用されます。

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

プロジェクトとタスクの機能の使用方法については、第 3 章プロジェクトとタスクの管理を参照してください。

Solaris 10 におけるプロジェクトデータベースと資源制御コマンドの新機能

Solaris 10 の具体的な拡張内容は次のとおりです。

資源制御の値およびコマンドで、倍率値と単位修飾子をサポート
プロジェクト属性のフィールドの検証と操作性が向上
prctl コマンドおよび projects コマンドの出力形式を改訂し、新しいオプションを追加
useradd コマンドを使ってユーザーのデフォルトプロジェクトを設定する機能と、usermod コマンドと passmgmt コマンドを使って情報を変更する機能

この章と第 6 章資源制御 (概要)に含まれている情報に加え、次のマニュアルページも参照してください。

Solaris 10 5/08 の拡張機能では、projmod コマンドに -A オプションが追加されました。「プロジェクトとタスクで使用するコマンド」を参照してください。

Solaris 10 の新機能の全一覧および Solaris リリースについての説明は、『Oracle Solaris 10 9/10 の新機能』を参照してください。

プロジェクトとタスクの機能

作業負荷の応答性を最適化するには、まず解析対象のシステム上で実行中の作業負荷を特定できなければなりません。この情報は、プロセス指向の手法とユーザー指向の手法のどちらか一方だけを使用して取得できるものではありません。Solaris システムでは、作業負荷を区別して特定するための 2 つの追加機能を利用できます。プロジェクトとタスクです。「プロジェクト」は、関連した作業に対してネットワーク全体で適用される管理識別子を与えます。「タスク」は、プロセスのグループを、作業負荷の構成要素を表す管理しやすいエンティティーにまとめます。

project ネームサービスデータベースで指定された制御は、プロセス、タスク、およびプロジェクトに対して設定されます。プロセスの制御とタスクの制御は fork および settaskid システムコールを通して継承されるので、これらの制御は同じプロジェクト内に作成されるすべてのプロセスとタスクに継承されます。これらのシステムコールについては、fork(2) および settaskid(2) のマニュアルページを参照してください。

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

プロジェクト識別子

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

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

システムにログインするには、そのユーザーにデフォルトのプロジェクトが割り当てられている必要があります。ユーザーは、そのプロジェクトで指定されたユーザーリストやグループリストに含まれていない場合でも、自動的にそのデフォルトプロジェクトのメンバーになります。

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

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

ユーザーが、/etc/user_attr 拡張ユーザー属性データベースで定義されている project 属性のエントリを持っている場合は、その project 属性の値がデフォルトプロジェクトになります。user_attr(4) のマニュアルページを参照してください。
user.user-id という名前のプロジェクトが project データベースにある場合は、そのプロジェクトがデフォルトプロジェクトになります。詳細は、project(4) のマニュアルページを参照してください。
group. group-name というプロジェクトが project データベースにあり、group-name がユーザーのデフォルトのグループ名 (passwd ファイルで指定されている) である場合は、そのプロジェクトがデフォルトプロジェクトになります。passwd ファイルについては、passwd(4) のマニュアルページを参照してください。
project データベースに default という特別なプロジェクトがある場合は、そのプロジェクトがデフォルトプロジェクトになります。

このロジックは getdefaultproj() ライブラリ関数が提供します。詳細は、getprojent(3PROJECT) のマニュアルページを参照してください。

`useradd` 、`usermod`、および `passmgmt` コマンドによるユーザー属性の設定

次のコマンドに -K オプションと key=value ペアを付けて使用すると、ローカルファイル内のユーザー属性を設定できます。

passmgmt: ユーザー情報を変更する
useradd: ユーザーのデフォルトプロジェクトを設定する
usermod: ユーザー情報を変更する

ローカルファイルには、次のようなものがあります。

/etc/group
/etc/passwd
/etc/project
/etc/shadow
/etc/user_attr

NIS などのネットワークネームサービスを使ってローカルファイルに追加エントリを補足する場合、これらのコマンドでは、ネットワークネームサービスで指定された情報を変更することはできません。ただし、これらのコマンドを使用すると、次の内容を外部の「ネームサービスデータベース」と照合して検証できます。

ユーザー名 (または役割) の一意性
ユーザー ID の一意性
指定されたグループ名の存在

詳細は、passmgmt(1M)、useradd(1M)、usermod(1M)、および user_attr(4) のマニュアルページを参照してください。

`project` データベース

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

注 –

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

PAM サブシステム

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

プロジェクト用のアカウント管理 PAM モジュールについては、pam_projects(5) のマニュアルページを参照してください。PAM の概要については、『Solaris のシステム管理 (セキュリティサービス)』の第 17 章「PAM の使用」を参照してください。

ネームサービス構成

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

project: files [nis] [ldap]

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

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

ローカルの `/etc/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

リソース制御など、名前と値の対をセミコロンで区切ったリスト (第 6 章資源制御 (概要)を参照)。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 ファイルに資源制御と属性を追加することもできます。

プロジェクトの資源制御を追加する方法については、「資源制御の設定」を参照してください。
資源上限デーモン (rcapd(1M) を参照) を使用して物理メモリー資源の上限をプロジェクトに対して定義する方法については、「プロジェクトの物理メモリーの使用率を制限する属性」を参照してください。
プロジェクトのエントリに project.pool 属性を追加する方法については、「構成の作成」を参照してください。

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 編)』の第 4 章「ネットワーク情報サービス (NIS) (概要)」を参照してください。

LDAP のプロジェクト構成

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

project: ldap files

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

タスク識別子

プロジェクトへのログインが成功するたびに、ログインプロセスを含む新しい「タスク」が作成されます。タスクは、時間をかけて行われる一連の作業を表すプロセスです。また、タスクは「作業負荷の構成要素」と考えることもできます。各タスクには、自動的にタスク ID が割り当てられます。

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

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

この図では、1 つのプロジェクトに 3 つのタスクが関連付けられており、各タスクの下に 2 〜 4 つのプロセスがあります。

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

プロジェクトへの参加が発生するたびに、タスクが作成されます。タスクは、次のアクション、コマンド、および関数によって作成されます。

ログイン
cron
newtask
setproject
su

次のいずれかの方法で、最終的なタスクを作成できます。これ以降は、新しいタスクを作成しようとすると失敗します。

newtask コマンドに -F オプションを付けて実行します。
project ネームサービスデータベースで、プロジェクトに task.final 属性を設定します。setproject によってそのプロジェクト内に作成されるすべてのタスクに、TASK_FINAL フラグが設定されます。

詳細は、login(1)、newtask(1)、cron(1M)、su(1M)、および setproject(3PROJECT) のマニュアルページを参照してください。

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

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

次の表に示すコマンドは、プロジェクトとタスクの機能を管理するための主要なインタフェースとなります。

マニュアルページ	説明
projects(1)	ユーザーのプロジェクトメンバーシップを表示します。`project` データベース内のプロジェクトを一覧表示します。特定のプロジェクトについて情報を表示します。プロジェクト名が指定されていない場合は、すべてのプロジェクトについて情報を表示します。`projects` コマンドに `-l` オプションを付けて実行すると、詳細情報が出力されます。
newtask(1)	ユーザーのデフォルトのシェルまたは指定されたコマンドを実行し、指定されたプロジェクトが所有する新しいタスクに実行コマンドを配置します。また、`newtask` は、実行中のプロセスに結合するタスクとプロジェクトを変更するためにも使用できます。`-F` オプションを付けて実行すると、最終的なタスクを作成できます。
passmgmt(1M)	パスワードファイル内の情報を更新します。`-K` `key=value` オプションを付けて実行すると、ローカルファイル内のユーザー属性に値を追加したり、ローカルファイル内のユーザー属性を置換したりできます。
projadd(1M)	`/etc/project` ファイルに新しいプロジェクトエントリを追加します。`projadd` コマンドは、ローカルシステム上にだけプロジェクトエントリを作成します。`projadd` は、ネットワークネームサービスから提供される情報は変更できません。デフォルトファイル `/etc/project` 以外のプロジェクトファイルを編集する場合に使用できます。`project` ファイルの構文検査機能を提供します。プロジェクト属性の検証と編集を行います。倍率値をサポートします。
projmod(1M)	ローカルシステム上のプロジェクトの情報を変更します。`projmod` は、ネットワークネームサービスから提供される情報は変更できません。ただし、このコマンドは、外部のネームサービスに対してプロジェクト名とプロジェクト ID の一意性を確認します。デフォルトファイル `/etc/project` 以外のプロジェクトファイルを編集する場合に使用できます。`project` ファイルの構文検査機能を提供します。プロジェクト属性の検証と編集を行います。新しい属性の追加、属性の値の追加、または属性の削除に使用できます。倍率値をサポートします。 Solaris 10 5/08 リリース以降は、`-A` オプションを付けて実行すると、プロジェクトデータベース内にある資源制御値をアクティブなプロジェクトに適用できます。`prctl` コマンドによって手動で設定された値など、`project` ファイルで定義されている値と一致しない既存の値は削除されます。
projdel(1M)	ローカルシステムからプロジェクトを削除します。`projdel` は、ネットワークネームサービスから提供される情報は変更できません。
useradd(1M)	デフォルトプロジェクトの定義をローカルファイルに追加します。`-K` `key=value` オプションを付けて実行すると、ユーザー属性を追加したり置換したりできます。
userdel(1M)	ローカルファイルからユーザーのアカウントを削除します。
usermod(1M)	システムにあるユーザーのログイン情報を変更します。`-K` `key=value` オプションを付けて実行すると、ユーザー属性を追加したり置換したりできます。

第 3 章プロジェクトとタスクの管理

この章では、Solaris の資源管理機能のうち、プロジェクトおよびタスク機能の使用方法について説明します。

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

プロジェクトとタスクの機能の概要については、第 2 章プロジェクトとタスク (概要)を参照してください。

注 –

これらの機能をゾーンがインストールされている Solaris システムで使用する場合は、非大域ゾーンでこれらのコマンドを実行すると、プロセス ID を受け取るシステムコールインタフェースを通して、同じゾーン内のプロセスだけが認識されます。

プロジェクトとタスクの管理 (作業マップ)

タスク	説明	説明
プロジェクトとタスクで使用するコマンドとオプションの例を表示します。	タスク ID とプロジェクト ID を表示し、システムで現在実行されているプロセスとプロジェクトについて各種の統計情報を表示します。	「コマンドとコマンドオプションの例」
プロジェクトを定義します。	`/etc/project` ファイルにプロジェクトエントリを追加し、そのエントリの値を変更します。	「プロジェクトを定義して現在のプロジェクトを表示する方法」
プロジェクトを削除します。	`/etc/project` ファイルからプロジェクトエントリを削除します。	「`/etc/project` ファイルからプロジェクトを削除する方法」
`project` ファイルまたはプロジェクトデータベースを検証します。	`/etc/project` ファイルの構文を検査します。または、外部のネームサービスと照合してプロジェクト名およびプロジェクト ID の一意性を確認します。	「`/etc/project` ファイルの内容を検証する方法」
プロジェクトのメンバーシップ情報を取得します。	起動中のプロセスの現在のプロジェクトメンバーシップを表示します。	「プロジェクトのメンバーシップ情報を取得する方法」
新しいタスクを作成します。	`newtask` コマンドを使用して、特定のプロジェクトに新しいタスクを作成します。	「新しいタスクを作成する方法」
実行中のプロセスを別のタスクとプロジェクトに関連付けます。	指定されたプロジェクト内の新しいタスク ID にプロセス番号を関連付けます。	「実行中のプロセスを新しいタスクに移動する方法」
プロジェクト属性を追加し、操作します。	プロジェクトデータベースの管理コマンドを使用して、プロジェクト属性の追加、編集、検証、および削除を行います。	「プロジェクト属性の編集と検証」

コマンドとコマンドオプションの例

この節では、プロジェクトとタスクで使用するコマンドとオプションの例を示します。

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

`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 コマンドと pkill コマンドに -J オプションを付けて実行します。

# pgrep -J projidlist
# pkill -J projidlist

特定のリスト内のタスク ID と一致するプロセスだけを表示するには、pgrep コマンドと pkill コマンドに -T オプションを付けて実行します。

# pgrep -T taskidlist
# pkill -T taskidlist

`prstat` コマンド

システムで現在実行中のプロセスとプロジェクトのさまざまな統計情報を表示するには、prstat コマンドに -J オプションを付けて実行します。

% 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 オプションを付けて実行します。

% 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 コマンドは、ログインのシミュレーションの一環として、新しいタスクを作成することによってターゲットユーザーのデフォルトプロジェクトに参加します。

su コマンドを使用してユーザーのデフォルトプロジェクトを切り替えるには、次のように入力します。

# su user

プロジェクトの管理

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

次の例は、projadd コマンドを使用してプロジェクトエントリを追加し、projmod コマンドを使用してそのエントリを変更する方法を示します。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

projects -l を使用して、システムのデフォルトの /etc/project ファイルを表示します。

# projects -l
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::system
        projid : 0
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
user.root
        projid : 1
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
noproject
        projid : 2
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
default
        projid : 3
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
group.staff
        projid : 10
        comment: ""
        users  : (none)
        groups : (none)
        attribs:

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

再度 /etc/project ファイルを表示します。

# projects -l
system
        projid : 0
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
user.root
        projid : 1
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
noproject
        projid : 2
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
default
        projid : 3
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
group.staff
        projid : 10
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
booksite
        projid : 4113
        comment: ""
        users  : mark
        groups : (none)
        attribs:

comment フィールドにプロジェクトを説明するコメントを追加します。
# projmod -c `Book Auction Project' booksite

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

# projects -l
system
        projid : 0
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
user.root
        projid : 1
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
noproject
        projid : 2
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
default
        projid : 3
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
group.staff
        projid : 10
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
booksite
        projid : 4113
        comment: "Book Auction Project"
        users  : mark
        groups : (none)
        attribs:

参照

プロジェクト、タスク、およびプロセスをプールに結合する方法については、「プール属性の設定とプールへの結合」を参照してください。

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

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

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

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

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

# projects -l
system
        projid : 0
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
user.root
        projid : 1
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
noproject
        projid : 2
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
default
        projid : 3
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
group.staff
        projid : 10
        comment: ""
        users  : (none)
        groups : (none)
        attribs:

ユーザー名 mark でログインして、projects と入力し、このユーザーに割り当てられているプロジェクトを表示します。
# su - mark # projects default

`/etc/project` ファイルの内容を検証する方法

編集オプションが指定されていない場合、projmod コマンドは project ファイルの内容を検証します。

NIS マップを検証するには、スーパーユーザーとして次のように入力します。

# ypcat project | projmod -f —

注 –

ypcat project | projmod -f — コマンドはまだ実装されていません。

/etc/project ファイルの構文を検査するには、次のように入力します。

# projmod -n

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

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

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

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

作成先となるプロジェクト booksite のメンバーとしてログインします。

booksite プロジェクト内に新しいタスクを作成します。それには、システムのタスク ID を取得するための -v (冗長) オプションを指定して newtask コマンドを実行します。
machine% newtask -v -p booksite 16
newtask を実行すると、指定したプロジェクト内に新しいタスクが作成され、そのタスクにユーザーのデフォルトのシェルが置かれます。

起動中のプロセスの現在のプロジェクトメンバーシップを表示します。
machine% id -p uid=100(mark) gid=1(other) projid=4113(booksite)
今度は、プロセスが新しいプロジェクトのメンバーになっています。

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

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

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

注 –
プロセスの所有者または新しいプロジェクトのメンバーであれば、この手順は省略できます。

book_catalog プロセスのプロセス ID を取得します。
# pgrep book_catalog 8100

プロセス 8100 を、新しいタスク ID を使って booksite プロジェクトに関連付けます。
# newtask -v -p booksite -c 8100 17
-c オプションは、newtask が指定された既存のプロセスに対して動作することを指定します。

タスクとプロセス ID の対応を確認します。
# pgrep -T 17 8100

プロジェクト属性の編集と検証

プロジェクトデータベースの管理コマンド projadd および projmod を使用して、プロジェクト属性を編集できます。

-K オプションは、属性の置換リストを指定します。属性はセミコロン (;) で区切られます。-K オプションを -a オプションとともに使用すると、その属性または属性値が追加されます。-K オプションを -r オプションとともに使用すると、その属性または属性値が削除されます。-K オプションを -s オプションとともに使用すると、その属性または属性値が置換されます。

属性と属性値をプロジェクトに追加する方法

プロジェクトの属性に値を追加するには、projmod コマンドに -a オプションと -K オプションを付けて実行します。属性が存在しない場合は、新たに作成されます。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プロジェクト myproject 内に task.max-lwps 資源制御属性を値なしで追加します。プロジェクトに加わるタスクでは、その属性にシステム値だけが設定されます。
# projmod -a -K task.max-lwps myproject

その後、プロジェクト myproject 内の task.max-lwps に値を追加できます。この値は、特権レベル、しきい値、およびしきい値に達したときのアクションから成ります。
# projmod -a -K "task.max-lwps=(priv,100,deny)" myproject

資源制御は複数の値を持つことができるので、同じオプションを使用して、既存の値リストに別の値を追加できます。
# projmod -a -K "task.max-lwps=(priv,1000,signal=KILL)" myproject
複数の値はコンマで区切られます。task.max-lwps エントリはこの時点で次のようになっています。
task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

属性値をプロジェクトから削除する方法

この手順では次の値を仮定します。

task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プロジェクト myproject 内の資源制御 task.max-lwps から属性値を削除するには、projmod コマンドに -r オプションと -K オプションを付けて実行します。
# projmod -r -K "task.max-lwps=(priv,100,deny)" myproject
task.max-lwps が次のように複数の値を持っているとします。
task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)
この場合は、最初に一致する値が削除されます。したがって、結果は次のようになります。
task.max-lwps=(priv,1000,signal=KILL)

資源制御属性をプロジェクトから削除する方法

資源制御 task.max-lwps をプロジェクト myproject から削除するには、projmod コマンドに -r オプションと -K オプションを付けて実行します。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

属性 task.max-lwps とそのすべての値を、プロジェクト myproject から削除します。
# projmod -r -K task.max-lwps myproject

プロジェクトの属性と属性値を置換する方法

プロジェクト myproject 内の資源制御 task.max-lwps の属性値を別の値で置換するには、projmod コマンドに -s オプションと -K オプションを付けて実行します。属性が存在しない場合は、新たに作成されます。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

task.max-lwps の現在の値を、次に示す新しい値で置換します。

# projmod -s -K "task.max-lwps=(priv,100,none),(priv,120,deny)" myproject

結果は次のようになります。

task.max-lwps=(priv,100,none),(priv,120,deny)

資源制御属性の既存の値を削除する方法

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

task.max-lwps の現在の値をプロジェクト myproject から削除するには、次のように入力します。
# projmod -s -K task.max-lwps myproject

第 4 章拡張アカウンティング (概要)

プロジェクトおよびタスク機能 (第 2 章プロジェクトとタスク (概要)で説明) を使って作業負荷にラベル付けを行い、分離することにより、作業負荷ごとの資源消費を監視できます。「拡張アカウンティング」サブシステムを使用すると、プロセスとタスクの両方について詳細な資源消費統計情報を取得できます。

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

拡張アカウンティングの使用を開始する場合は、「プロセス、タスク、およびフローの拡張アカウンティングを起動する方法」に進んでください。

Solaris 10 における拡張アカウンティングの新機能

プロセスアカウンティングの mstate データを生成できるようになりました。「使用可能なアカウンティング資源を表示する方法」を参照してください。

Solaris 10 の新機能の全一覧および Solaris リリースについての説明は、『Oracle Solaris 10 9/10 の新機能』を参照してください。

拡張アカウンティングの紹介

拡張アカウンティングサブシステムは、行われた作業の対象プロジェクトの使用状況レコードにラベル付けします。また、拡張アカウンティングを IPQoS (Internet Protocol Quality of Service、IP サービス品質) フローアカウンティングモジュール (『Solaris のシステム管理 (IP サービス)』の第 36 章「フローアカウンティングの使用と統計情報の収集 (手順)」を参照) と組み合わせて、システム上のネットワークフロー情報を取得することもできます。

資源管理機構を適用する前に、まず、さまざまな作業負荷がシステムに対して行う資源消費要求の特徴をつかむ必要があります。Solaris オペレーティングシステムの拡張アカウンティング機能を利用すると、タスクベース、プロセスベース、または IPQoS flowacct モジュールが提供するセレクタベースで、システムやネットワークの資源消費を記録する柔軟性が得られます。詳細は、ipqos(7IPP) のマニュアルページを参照してください。

システムの使用状況をリアルタイムで計測するオンライン監視ツールとは異なり、拡張アカウンティング機能を使用すると、使用状況の履歴を調べることができます。その上で、将来の作業負荷の容量要件を算定できます。

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

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

Solaris オペレーティングシステムの拡張アカウンティング機能は、バージョン番号が付けられた拡張ファイル形式を使用してアカウンティングデータを格納します。このデータ形式を使用するファイルは、添付のライブラリ libexacct (libexacct(3LIB) のマニュアルページを参照) で提供される API を使ってアクセスまたは作成できます。作成されたファイルは、拡張アカウンティング機能を使用できる任意のプラットフォーム上で解析でき、データを容量計画や課金に使用できます。

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

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

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

このフロー図は、メンバープロセスの総資源使用状況が、タスク完了時にレコードに取り込まれる方法を示しています。

拡張可能な形式

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

注 –

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

`exacct` レコードとその形式

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

他社製の exacct ファイルを作成できるようにします。
putacct システムコールを使ってカーネルアカウンティングファイルに埋め込むためのタグ付けレコードを作成できるようにします (getacct(2) のマニュアルページを参照)。

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

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

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

注 –

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

ゾーンがインストールされている Solaris システムでの拡張アカウンティングの使用

拡張アカウンティングサブシステムを大域ゾーンで実行した場合、非大域ゾーンを含むシステム全体の情報が収集および報告されます。大域管理者は、ゾーンごとの資源消費を決定することもできます。詳細は、「ゾーンがインストールされている Solaris システムでの拡張アカウンティング」を参照してください。

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

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

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

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

コマンド	説明
acctadm(1M)	拡張アカウンティング機能のさまざまな属性の変更、拡張アカウンティングの停止と起動を行います。また、プロセス、タスク、およびフローを追跡するためのアカウンティング属性を選択するのに使用します。
wracct(1M)	アクティブなプロセスおよびタスクの拡張アカウンティングアクティビティーを書き込みます。
lastcomm(1)	直前に呼び出されたコマンドを表示します。`lastcomm` では、標準アカウンティングプロセスのデータまたは拡張アカウンティングプロセスのデータのどちらかを使用できます。

タスクやプロジェクトに関連するコマンドについては、「コマンドとコマンドオプションの例」を参照してください。IPQoS フローアカウンティングについては、ipqosconf(1M) のマニュアルページを参照してください。

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

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

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

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

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

アイテム (単一データ値 [スカラー])
グループ (項目のリスト)

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

モジュール (空白文字は使用不可)	説明	詳細
`Sun::Solaris::Project`	このモジュールは、次のプロジェクト操作関数にアクセスする機能を提供します。getprojid(2)、endprojent(3PROJECT)、fgetprojent(3PROJECT)、getdefaultproj(3PROJECT)、getprojbyid(3PROJECT)、getprojbyname(3PROJECT)、getprojent(3PROJECT)、getprojidbyname(3PROJECT)、inproj(3PROJECT)、project_walk(3PROJECT)、setproject(3PROJECT)、および setprojent(3PROJECT) です。	`Project(3PERL)`
`Sun::Solaris::Task`	このモジュールは、タスク操作関数である gettaskid(2) と settaskid(2) にアクセスする機能を提供します。	`Task(3PERL)`
`Sun::Solaris::Exacct`	最上位レベルの `exacct` モジュール。このモジュールは、`exacct` 関連のシステムコールである getacct(2)、putacct(2)、および wracct(2) にアクセスする機能を提供します。このモジュールは、libexacct(3LIB) ライブラリ関数である ea_error(3EXACCT) にアクセスする機能も提供します。`exacct` EO_、EW_、EXR_、P_、および TASK_* マクロのすべてに対応する定数も、このモジュールで提供されます。	`Exacct(3PERL)`
`Sun::Solaris::Exacct:: Catalog`	このモジュールは、`exacct` カタログタグ内のビットフィールドにアクセスする、オブジェクト指向型メソッドを提供します。このモジュールによって、EXC_、EXD_、および EXD_* マクロの定数にもアクセスできます。	`Exacct::Catalog(3PERL)`
`Sun::Solaris::Exacct:: File`	このモジュールは、次の `libexacct` アカウンティングファイル関数にアクセスする、オブジェクト指向型メソッドを提供します。ea_open(3EXACCT)、ea_close(3EXACCT)、ea_get_creator(3EXACCT)、ea_get_hostname(3EXACCT)、ea_next_object(3EXACCT)、ea_previous_object(3EXACCT)、および ea_write_object(3EXACCT) です。	`Exacct::File(3PERL)`
`Sun::Solaris::Exacct:: Object`	このモジュールは、個々の `exacct` アカウンティングファイルオブジェクトにアクセスする、オブジェクト指向型メソッドを提供します。`exacct` オブジェクトは、該当する `Sun::Solaris::Exacct::Object` サブクラスに与えられた、隠された参照として表されます。このモジュールはさらに、アイテムかグループかのオブジェクトタイプに分けられます。このレベルで、ea_match_object_catalog(3EXACCT) および ea_attach_to_object(3EXACCT) 関数にアクセスするメソッドがあります。	`Exacct::Object(3PERL)`
`Sun::Solaris::Exacct:: Object::Item`	このモジュールは、独立した `exacct` アカウンティングファイルアイテムにアクセスする、オブジェクト指向型メソッドを提供します。このタイプのオブジェクトは、`Sun::Solaris::Exacct::Object` から継承します。	`Exacct::Object::Item(3PERL)`
`Sun::Solaris::Exacct:: Object::Group`	このモジュールは、独立した `exacct` アカウンティングファイルグループにアクセスする、オブジェクト指向型メソッドを提供します。このタイプのオブジェクトは、`Sun::Solaris::Exacct::Object` から継承します。これらのオブジェクトによって、ea_attach_to_group(3EXACCT) 関数にアクセスできます。グループ内のアイテムは Perl 配列として表されます。	`Exacct::Object::Group(3PERL)`
`Sun::Solaris::Kstat`	このモジュールは、`kstat` 機能に対する Perl のタイハッシュインタフェースを提供します。このモジュールの使用例については、Perl で記述された `/bin/kstat` を参照してください。	`Kstat`(3PERL)

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

第 5 章拡張アカウンティングの管理 (手順)

この章では、拡張アカウンティングサブシステムを管理する方法について説明します。

拡張アカウンティングサブシステムの概要については、第 4 章拡張アカウンティング (概要)を参照してください。

拡張アカウンティング機能の管理 (作業マップ)

タスク	説明	説明
拡張アカウンティング機能を起動します。	拡張アカウンティングを使用して、システムで実行されている各プロジェクトの資源消費を監視します。「拡張アカウンティング」サブシステムを使用すると、タスク、プロセス、およびフローの履歴データを取り込むことができます。	「プロセス、タスク、およびフローの拡張アカウンティングを起動する方法」、「起動スクリプトを使って拡張アカウンティングを起動する方法」
拡張アカウンティングの状態を表示します。	拡張アカウンティング機能の状態を調べます。	「拡張アカウンティング状態を表示する方法」
使用可能なアカウンティング資源を表示します。	システム上の使用可能なアカウンティング資源を表示します。	「使用可能なアカウンティング資源を表示する方法」
プロセス、タスク、およびフローのアカウンティング機能を停止します。	拡張アカウンティング機能をオフにします。	「プロセス、タスク、およびフローアカウンティングを停止する方法」
拡張アカウンティング機能に対する Perl インタフェースを使用します。	Perl インタフェースを使用して、報告および抽出用のカスタムスクリプトを作成します。	「`libexacct` に対する Perl インタフェースの使用」

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

ユーザーは、管理対象の拡張アカウンティングの種類に適した権利プロファイルがあれば、拡張アカウンティングの管理 (アカウンティングの開始、アカウンティングの停止、およびアカウンティング構成パラメータの変更) を行うことができます。

フロー管理
プロセス管理
タスク管理

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

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

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プロセスの拡張アカウンティングを起動します。
# acctadm -e extended -f /var/adm/exacct/proc process

タスクの拡張アカウンティングを起動します。
# acctadm -e extended,mstate -f /var/adm/exacct/task task

フローの拡張アカウンティングを起動します。
# acctadm -e extended -f /var/adm/exacct/flow flow

参照

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

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

/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
                 Flow accounting: active
            Flow accounting file: /var/adm/exacct/flow
          Tracked flow resources: extended
        Untracked flow resources: none

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

注 –

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

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

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

# acctadm -r
process:
extended pid,uid,gid,cpu,time,command,tty,projid,taskid,ancpid,wait-status,zone,flag,
memory,mstatedisplays as one line
basic    pid,uid,gid,cpu,time,command,tty,flag
task:
extended taskid,projid,cpu,time,host,mstate,anctaskid,zone
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

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

プロセス、タスク、およびフローのアカウンティングを停止するには、それぞれを個別にオフにします。そのためには、acctadm コマンドに -x オプションを付けて実行します。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プロセスアカウンティングをオフにします。
# acctadm -x process

タスクアカウンティングをオフにします。
# acctadm -x task

フローアカウンティングをオフにします。
# acctadm -x flow

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

	# 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
            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/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/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

第 6 章資源制御 (概要)

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

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

資源制御を管理する方法については、第 7 章資源制御の管理 (手順)を参照してください。

Solaris 10 における資源制御の新機能

System V プロセス間通信 (IPC) の /etc/system 調整可能パラメータが、次の一連の資源制御で置き換えられています。

project.max-shm-ids
project.max-msg-ids
project.max-sem-ids
project.max-shm-memory
process.max-sem-nsems
process.max-sem-ops
process.max-msg-qbytes

次のイベントポート資源制御が追加されています。

project.max-device-locked-memory
project.max-port-ids
process.max-port-events

次の暗号化資源制御が追加されています。

project.max-crypto-memory

その他、次の資源制御が追加されています。

project.max-lwps
project.max-tasks
project.max-contracts

詳細は、「使用可能な資源制御」を参照してください。

Solaris 10 の新機能の全一覧および Solaris リリースについての説明は、『Oracle Solaris 10 9/10 の新機能』を参照してください。

資源制御の概念

Solaris オペレーティングシステムでは、プロセスごとの資源制限という概念が、第 2 章プロジェクトとタスク (概要)で説明したタスクおよびプロジェクトのエンティティーに拡張されています。この拡張機能は、資源制御 (rctls) 機能によって提供されます。また、割り当ては /etc/system 調整可能パラメータを通して設定していましたが、これも資源制御機構を通して自動的に行われるか、手動で構成するようになりました。

資源制御には、接頭辞 zone、project、task、または process が付きます。資源制御はシステム全体に適用できます。動作中のシステム上の資源制御値を更新できます。

このリリースで使用できる標準の資源制御のリストについては、「使用可能な資源制御」を参照してください。ゾーンごとに使用可能な資源制御については、「資源タイプのプロパティー」を参照してください。

このリリースで使用できる標準の資源制御のリストについては、「使用可能な資源制御」を参照してください。

資源制限と資源制御

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

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

プロセス間通信と資源制御

プロセスは、数種類のプロセス間通信 (IPC) の 1 つを使用して、互いに通信できます。IPC を使用すると、プロセス間で情報の転送や同期化を行うことができます。Solaris 10 リリースの前は、/etc/system ファイルにエントリを追加することで、IPC 調整可能パラメータを設定していました。今後は、資源制御機能により、カーネルの IPC 機能の動作を定義する資源制御が提供されるようになりました。これらの資源制御は、/etc/system の調整可能パラメータを置換します。

古いパラメータが、Solaris システムの /etc/system ファイルに入っていることがあります。その場合、これらのパラメータは、以前の Solaris リリースの場合と同様に、デフォルトの資源制御値の初期化に使用されます。ただし、古いパラメータはできるだけ使用しないでください。

どの IPC オブジェクトがプロジェクトの使用状況に影響を与えているかを監視するには、ipcs コマンドに -J オプションを付けて実行します。表示例については、「ipcs を使用する方法」を参照してください。ipcs コマンドの詳細については、ipcs(1) のマニュアルページを参照してください。

Solaris システムの調整については、『Oracle Solaris カーネルのチューンアップ・リファレンスマニュアル』を参照してください。

資源制御の制約機構

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

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

プロジェクトの属性機構

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

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

project.pool 属性は、プロジェクトのプールの結合を指定するために使用されます。資源プールの詳細については、第 12 章資源プール (概要)を参照してください。

資源制御と属性の構成

資源制御機能は、project データベースによって構成されます。第 2 章プロジェクトとタスク (概要)を参照してください。資源制御とその他の属性は、project データベースエントリの最後のフィールドで設定します。各資源制御に対応付けられる値は、括弧で囲まれ、コンマ区切りのプレーンテキストとして示されます。括弧内の値によって「アクション文節」が構成されます。各アクション文節には、値として特権レベル、しきい値、および特定のしきい値に対応付けられたアクションが含まれます。各資源制御は複数のアクション文節を持つことができ、各アクション文節もコンマで区切られます。次のエントリは、プロジェクトエンティティーにおけるタスクごとの軽量プロセス (LWP) 制限と、プロセスごとの最長 CPU 時間制限を定義します。process.max-cpu-time は、プロセスの実行時間が合計で 1 時間になるとプロセスに SIGTERM を送信し、1 時間 1 分になると SIGKILL を送信します。表 6–3 を参照してください。

development:101:Developers:::task.max-lwps=(privileged,10,deny);
  process.max-cpu-time=(basic,3600,signal=TERM),(priv,3660,signal=KILL)
typed as one line

注 –

ゾーンが有効になっているシステムの場合、ゾーン規模の資源制御はゾーン構成で指定されます。その形式は多少異なります。詳細は、「ゾーン構成データ」を参照してください。

rctladm コマンドを使用すると、資源制御機能の実行時に問い合わせや制御機能の変更を「大域有効範囲」で行うことができます。prctl コマンドを使用すると、実行時に資源制御機能の問い合わせや変更を「局所有効範囲」で行うことができます。

詳細については、「資源制御値に対応付けられた大域アクションと局所アクション」、および rctladm(1M) と prctl(1) のマニュアルページを参照してください。

注 –

ゾーンがインストールされているシステムでは、非大域ゾーンで rctladm を使用して設定を変更することはできません。各資源制御の大域ログ状態を表示する場合に、非大域ゾーンで rctladm を使用します。

使用可能な資源制御

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

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

数量は制限される量を意味します。
インデックスは最大有効識別子を意味します。

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

表 6–1 標準の資源制御


制御名	説明	デフォルトの単位
`project.cpu-cap`	Solaris 10 8/07: 1 つのプロジェクトで消費可能な CPU 資源量に対する絶対的な制限。`project.cpu-cap` 設定と同様、`100` の値は 1 つの CPU の 100% を意味します。`125` の値は 125% になります。CPU キャップの使用時は、100% がシステム上の 1 つの CPU の上限となります。	数量 (CPU の数)
`project.cpu-shares`	このプロジェクトに対して、公平配分スケジューラ (FSS(7) のマニュアルページを参照) で使用することが許可されている CPU 配分。	数量 (配分)
`project.max-crypto-memory`	ハードウェアによる暗号化処理の高速化のために `libpkcs11` が使用できるカーネルメモリーの合計量。カーネルバッファーおよびセッション関連の構造体の割り当ては、この資源制御に対してチャージされます。	サイズ (バイト)
`project.max-locked-memory`	ロックされる物理メモリーの許容合計量。 `priv_proc_lock_memory` がユーザーに割り当てられている場合、そのユーザーがすべてのメモリーをロックするのを防ぐため、この資源制御の設定も検討してください。 Solaris 10 8/07: Solaris 10 8/07 リリースでは、`project.max-device-locked-memory` は削除され、この資源制御で置き換えられました。	サイズ (バイト)
`project.max-port-ids`	イベントポートの許容最大数。	数量 (イベントポート数)
`project.max-sem-ids`	このプロジェクトに許容されるセマフォー ID の最大数。	数量 (セマフォー ID の数)
`project.max-shm-ids`	このプロジェクトに許容される共有メモリー ID の最大数。	数量 (共有メモリー ID の数)
`project.max-msg-ids`	このプロジェクトに許容されるメッセージキュー ID の最大数。	数量 (メッセージキュー ID の数)
`project.max-shm-memory`	このプロジェクトに許容される System V 共有メモリーの合計量。	サイズ (バイト)
`project.max-lwps`	このプロジェクトで同時に使用できる LWP の最大数。	数量 (LWP 数)
`project.max-tasks`	このプロジェクトに許容されるタスクの最大数	数量 (タスク数)
`project.max-contracts`	このプロジェクトに許容される契約の最大数	数量 (契約数)
`task.max-cpu-time`	このタスクのプロセスで使用できる最長 CPU 時間。	時間 (秒)
`task.max-lwps`	このタスクのプロセスで同時に使用できる LWP の最大数。	数量 (LWP 数)
`process.max-cpu-time`	このプロセスで使用できる最長 CPU 時間。	時間 (秒)
`process.max-file-descriptor`	このプロセスで使用できる最大のファイル記述子インデックス。	インデックス (最大ファイル記述子)
`process.max-file-size`	このプロセスの書き込みに使用できる最大ファイルオフセット。	サイズ (バイト)
`process.max-core-size`	このプロセスによって作成されるコアファイルの最大サイズ。	サイズ (バイト)
`process.max-data-size`	このプロセスで使用できるヒープメモリーの最大サイズ。	サイズ (バイト)
`process.max-stack-size`	このプロセスに使用できる最大スタックメモリーセグメント。	サイズ (バイト)
`process.max-address-space`	このプロセスで使用できる、セグメントサイズの総計としての最大アドレス空間。	サイズ (バイト)
`process.max-port-events`	イベントポートあたりに許容されるイベントの最大数。	数量 (イベント数)
`process.max-sem-nsems`	セマフォーセットあたりに許容されるセマフォーの最大数。	数量 (セットあたりのセマフォー数)
`process.max-sem-ops`	1 回の `semop` コールに許容されるセマフォー操作の最大数 (`semget()` のコール時に資源制御からコピーされる値)。	数量 (操作の数)
`process.max-msg-qbytes`	メッセージキュー内のメッセージの最大バイト数 (`msgget()` のコール時に資源制御からコピーされる値)。	サイズ (バイト)
`process.max-msg-messages`	メッセージキュー内のメッセージの最大数 (`msgget()` のコール時に資源制御からコピーされる値)。	数量 (メッセージ数)

資源制御の設定や変更がまったく行われていないシステム上では、資源制御のデフォルト値を表示できます。そのようなシステムでは、/etc/system や project データベースにデフォルト以外のエントリが含まれていません。値を表示するには、prctl コマンドを使用します。

ゾーン規模の資源制御

ゾーン規模の資源制御は、ゾーン内のすべてのプロセスエンティティーによる総資源消費を制限します。ゾーン規模の資源制御は、グローバルプロパティー名を使用して設定することもできます。詳細は、「ゾーン規模の資源制御の設定」および「ゾーンの構成方法」を参照してください。

表 6–2 ゾーン規模の資源制御


制御名	説明	デフォルトの単位
`zone.cpu-cap`	Solaris 10 5/08: 1 つの非大域ゾーンで消費可能な CPU 資源量に対する絶対的な制限。`project.cpu-cap` 設定と同様、`100` の値は 1 つの CPU の 100% を意味します。`125` の値は 125% になります。CPU キャップの使用時は、100% がシステム上の 1 つの CPU の上限となります。	数量 (CPU の数)
`zone.cpu-shares`	このゾーンに対する公平配分スケジューラ (FSS) の CPU 配分	数量 (配分)
`zone.max-locked-memory`	ゾーンで使用できるロックされた物理メモリーの合計量。 `priv_proc_lock_memory` がゾーンに割り当てられている場合、そのゾーンがすべてのメモリーをロックするのを防ぐため、この資源制御の設定も検討してください。	サイズ (バイト)
`zone.max-lwps`	このゾーンで同時に使用できる LWP の最大数	数量 (LWP 数)
`zone.max-msg-ids`	このゾーンに許容されるメッセージキュー ID の最大数	数量 (メッセージキュー ID の数)
`zone.max-sem-ids`	このゾーンに許容されるセマフォー ID の最大数	数量 (セマフォー ID の数)
`zone.max-shm-ids`	このゾーンに許容される共有メモリー ID の最大数	数量 (共有メモリー ID の数)
`zone.max-shm-memory`	このゾーンに許容される System V 共有メモリーの合計量	サイズ (バイト)
`zone.max-swap`	このゾーンのユーザープロセスのアドレス空間マッピングと `tmpfs` マウントで消費できるスワップの合計量。	サイズ (バイト)

ゾーン規模の資源制御の構成方法については、「資源タイプのプロパティー」および「ゾーンの構成方法」を参照してください。lx ブランドゾーンでゾーン規模の資源制御を使用する方法については、「lx ブランドゾーンを構成、検証、および確定する方法」を参照してください。

ゾーン規模の資源制御を大域ゾーンに適用することも可能です。詳細は、第 17 章非大域ゾーンの構成 (概要)および「ゾーンがインストールされている Solaris システムでの公平配分スケジューラの使用」を参照してください。

単位のサポート

資源制御の種類を示す大域フラグは、すべての資源制御に対して定義されます。これらのフラグは、種類に関する基本情報を prctl などのアプリケーションに伝えるために、システムによって使用されます。アプリケーションはこの情報を使用して、次の内容を判定します。

各資源制御に適した単位の文字列
倍率値を解釈するときに使用する正しい倍率

次の大域フラグを使用できます。

大域フラグ	資源制御の種類ごとの文字列	修飾子	倍率
RCTL_GLOBAL_BYTES	バイト	B	1
		KB	2¹⁰
		MB	2²⁰
		GB	2³⁰
		TB	2⁴⁰
		PB	2⁵⁰
		EB	2⁶⁰
RCTL_GLOBAL_SECONDS	秒	s	1
		Ks	10³
		Ms	10⁶
		Gs	10⁹
		Ts	10¹²
		Ps	10¹⁵
		Es	10¹⁸
RCTL_GLOBAL_COUNT	数	なし	1
		K	10³
		M	10⁶
		G	10⁹
		T	10¹²
		P	10¹⁵
		E	10¹⁸

資源制御に倍率値を使用できます。次の例は、倍率付きのしきい値を示します。

task.max-lwps=(priv,1K,deny)

注 –

単位修飾子は、prctl、projadd、および projmod コマンドに使用できます。project データベース自体で単位修飾子を使用することはできません。

資源制御値と特権レベル

資源制御のしきい値は、局所アクションのトリガーやログ作成などの大域アクションの発生が可能である実行ポイントを設定します。

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

基本値 — 呼び出し元プロセスの所有者が変更できます
特権値 — 特権を持っている呼び出し元 (スーパーユーザー) だけが変更できます
システム値 — オペレーティングシステムによる処理が実行されている間は、固定されます

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

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

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

資源制御値に対応付けられた大域アクションと局所アクション

資源制御値に対応付けられるアクションには、2 種類あります。大域アクションと局所アクションです。

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

大域アクションは、システム上のすべての資源制御の資源制御値に適用されます。rctladm コマンド (rctladm(1M) のマニュアルページを参照) を使用すると、次の動作を実行できます。

アクティブなシステム資源制御の大域的状態を表示します
大域ログ作成アクションを設定します

資源制御に対応付けられた大域ログ作成アクションは、無効にしたり有効にしたりできます。syslog アクションの程度を設定するには、重要度を syslog=level のように割り当てます。level に設定できる値は次のとおりです。

debug
info
notice
warning
err
crit
alert
emerg

デフォルトでは、資源制御の違反は大域ログ作成では記録されません。Solaris 10 5/08 リリースでは、大域アクションを構成できない資源制御に対して、レベル n/a が追加されました。

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

局所アクションは、制御値を超えようとしているプロセスに対して実行されます。資源制御に設定された各しきい値に対して、1 つ以上のアクションを対応付けることができます。局所アクションには、3 つの種類があります。 none、deny、および signal= です。これら 3 つのアクションは、次のように使用されます。

none: しきい値を超える量の資源要求に対して、何のアクションも行いません。このアクションは、アプリケーションの進行に影響を与えることなく、資源の使用状況を監視するのに役立ちます。プロセスが資源制御のしきい値を超えたときに大域メッセージを表示することもできます。ただし、このアクションによってプロセスが影響を受けることはありません。
deny: しきい値を超える量の資源要求を拒否できます。たとえば、task.max-lwps 資源制御に deny アクションが指定されている場合、制御値を超えるような新しいプロセスを作成する fork システムコールは失敗します。fork(2) のマニュアルページを参照してください。
signal=: 資源制御値を超えたときに大域シグナルメッセージを送信するアクションを有効にすることができます。プロセスがしきい値を超えると、プロセスにシグナルが送信されます。プロセスがさらに資源を消費しても、追加のシグナルが送信されることはありません。使用できるシグナルの一覧については、表 6–3 を参照してください。

すべての資源制御にすべてのアクションを適用できるわけではありません。たとえば、プロセスは、その所属先のプロジェクトに割り当てられている CPU 配分を超えることはできません。したがって、project.cpu-shares 資源制御に deny アクションを適用することはできません。

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

表 6–3 資源制御値に使用できるシグナル


シグナル	説明	注釈
SIGABRT	プロセスを終了します。
SIGHUP	ハングアップシグナルを送信します。開いた回線上でキャリアが検出されなくなったときに発生します。シグナルは、端末を制御しているプロセスグループに送信されます。
SIGTERM	プロセスを終了します。ソフトウェアによって送信される終了シグナルです。
SIGKILL	プロセスを終了し、プログラムを強制終了します。
SIGSTOP	プロセスを停止します。ジョブ制御シグナルです。
SIGXRES	資源制御の制限超過です。資源制御機能によって生成されます。
SIGXFSZ	プロセスを終了します。ファイルサイズの制限超過です。	RCTL_GLOBAL_FILE_SIZE プロパティー (`process.max-file-size`) を持つ資源制御だけで使用可能です。詳細は、rctlblk_set_value(3C) のマニュアルページを参照してください。
SIGXCPU	プロセスを終了します。CPU 時間の制限超過です。	RCTL_GLOBAL_CPUTIME プロパティー (`process.max-cpu-time`) を持つ資源制御だけで使用可能です。詳細は、rctlblk_set_value(3C) のマニュアルページを参照してください。

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

システム上の資源制御には、それぞれ特定のプロパティーセットが対応付けられています。このプロパティーセットは、一連のフラグとして定義されます。これらのフラグは、その資源が制御されているすべてのインスタンスに対応付けられます。大域フラグは変更できませんが、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 seconds ]

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

lowerable: この制御の特権値を下げるのに、スーパーユーザー特権を必要としません。
no-deny: しきい値を超えても、資源へのアクセスは拒否されません。
cpu-time: 資源がしきい値に達したとき、SIGXCPU を送信できます。
seconds: 資源制御の時間。
no-basic: 特権タイプ basic を持つ資源制御値を設定できません。特権付き資源制御値だけが許可されます。
no-signal: 資源制御値に対してローカルのシグナルアクションを設定できません。
no-syslog: この資源制御に対して大域の syslog メッセージアクションを設定できません。
deny: しきい値を超えたときに、必ず資源の要求を拒否します。
count: 資源制御のカウント (整数) 値。
bytes: 資源制御のサイズの単位。

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

$ prctl -n process.max-cpu-time $$
	process 353939: -ksh
	NAME    PRIVILEGE    VALUE    FLAG   ACTION              RECIPIENT
 process.max-cpu-time
         privileged   18.4Es    inf   signal=XCPU                 -
         system       18.4Es    inf   none

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

資源制御の実行

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

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

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

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

資源制御の適用

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

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

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

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

ログ状態の更新

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

資源制御の更新

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

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

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

資源制御で使用するコマンド

資源制御で使用するコマンドを次の表に示します。

コマンド	説明
ipcs(1)	このコマンドを使用すると、どの IPC オブジェクトがプロジェクトの使用状況に影響を与えているかを監視できます
prctl(1)	このコマンドを使用すると、資源制御機能の実行時に問い合わせや資源制御機能の変更をローカルに行うことができます
rctladm(1M)	このコマンドを使用すると、資源制御機能の実行時に問い合わせや資源制御機能の変更を大域的に行うことができます

resource_controls(5) のマニュアルページでは、単位や倍率なども含め、プロジェクトデータベース経由で使用可能な資源制御について説明しています。

第 7 章資源制御の管理 (手順)

この章では、資源制御機能を管理する方法について説明します。

資源制御機能の概要については、第 6 章資源制御 (概要)を参照してください。

資源制御の管理 (作業マップ)

タスク	説明	説明
資源制御を設定します。	`/etc/project` ファイルでプロジェクトに資源制御を設定します。	「資源制御の設定」
アクティブなプロセス、タスク、またはプロジェクトについて、資源制御値をローカルに取得または変更します。	システム上のアクティブなプロセス、タスク、またはプロジェクトに関連付けられている資源制御に対し、実行時に問い合わせや変更を行います。	「`prctl` コマンドの使用」
稼働中のシステムの資源制御の大域的状態を表示または更新します。	システム全体の各資源制御の大域ログ状態を表示します。また、制御値を超えたときに `syslog` で記録するログのレベルを設定します。	「`rctladm` の使用」
アクティブなプロセス間通信 (IPC) 機能の状態を報告します。	アクティブなプロセス間通信 (IPC) 機能について情報を表示します。どの IPC オブジェクトがプロジェクトの使用状況に影響を与えているかを監視します。	「`ipcs` の使用」
Web サーバーに十分な CPU 容量が割り当てられているかどうかを判定します。	資源制御に大域アクションを設定します。このアクションを設定すると、資源制御値を超えたエンティティーについて通知を受け取ることができ、資源制御値が低すぎるかどうかを判定できます。	「Web サーバーに十分な CPU 容量が割り当てられているかどうかを判定する方法」

資源制御の設定

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

この手順では、x-files というプロジェクトを /etc/project ファイルに追加し、このプロジェクト内に作成されるタスクに適用する LWP の最大数を設定します。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

projadd コマンドに -K オプションを付けて実行して、x-files というプロジェクトを作成します。このプロジェクト内に作成される各タスクの LWP の最大数を 3 に設定します。
# projadd -K 'task.max-lwps=(privileged,3,deny)' x-files

/etc/project ファイル内のエントリを表示します。それには、次のいずれかの方法を使用します。

次のように入力します。

# projects -l
system
        projid : 0
        comment: ""
        users  : (none)
        groups : (none)
        attribs: 
.
.
.
x-files
        projid : 100
        comment: ""
        users  : (none)
        groups : (none)
        attribs: task.max-lwps=(privileged,3,deny)

次のように入力します。

# cat /etc/project
system:0:System:::
.
.
.
x-files:100::::task.max-lwps=(privileged,3,deny)

例 7–1 セッション例

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

# newtask -p x-files csh

# prctl -n task.max-lwps $$
process: 111107: csh
NAME    PRIVILEGE    VALUE    FLAG   ACTION            RECIPIENT
task.max-lwps
        privileged       3       -   deny                      -
        system       2.15G     max   deny                      -
# id -p
uid=0(root) gid=1(other) projid=100(x-files)

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

# csh        /* creates second LWP */

# csh        /* creates third LWP */

# csh        /* cannot create more LWPs */
Vfork failed
#

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

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

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

projmod コマンドに -s オプションと -K オプションを付けて実行することで、プロジェクト x-files に資源制御を設定します。
# projmod -s -K 'task.max-lwps=(basic,10,none),(privileged,500,deny); process.max-file-descriptor=(basic,128,deny)' x-filesone line in file
次の制御が設定されます。
- タスクごとの LWP 最大数について、アクションなしの basic 制御。
- タスクごとの LWP 最大数について、特権レベルの deny 制御。この制御により、「プロジェクト内の各タスクの最大 LWP 数を設定する方法」の例のように、最大数を超える数の LWP を作成しようとすると失敗します。
- プロセスごとの最大ファイル記述子は basic レベルに制限されており、最大値を超える open コールはすべて失敗します。

次のいずれかの方法で、ファイル内のエントリを表示します。

次のように入力します。

# projects -l
.
.
.
x-files
        projid : 100
        comment: ""
        users  : (none)
        groups : (none)
        attribs: process.max-file-descriptor=(basic,128,deny)
                 task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file

次のように入力します。

# cat etc/project
.
.
.
x-files:100::::process.max-file-descriptor=(basic,128,deny);
task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file

`prctl` コマンドの使用

prctl コマンドを使用すると、システム上のアクティブなプロセス、タスク、またはプロジェクトに関連付けられている資源制御に対し、実行時に問い合わせや変更を行うことができます。詳細は、prctl(1) のマニュアルページを参照してください。

`prctl` コマンドを使ってデフォルトの資源制御値を表示する方法

この手順は、資源制御の設定や変更がまったく行われていないシステム上で実行する必要があります。/etc/system ファイルまたは project データベース内には、デフォルト以外のエントリしか記述できません。

実行中の現在のシェルなど、任意のプロセスに対して prctl コマンドを実行します。

# prctl $$
process: 100337: -sh
NAME    PRIVILEGE       VALUE    FLAG   ACTION                   RECIPIENT
process.max-port-events
        privileged      65.5K       -   deny                             -
        system          2.15G     max   deny                             -
process.crypto-buffer-limit
        system          16.0EB    max   deny                             -
process.max-crypto-sessions
        system          18.4E     max   deny                             -
process.add-crypto-sessions
        privileged        100       -   deny                             -
        system          18.4E     max   deny                             -
process.min-crypto-sessions
        privileged         20       -   deny                             -
        system          18.4E     max   deny                             -
process.max-msg-messages
        privileged      8.19K       -   deny                             -
        system          4.29G     max   deny                             -
process.max-msg-qbytes
        privileged      64.0KB      -   deny                             -
        system          16.0EB    max   deny                             -
process.max-sem-ops
        privileged        512       -   deny                             -
        system          2.15G     max   deny                             -
process.max-sem-nsems
        privileged        512       -   deny                             -
        system          32.8K     max   deny                             -
process.max-address-space
        privileged      16.0EB    max   deny                             -
        system          16.0EB    max   deny                             -
process.max-file-descriptor
        basic             256       -   deny                        100337
        privileged      65.5K       -   deny                             -
        system          2.15G     max   deny                             -
process.max-core-size
        privileged      8.00EB    max   deny                             -
        system          8.00EB    max   deny                             -
process.max-stack-size
        basic           8.00MB      -   deny                        100337
        privileged      8.00EB      -   deny                             -
        system          8.00EB    max   deny                             -
process.max-data-size
        privileged      16.0EB    max   deny                             -
        system          16.0EB    max   deny                             -
process.max-file-size
        privileged      8.00EB    max   deny,signal=XFSZ                 -
        system          8.00EB    max   deny                             -
process.max-cpu-time
        privileged      18.4Es    inf   signal=XCPU                      -
        system          18.4Es    inf   none                             -
task.max-cpu-time
        system          18.4Es    inf   none                             -
task.max-lwps
        system          2.15G     max   deny                             -
project.max-contracts
        privileged      10.0K       -   deny                             -
        system          2.15G     max   deny                             -
project.max-device-locked-memory
        privileged       499MB      -   deny                             -
        system          16.0EB    max   deny                             -
project.max-port-ids
        privileged      8.19K       -   deny                             -
        system          65.5K     max   deny                             -
project.max-shm-memory
        privileged      1.95GB      -   deny                             -
        system          16.0EB    max   deny                             -
project.max-shm-ids
        privileged        128       -   deny                             -
        system          16.8M     max   deny                             -
project.max-msg-ids
        privileged        128       -   deny                             -
        system          16.8M     max   deny                             -
project.max-sem-ids
        privileged        128       -   deny                             -
        system          16.8M     max   deny                             -
project.max-tasks
        system          2.15G     max   deny                             -
project.max-lwps
        system          2.15G     max   deny                             -
project.cpu-shares
        privileged          1       -   none                             -
        system          65.5K     max   none                             -
zone.max-lwps
        system          2.15G     max   deny                             -
zone.cpu-shares
        privileged          1       -   none                             -
        system          65.5K     max   none                             -

`prctl` コマンドを使って特定の資源制御の情報を表示する方法

実行中の現在のシェルの最大ファイル記述子を表示します。

# prctl -n process.max-file-descriptor $$
process: 110453: -sh
NAME    PRIVILEGE       VALUE    FLAG   ACTION       RECIPIENT
process.max-file-descriptor
        basic             256       -   deny            110453
        privileged      65.5K       -   deny                 -
        system          2.15G     max   deny

`prctl` を使って値を一時的に変更する方法

次の手順では、prctl コマンドを使用して x-files プロジェクトに新しい特権値を一時的に追加し、プロジェクトあたり 4 つ以上の LWP を使用することを拒否します。その結果は、「プロジェクト内の各タスクの最大 LWP 数を設定する方法」の結果と同等になります。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

newtask を使って x-files プロジェクトに参加します。
# newtask -p x-files

id コマンドに -p オプションを付けて実行し、正しいプロジェクトに参加できたことを確認します。
# id -p uid=0(root) gid=1(other) projid=101(x-files)

project.max-lwps に新しい特権値を追加して、LWP の数を 3 つまでに制限します。
# prctl -n project.max-lwps -t privileged -v 3 -e deny -i project x-files

結果を確認します。

# prctl -n project.max-lwps -i project x-files
process: 111108: csh
NAME    PRIVILEGE    VALUE    FLAG   ACTION            RECIPIENT
project.max-lwps
        privileged       3       -   deny                      -
        system       2.15G     max   deny                      -

`prctl` を使って資源制御値を下げる方法

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

prctl コマンドに -r オプションを付けて実行し、process.max-file-descriptor 資源制御の最小値を変更します。
# prctl -n process.max-file-descriptor -r -v 128 $$

`prctl` を使ってプロジェクトの制御値を表示、置換、確認する方法

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プロジェクト group.staff の project.cpu-shares の値を表示します。

# prctl -n project.cpu-shares -i project group.staff
project: 2: group.staff
NAME    PRIVILEGE       VALUE    FLAG   ACTION     RECIPIENT
project.cpu-shares
        privileged          1       -   none               -
        system          65.5K     max   none

project.cpu-shares の現在の値 1 を値 10 で置換します。

# prctl -n project.cpu-shares -v 10 -r -i project group.staff

プロジェクト group.staff の project.cpu-shares の値を表示します。

# prctl -n project.cpu-shares -i project group.staff
project: 2: group.staff
NAME    PRIVILEGE       VALUE    FLAG   ACTION     RECIPIENT
project.cpu-shares
        privileged         10       -   none               -
        system          65.5K     max   none

`rctladm` の使用

`rctladm` を使用する方法

rctladm コマンドを使用すると、資源制御機能の大域的状態を実行時に問い合わせたり変更したりできます。詳細は、rctladm(1M) のマニュアルページを参照してください。

たとえば、rctladm に -e オプションを付けて実行して、資源制御の大域属性 syslog を有効にすることができます。制御が限界を超えたとき、指定された syslog レベルで通知が記録されます。process.max-file-descriptor の大域属性 syslog を有効にするには、次のように入力します。

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

rctladm コマンドを引数なしで使用すると、各資源制御の大域フラグが大域タイプフラグも含めて表示されます。

# rctladm
process.max-port-events     syslog=off  [ deny count ]
process.max-msg-messages    syslog=off  [ deny count ]
process.max-msg-qbytes      syslog=off  [ deny bytes ]
process.max-sem-ops         syslog=off  [ deny count ]
process.max-sem-nsems       syslog=off  [ deny count ]
process.max-address-space   syslog=off  [ lowerable deny no-signal bytes ]
process.max-file-descriptor syslog=off  [ lowerable deny count ]
process.max-core-size       syslog=off  [ lowerable deny no-signal bytes ]
process.max-stack-size      syslog=off  [ lowerable deny no-signal bytes ]
.
.
.

`ipcs` の使用

`ipcs` を使用する方法

ipcs ユーティリティーを使用すると、アクティブなプロセス間通信 (IPC) 機能について情報を表示できます。詳細は、ipcs(1) のマニュアルページを参照してください。

ipcs に -J オプションを付けて実行すると、どのプロジェクトの制限に対して IPC オブジェクトが割り当てられているかを確認できます。

# ipcs -J
    IPC status from <running system> as of Wed Mar 26 18:53:15 PDT 2003
T         ID      KEY        MODE       OWNER    GROUP    PROJECT
Message Queues:
Shared Memory:
m       3600      0       --rw-rw-rw-   uname    staff    x-files
m        201      0       --rw-rw-rw-   uname    staff    x-files
m       1802      0       --rw-rw-rw-   uname    staff    x-files
m        503      0       --rw-rw-rw-   uname    staff    x-files
m        304      0       --rw-rw-rw-   uname    staff    x-files
m        605      0       --rw-rw-rw-   uname    staff    x-files
m          6      0       --rw-rw-rw-   uname    staff    x-files
m        107      0       --rw-rw-rw-   uname    staff    x-files
Semaphores:
s          0      0       --rw-rw-rw-   uname    staff    x-files

容量に関する警告

資源制御に対して大域アクションを設定すると、資源制御値を超えたエンティティーに関する通知を受け取ることができ、資源制御値が低すぎるかどうかを判断できます。

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

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

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

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

prctl コマンドを使用して、httpd プロセスを含むタスクにスーパーユーザーが所有する特権レベルの資源制御を設定します。各タスクの LWP の総数を 40 に制限し、すべての局所アクションを無効にします。
# prctl -n task.max-lwps -v 40 -t privileged -d all `pgrep httpd`

資源制御 task.max-lwps で、システムログの大域アクションを有効にします。
# rctladm -e syslog task.max-lwps

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

作業負荷が資源制御を超えると、次のような内容が /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 時間を割り当てることができます。

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

公平配分スケジューラの使用を開始する方法については、第 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 資源を得るための競合が各プロセッサセットで常に発生します。

この図は、3 つのプロジェクト内で CPU にバインドされたアプリケーションを実行する場合、サーバーの 8 つの CPU がどのように割り当てられるかを示します。

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

プロジェクト	割り当て
プロジェクト A	4% = (1/6 X 2/8)_pset1
プロジェクト B	28% = (2/6 X 2/8)_pset1+ (2/5 * 4/8)_pset2
プロジェクト C	67% = (3/6 X 2/8)_pset1+ (3/5 X 4/8)_pset2+ (3/3 X 2/8)_pset3

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

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

プロジェクト	割り当て
プロジェクト A	16.66% = (1/6)
プロジェクト B	33.33% = (2/6)
プロジェクト C	50% = (3/6)

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 で使用するコマンド

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

コマンド	説明
priocntl(1)	指定されたプロセスのスケジューリングパラメータを表示または設定します。実行中のプロセスを別のスケジューリングクラスに移動します。
ps(1)	実行中のプロセスに関する情報を一覧表示します。プロセッサセットがどのスケジューリングクラスで実行されているかを示します。
dispadmin(1M)	システムのデフォルトのスケジューラを設定します。FSS スケジューラのタイムクォンタム (time quantum) 値を調べ、調整する場合にも使用されます。
FSS(7)	公平配分スケジューラ (FSS) を記述します。

第 9 章公平配分スケジューラの管理 (手順)

この章では、公平配分スケジューラ (FSS) の使用方法について説明します。

FSS の概要については、第 8 章公平配分スケジューラ (概要)を参照してください。ゾーンが使用されている場合のスケジューリングクラスの詳細については、「ゾーンのスケジューリングクラス」を参照してください。

公平配分スケジューラの管理 (作業マップ)

タスク	説明	参照先
CPU 使用量を監視します。	プロジェクトの CPU 使用量およびプロセッサセット内のプロジェクトの CPU 使用量を監視します。	「FSS の監視」
デフォルトのスケジューラクラスを設定します。	FSS などのスケジューラをシステムのデフォルトスケジューラとして設定します。	「FSS をデフォルトのスケジューラクラスにする方法」
実行中のプロセスを、あるスケジューリングクラスから FSS クラスなどの別のスケジューリングクラスに移動します。	デフォルトのスケジューリングクラスの変更や再起動を行うことなく、あるスケジューリングクラスから別のスケジューリングクラスにプロセスを手動で移動します。	「プロセスを TS クラスから FSS クラスに手動で移動する方法」
すべての実行中のプロセスを、FSS クラスなどの別のスケジューリングクラスに移動します。	デフォルトのスケジューリングクラスの変更や再起動を行うことなく、すべてのスケジューリングクラスから別のスケジューリングクラスにプロセスを手動で移動します。	「プロセスをすべてのユーザークラスから FSS クラスに手動で移動する方法」
プロジェクトのプロセスを、FSS クラスなどの別のスケジューリングクラスに移動します。	プロジェクトのプロセスを、現在のスケジューリングクラスから別のスケジューリングクラスに手動で移動します。	「プロジェクトのプロセスを FSS クラスに手動で移動する方法」
FSS パラメータを調べ、調整します。	スケジューラのタイムクォンタムの値を調整します。「タイムクォンタム」とは、スレッドがプロセッサ上で実行を開始してからそのプロセッサを放棄するまでの時間量のことです。	「スケジューラのパラメータを調整する方法」

FSS の監視

prstat コマンド (prstat(1M) のマニュアルページを参照) を使用すると、アクティブなプロジェクトごとの CPU 使用量を監視できます。

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

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

システム上で実行されているプロジェクトの CPU 使用量を監視するには、prstat コマンドに -J オプションを付けて実行します。
% prstat -J

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

1 つまたは複数のプロセッサセットについて、プロジェクトの CPU 使用量を監視するには、次のように入力します。
% prstat -J -C pset-list
ここで pset-list は、プロセッサセット ID をコンマで区切って並べたリストです。

FSS の構成

Solaris システムのほかのスケジューリングクラスで使用するものと同じコマンドを、FSS でも使用できます。スケジューラクラス、スケジューラの調整可能パラメータ、および個々のプロセスのプロパティーを構成できます。

svcadm restart を使用すると、スケジューラサービスを再起動することができます。詳細は、svcadm(1M) のマニュアルページを参照してください。

FSS をデフォルトのスケジューラクラスにする方法

CPU 配分割り当てを有効にするには、FSS をシステムのデフォルトのスケジューラにする必要があります。

priocntl と dispadmin コマンドを組み合わせて使用することにより、FSS はただちにデフォルトのスケジューラになり、この設定は再起動後も有効です。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

システムのデフォルトのスケジューラが FSS になるように設定します。
# dispadmin -d FSS
この変更指定は次の再起動で有効になります。再起動後は、システムのすべてのプロセスが FSS スケジューリングクラスで実行されます。

再起動を行わずに、この設定をただちに有効にします。
# priocntl -s -c FSS -i all

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

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

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

init プロセス (pid 1) を FSS スケジューリングクラスに移動します。
# priocntl -s -c FSS -i pid 1

すべてのプロセスを TS スケジューリングクラスから FSS スケジューリングクラスに移動します。
# priocntl -s -c FSS -i class TS
注 –
すべてのプロセスは、再起動後には再び TS スケジューリングクラスで実行されます。

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

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

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

init プロセス (pid 1) を FSS スケジューリングクラスに移動します。
# priocntl -s -c FSS -i pid 1

すべてのプロセスを現在のスケジューリングクラスから FSS スケジューリングクラスに移動します。
# priocntl -s -c FSS -i all
注 –
すべてのプロセスは、再起動後には再びデフォルトのスケジューリングクラスで実行されます。

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

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

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プロジェクト ID 10 で実行するプロセスを FSS スケジューリングクラスに移動します。
# priocntl -s -c FSS -i projid 10
プロジェクトのプロセスは、再起動後には再びデフォルトのスケジューリングクラスで実行されます。

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

dispadmin コマンドを使用すると、システムの稼働中にプロセススケジューラパラメータを表示または変更できます。たとえば、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

第 10 章資源上限デーモンによる物理メモリーの制御 (概要)

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

Solaris 10 8/07: システムでゾーンを実行している場合は、大域ゾーンから rcapd を使用して、非大域ゾーンでの物理メモリーの消費を規制できます。詳細は、第 18 章非大域ゾーンの計画と構成 (手順)を参照してください。

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

rcapd 機能の使用手順については、第 11 章資源上限デーモンの管理 (手順)を参照してください。

資源上限デーモンによる物理メモリー制御の新機能

Solaris 10: projmod コマンドを使用して、/etc/project ファイル内の rcap.max-rss 属性を設定できるようになりました。

Solaris 10 11/06: Solaris サービス管理機能 (SMF) のサービスとして資源上限デーモンを有効化/無効化することに関する情報が、追加されました。

Solaris 10 の新機能の全一覧および Solaris リリースについての説明は、『Oracle Solaris 10 9/10 の新機能』を参照してください。

資源上限デーモンの紹介

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

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

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

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

資源上限制御のしくみ

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

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

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

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

プロジェクトの物理メモリーの使用率を制限する属性

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

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

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

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

注 –

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

projmod コマンドを使用すると、/etc/project ファイル内の rcap.max-rss 属性を設定できます。

# projmod -s -K rcap.max-rss=10GB db

/etc/project ファイルには、次の行が含まれるようになります。

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

`rcapd` の構成

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

上限実行しきい値を設定します
rcapd が実行する動作間隔を設定します
資源上限制御を有効または無効にします
構成済みの資源上限デーモンの現在の状態を表示します

資源上限デーモンを構成するには、スーパーユーザーの特権を持っているか、プロファイルの一覧内に Process Management プロファイルが含まれている必要があります。Process Management 役割と System Administrator 役割には、どちらにも Process Management プロファイルが含まれています。

構成の変更を rcapd に適用するには、構成間隔に従うか (「rcapd の動作間隔」を参照)、または必要に応じて SIGHUP を送信します (kill(1) のマニュアルページを参照)。

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

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

ゾーン環境がインストールされているシステムでの資源上限デーモンの使用

ゾーンを構成するときに capped-memory 資源を設定することにより、ゾーンの常駐セットサイズ (RSS) 使用量を制御できます。詳細は、「Solaris 10 8/07: 物理メモリーの制御と capped-memory 資源」を参照してください。大域ゾーンも含め、ゾーン内で rcapd を実行すると、そのゾーン内のプロジェクトにメモリー上限を適用できます。

特定のゾーンで消費可能なメモリー量に、次の再起動まで一時的な上限を設定することができます。「ゾーンに一時的な資源上限を指定する方法」を参照してください。

rcapd をゾーン内で使用して、資源上限が定義されたプロジェクト内で動作するプロセスが消費する物理メモリーを規制する場合は、そのゾーン内でデーモンを構成する必要があります。

別のゾーン内にあるアプリケーションのメモリー上限を選択する場合、通常は、そのアプリケーションが別のゾーン内にあることを考慮する必要はありません。例外は、ゾーン別のサービスの場合です。ゾーン別のサービスは、メモリーを消費します。システムの物理メモリー量およびメモリー上限を決定する際には、このメモリー消費を考慮してください。

注 –

rcapd を lx ブランドゾーンで実行することはできません。ただし、デーモンを大域ゾーンから使用してブランドゾーンのメモリー上限を設定することはできます。

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

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

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

メモリーをページアウトすることによって、作業負荷に定義された上限を超えた分のメモリーのサイズを小さくすることができます。
メモリーをページアウトすることによって、システム上のメモリー上限実行しきい値を超えた物理メモリーの使用率を下げることができます。

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

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

上限値の決定

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

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

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

入出力システムへの影響

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

CPU 使用率への影響

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

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

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

共有メモリーの報告

rcapd デーモンは、ほかのプロセスと共有されているメモリーページ、あるいは、同じプロセス内で複数回マッピングされているメモリーページについて、かなり正確な RSS の見積もりを報告します。異なるプロジェクトのプロセスが同じメモリーを共有している場合、そのメモリーは、そのメモリーを共有しているすべてのプロジェクトの RSS の合計に含められます。

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

`rcapd` の動作間隔

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

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

操作	デフォルトの間隔値 (秒)	説明
`scan`	15	プロジェクトの作業負荷内で動作しているプロセスを走査する間隔の秒数。最小値は 1 秒です。
`sample`	5	常駐セットサイズのサンプリングから、その後に上限を制限するまでの間の秒数。最小値は 1 秒です。
`report`	5	ページング統計を更新する間隔の秒数。`0` に設定すると、ページング統計は更新されず、`rcapstat` からの出力も最新の状態を示さなくなります。
`config`	60	再構成する間隔の秒数。再構成イベントでは、`rcapadm` は構成ファイルを更新用に読み取って、`project` データベースに新しいまたは改訂されたプロジェクト上限があるかどうかを走査します。`SIGHUP` を `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 の報告の列見出しを定義します。

`rcapstat` の列見出し	説明
`id`	上限が定義されたプロジェクトの ID。
`project`	プロジェクト名。
`nproc`	プロジェクト内のプロセス数。
`vm`	プロジェクト内のプロセスが使用する仮想メモリーサイズの合計。マップされたファイルおよびデバイスもすべて含みます。単位は、K バイト (K)、M バイト (M)、または G バイト (G) です。
`rss`	プロジェクト内のプロセスが使用すると推定される常駐セットサイズ (RSS) の合計。単位は、K バイト (K)、M バイト (M)、または G バイト (G) です。共有されるページは考慮されません。
`cap`	プロジェクトに定義された RSS 上限。メモリー上限を指定する方法については、「プロジェクトの物理メモリーの使用率を制限する属性」または rcapd(1M) のマニュアルページを参照してください。
`at`	前回の `rcapstat` のサンプリング以降、 `rcapd` がページアウトしようとしたメモリーの合計。
`avgat`	前回の `rcapstat` のサンプリング以降に発生した各サンプリングサイクル中、`rcapd` がページアウトしようとしたメモリーの平均。`rcapd` がコレクション RSS をサンプリングする頻度は、`rcapadm` で設定できます。「`rcapd` の動作間隔」を参照してください。
`pg`	前回の `rcapstat` のサンプリング以降、 `rcapd` が正常にページアウトしたメモリーの合計。
`avgpg`	前回の `rcapstat` のサンプリング以降に発生した各サンプリングサイクル中、`rcapd` が正常にページアウトしたと推定されるメモリーの平均。`rcapd` がプロセス RSS をサンプリングする頻度は `rcapadm` で設定できます。「`rcapd` の動作間隔」を参照してください。

`rcapd` とともに使用されるコマンド

コマンド	説明
rcapstat(1)	上限が定義されたプロジェクトの資源使用率を監視します。
rcapadm(1M)	資源上限デーモンを構成します。構成済みの資源上限デーモンの現在の状態を表示します。資源上限制御を有効または無効にします。
rcapd(1M)	資源上限デーモン。

第 11 章資源上限デーモンの管理 (手順)

この章では、資源上限デーモン rcapd を構成して使用する手順について説明します。

rcapd の概要については、第 10 章資源上限デーモンによる物理メモリーの制御 (概要)を参照してください。

資源上限デーモンの構成と使用 (作業マップ)

タスク	説明	説明
メモリー上限実行しきい値を設定します。	プロセスが利用できる物理メモリーが少なくなったときに制限する上限を設定します。	「メモリー上限実行しきい値を設定する方法」
動作間隔を設定します。	この間隔は、資源上限デーモンが行う定期的な動作に適用されます。	「動作間隔を設定する方法」
資源上限制御を有効にします。	システムで資源上限制御を起動します。	「資源上限制御を有効にする方法」
資源上限制御を無効にします。	システムで資源上限制御を停止します。	「資源上限制御を無効にする方法」
上限とプロジェクトの情報を報告します。	報告を生成するためのコマンド例を表示します。	「上限とプロジェクトの情報の報告」
プロジェクトの常駐セットサイズを監視します。	プロジェクトの常駐セットサイズについて報告を生成します。	「プロジェクトの RSS の監視」
プロジェクトの作業セットサイズを決定します。	プロジェクトの作業セットサイズについて報告を生成します。	「プロジェクトの作業セットサイズの決定」
メモリー使用率とメモリー上限を報告します。	各サンプリング間隔に対応する報告の最後に、メモリー使用率と上限実行しきい値を示す行を出力します。	「メモリー使用率とメモリー上限実行しきい値の報告」

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

この節では、rcapadm コマンドを使用して資源上限デーモンを構成する手順について説明します。詳細は、「rcapd の構成」および rcapadm(1M) のマニュアルページを参照してください。rcapadm を使用してゾーンに一時的な資源上限を指定する方法についても説明します。

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

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

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

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

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割を作成してユーザーに割り当てる方法については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の管理 (作業マップ)」を参照してください。

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

参照

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

動作間隔を設定する方法

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

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割を作成してユーザーに割り当てる方法については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の管理 (作業マップ)」を参照してください。

-i オプションを使用して、動作間隔の値を設定します。
# rcapadm -i interval=value,...,interval=value
注 –
すべての動作間隔の値の単位は秒です。

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

資源上限制御をシステムで有効にする方法は 3 つあります。資源上限制御を有効にすると、さらに /etc/rcap.conf ファイルがデフォルト値で設定されます。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割を作成してユーザーに割り当てる方法については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の管理 (作業マップ)」を参照してください。

次のどちらかの方法で資源上限デーモンを有効にします。
- svcadm コマンドを使って、資源上限制御を有効にします。
  # svcadm enable rcap
- 資源上限デーモンを有効にして、ただちに起動し、かつ、システムをブートするたびに起動するようにします。次のように入力します。
  # rcapadm -E
- 資源上限デーモンをただちには起動せず、ブート時に有効にするには、-n オプションも指定します。
  # rcapadm -n -E

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

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

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割を作成してユーザーに割り当てる方法については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の管理 (作業マップ)」を参照してください。

次のどちらかの方法で資源上限デーモンを無効にします。
- svcadm コマンドを使用して、資源上限制御をオフにします。
  # svcadm disable rcap
- 資源上限デーモンを無効にして、ただちに停止し、かつ、システムをブートしても起動しないようにするには、次のように入力します。
  # rcapadm -D
- 資源上限デーモンを停止せずに無効にするには、-n オプションも指定します。
  # rcapadm -n -D
ヒント –
資源上限デーモンの安全な無効化

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

ゾーンに一時的な資源上限を指定する方法

この手順は、特定のゾーンで消費可能な最大のメモリー量を割り当てる場合に使用します。この値は、次の再起動までに限り有効です。持続的な上限を設定するには、zonecfg コマンドを使用します。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。

ゾーン my-zone に最大メモリーの値として 512M バイトを設定します。
# rcapadm -z testzone -m 512M

`rcapstat` による報告の生成

資源上限制御の統計を報告するには、rcapstat を使用します。「rcapstat による資源使用率の監視」コマンドを使って報告を生成する方法については、Monitoring Resource Utilization With 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 バイト) を反映して安定する場合があります。この値が、このプロジェクトのプロセスがページフォルトを頻繁に起こさずに動作できる、上限の最小値です。

user1 の上限が 6G バイトであるとき、サンプリング間隔の 5 秒ごとに、rcapd が作業負荷のメモリーの一部をページアウトするにつれて、RSS は減少して入出力は増加します。ページアウトの直後、これらのページを必要とする作業負荷は、(動作し続ける限り) メモリーをページインします。このサイクルは、例の中ほどで上限を10G バイトに上げるまで繰り返されます。その後、RSS は 6.1G バイトで安定します。作業負荷の RSS が上限より低くなったため、これ以後ページングは発生しません。また、ページングに関連する入出力は止まります。このため、観察時にプロジェクトが行なっていた作業の実行には、6.1G バイトが必要であったことがわかります。

vmstat(1M) および iostat(1M) のマニュアルページも参照してください。

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

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%

第 12 章資源プール (概要)

この章では、次の機能について説明します。

資源プール。マシン資源の区分に使用されます
動的資源プール (DRP)。設定されているシステムの目標に合うように、各資源プールの資源割り当てを動的に調整します

Solaris 10 11/06 リリースから、資源プールおよび動的資源プールが、Solaris サービス管理機能 (SMF) 内のサービスになりました。これらの各サービスは、別個に有効にできます。

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

この機能の使用手順については、第 13 章資源プールの作成と管理 (手順)を参照してください。

資源プールと動的資源プールの新機能

Solaris 10: システムイベントやアプリケーションの負荷変化に応じて各プールの資源割り当てを調整する機構が資源プールに追加されました。動的資源プールによって管理者が決定を行いやすくなり、決定を行う回数も減少します。管理者がシステム性能の目標を指定すると、それを維持するように自動的に調整が行われます。

projmod コマンドを使用して、/etc/project ファイル内の project.pool 属性を設定できるようになりました。

Solaris 10 の新機能の全一覧および Solaris リリースについての説明は、『Oracle Solaris 10 9/10 の新機能』を参照してください。

Solaris 10 11/06: 資源プールと動的資源プールが、SMF サービスになりました。

資源プールの紹介

「資源プール」を使用すると、作業負荷によって特定の資源が重複して消費されないように、作業負荷を分離することができます。このような方法で資源を確保すると、さまざまな作業負荷が混在するシステム上で予測どおりの性能を得ることができます。

資源プールは、プロセッサセット (pset) の構成やスケジューリングクラスの割り当て (任意) に対して一貫した構成機構を提供します。

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

この図は、プールが 1 つのプロセッサセットとオプションのスケジューリングクラスから構成されていることを示しています。

プールは、システムで使用可能なさまざまな資源セットを結合した特定のものと考えることができます。資源のさまざまな組み合わせを表す各種のプールを作成できます。

pool1: pset_default

pool2: pset1

pool3: pset1, pool.scheduler="FSS"

資源プールは、複数のパーティションをグループ化することにより、ラベル付けされている作業負荷とハンドルを対応付けることができます。/etc/project ファイル内の各プロジェクトエントリには単一のプールを関連付けることができます。それらのプールを指定するには、project.pool 属性を使用します。

プールが有効になっている場合、基本構成は「デフォルトプール」と「デフォルトプロセッサセット」から成ります。ユーザー定義のプールやプロセッサセットを作成し、構成に追加することもできます。CPU は 1 つのプロセッサセットだけに所属できます。ユーザー定義のプールやプロセッサセットは破棄できます。デフォルトプールとデフォルトプロセッサセットは破棄できません。

デフォルトプールの pool.default プロパティーは true に設定されます。デフォルトプロセッサセットの pset.default プロパティーは true に設定されます。したがって、デフォルトプールとデフォルトプロセッサセットはどちらも、名前が変更された場合でも識別できます。

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

動的資源プールの紹介

動的資源プールは、システムイベントやアプリケーション負荷の変化に対応して各プールの資源割り当てを動的に調整する機構を提供します。動的資源プールによって管理者が決定を行いやすくなり、決定を行う回数も減少します。管理者がシステム性能の目標を指定すると、それを維持するように自動的に調整が行われます。構成に変更を加えると、変更内容がログに記録されます。これらの機能は、主に資源コントローラ poold によって実行されます。動的資源割り当てが必要なときは、常にこのシステムデーモンをアクティブにしておく必要があります。poold は定期的にシステムの負荷を調べ、システムの性能を最適に保つために、資源消費に関する調整が必要かどうかを判定します。poold の構成は libpool の構成に保存されています。poold の詳細については、poold(1M) のマニュアルページを参照してください。

資源プールと動的資源プールの有効化/無効化について

資源プールおよび動的資源プールを有効化/無効化する方法については、「プール機能の有効化と無効化」を参照してください。

ゾーンで使用される資源プール

ヒント –

Solaris 10 8/07: システム上で構成済みの資源プールにゾーンを関連付ける代わりに、zonecfg コマンドを使用して、ゾーンの稼働中に有効になる一時プールを作成することもできます。詳細は、「Solaris 10 8/07: dedicated-cpu 資源」を参照してください。

ゾーンが有効になっているシステムの場合、1 つの非大域ゾーンには資源プールを 1 つだけ関連付けることができますが、特定のゾーンに割り当てたプールをそのゾーン専用にする必要はありません。また、大域ゾーンから poolbind コマンドを使用して、非大域ゾーンの個々のプロセスを別のプールに結合することもできません。非大域ゾーンをプールに関連付ける方法については、「ゾーンを構成、検証、および確定する」を参照してください。

プールに対してスケジューリングクラスを設定した場合は、そのプールに非大域ゾーンを関連付けると、そのゾーンではそのスケジューリングクラスがデフォルトで使用されます。

動的資源プールを使用している場合、実行中の poold インスタンスの有効範囲は大域ゾーンに制限されます。

poolstat ユーティリティーを非大域ゾーンで実行すると、そのゾーンに関連付けられているプールの情報だけが表示されます。非大域ゾーンで引数なしで pooladm コマンドを実行すると、そのゾーンに関連付けられているプールの情報だけが表示されます。

資源プールのコマンドについては、「資源プール機能で使用するコマンド」を参照してください。

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

資源プールは、多くの管理作業に適用できる汎用機構を提供します。

バッチ処理サーバー

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

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

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

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

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

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

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

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

多数のユーザーをサポートするサーバーを区分します。サーバーの区分によって、ユーザーごとの応答が時間をより確実に予測できる分離機構が提供されます。

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

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

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

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

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

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

システムの使用率

システムの目標を設定して適用します。

自動プールデーモンの機能を使用して、使用可能な資源を特定してから作業負荷を監視すると、指定した目標がいつ満たされなくなるかを検出できます。可能な場合はデーモンで修正操作を実行したり、状況をログに記録したりできます。

資源プールのフレームワーク

/etc/pooladm.conf 構成ファイルには、静的なプール構成が記述されます。静的構成では、資源プール機能に関連して管理者がシステムをどのように構成するかを記述できます。別のファイル名を指定することもできます。

サービス管理機能 (SMF) または pooladm - e コマンドを使って資源プールフレームワークを有効にする場合で、/etc/pooladm.conf ファイルが存在するときは、このファイル内の構成がシステムに適用されます。

資源プールフレームワーク内での資源の処置に関する情報は、カーネルで保持されます。これは動的構成と呼ばれ、特定のシステムの、ある時点での資源プール機能を表します。動的構成を表示するには、pooladm コマンドを使用します。プールや資源セットについて表示されるプロパティーの順序は、場合によって異なります。動的構成に対する変更は、次の方法で行われます。

静的構成ファイルを適用する、間接的な方法
poolcfg コマンドに -d オプションを使用する、直接的な方法

場合に応じて起動できるように、複数の静的プール構成ファイルを作成しておくことができます。cron ジョブで pooladm を起動して、複数のプール構成を使い分けることができます。cron ユーティリティーの詳細は、cron(1M) のマニュアルページを参照してください。

デフォルトでは、資源プールフレームワークは無効になっています。動的構成を作成したり変更したりするには、資源プールが有効になっている必要があります。資源プールフレームワークが無効になっている場合でも、poolcfg コマンドまたは libpool コマンドを使って静的構成ファイルを操作することはできます。プール機能が無効になっている場合、静的構成ファイルを作成することはできません。構成ファイルの詳細については、「プール構成の作成」を参照してください。

資源プールおよび poold システムデーモンで使用するコマンドについては、次のマニュアルページを参照してください。

`/etc/pooladm.conf` の内容

次の要素は、動的構成も含め、すべての資源プール構成に使用できます。

system: システムの全体的な動作に影響を与えるプロパティー
pool: 資源プールの定義
pset: プロセッサセットの定義
cpu: プロセッサの定義

これらの要素に含まれているプロパティーを操作することで、資源プールフレームワークの状態と動作を変更できます。たとえば、プールプロパティー pool.importance は、プールの相対的な重要性を示します。このプロパティーは、資源の競合が発生した場合の解決に使用されます。詳細は、libpool(3LIB) のマニュアルページを参照してください。

プールのプロパティー

プール機能では、プール、資源、または構成要素に設定される、名前と型の指定されたプロパティーがサポートされています。管理者は、プールのさまざまな要素に対して、追加のプロパティーを設定することもできます。プロジェクト属性に似たプロパティー名前空間が使用されます。

たとえば、次のコメントは、特定の Datatree データベースに pset が関連付けられていることを示します。

Datatree,pset.dbname=warehouse

プロパティーの型の詳細については、「poold のプロパティー」を参照してください。

注 –

いくつかの特殊プロパティーが内部使用のために予約されています。これらを設定したり削除したりすることはできません。詳細は、libpool(3LIB) のマニュアルページを参照してください。

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

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

Solaris ソフトウェアが起動すると、init スクリプトは /etc/pooladm.conf ファイルが存在するかどうかを検査します。このファイルが検出され、プールが有効化されると、pooladm が呼び出され、この構成をアクティブなプール構成にします。システムは、/etc/pooladm.conf で指定されている編成に従って、動的な構成を作成し、マシンの資源は指定どおりに区分されます。
Solaris システムが起動しているときは、pooladm コマンドを使用して、プール構成が存在しない場合はプール構成を起動したり、プール構成を変更したりできます。デフォルトでは、pooladm コマンドは /etc/pooladm.conf の内容を使用します。ただし、別のディレクトリとファイル名を指定し、そのファイルを使用してプール構成を変更することもできます。

資源プールを有効化または無効化する方法については、「プール機能の有効化と無効化」を参照してください。ユーザー定義のプールや資源が使用されている間は、プール機能を無効にすることはできません。

資源プールを構成するには、スーパーユーザーの特権を持っているか、またはプロファイルの一覧内に Process Management プロファイルが含まれている必要があります。System Administrator 役割には、Process Management プロファイルが含まれています。

poold 資源コントローラは、動的資源プール機能とともに起動されます。

`project.pool` 属性

/etc/project ファイル内のプロジェクトエントリに project.pool 属性を追加すると、そのエントリに単一のプールを関連付けることができます。プロジェクトで開始される新しい作業は、適切なプールに結合されます。詳細は、第 2 章プロジェクトとタスク (概要)を参照してください。

たとえば、projmod コマンドを使用して、/etc/project ファイル内のプロジェクト sales に project.pool 属性を設定できます。

# projmod -a -K project.pool=mypool sales

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

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

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

DR 処理によってプール構成が無効になった場合、操作は失敗し、メッセージログにメッセージが書き込まれます。構成処理を強制的に最後まで実行するには、DR の強制オプションを使用します。強制オプションで処理を続行すると、プール構成は、新しい資源構成に合うように変更されます。DR 処理と強制オプションについては、使用している Sun ハードウェアの動的再構成に関するユーザーガイドを参照してください。

動的資源プールを使用している場合、poold デーモンがアクティブになっている間に、その制御からパーティションが除外されることがあります。詳細は、「資源不足の特定」を参照してください。

プール構成の作成

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

system
pool
pset
cpu

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

プールが有効になっている場合、構造化された /etc/pooladm.conf ファイルを次の 2 つの方法で作成できます。

pooladm コマンドに -s オプションを付けて実行して、現在のシステム上の資源を検出し、その結果を構成ファイルに記録します。

この方法をお勧めします。プール機能で操作できるシステム上のアクティブな資源と構成要素がすべて記録されます。資源には、既存のプロセッサセットの構成が含まれます。最後に、プロセッサセットの名前を変更したり、必要に応じてプールを作成したりして、構成を変更できます。
poolcfg コマンドに -c オプションと discover サブコマンドまたは create system name サブコマンドを付けて実行して、新しいプール構成を作成します。

これらのオプションは、以前のリリースとの下位互換性を保つために残されています。

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

動的構成の直接操作

poolcfg コマンドに -d オプションを付けて実行すると、動的構成内の CPU 資源タイプを直接操作できます。資源を転送するには、次の 2 つの方法があります。

識別された利用可能な資源すべてをセット間で転送するように要求します。
特定の ID を持つ資源だけをターゲットセットに転送します。資源構成が変更されたときやシステムの再起動後は、資源に関連付けられているシステム ID が変わることがあります。

具体例は、「資源の転送」を参照してください。

資源転送によって poold からアクションが引き起こされることがあります。詳細は、「poold の概要」を参照してください。

`poold` の概要

プールの資源コントローラ poold は、システムターゲットと観察可能な統計情報を使用して、管理者によって指定されたシステム性能の目標を維持します。動的資源割り当てが必要なときは、常にこのシステムデーモンをアクティブにしておく必要があります。

poold 資源コントローラは、使用可能な資源を特定してから作業負荷を監視して、システム使用率に関する目標がいつ満たされなくなるかを検出できます。poold は、これらの目標の観点から別の構成を検討し、改善操作を実行します。可能な場合は、目標を満たすように資源を再構成します。この操作が不可能な場合は、ユーザーによって指定された目標が達成不可能になったことをログに記録します。再構成を行なった後、デーモンは作業負荷目標の監視を再開します。

poold では決定の履歴が保持され、確認に使用されます。決定履歴を使用すると、それまでに行なった再構成のうち、改善効果を示さなかったものを削除できます。

作業負荷の目標が変更された場合や、システムで使用可能な資源が変更された場合は、再構成が非同期に実行されることもあることに注意してください。

動的資源プールの管理

DRP サービスは、サービス識別子 svc:/system/pools/dynamic 下のサービス管理機能 (SMF) によって管理されます。

有効化、無効化、再起動の要求など、このサービスに関する管理作業は、svcadm コマンドを使用して実行できます。サービスの状態は、svcs コマンドを使用して照会できます。詳細は、svcs(1) および svcadm(1M) のマニュアルページを参照してください。

DRP の制御方法として望ましいのは SMF インタフェースですが、下位互換性を維持するために、次の方法も使用できます。

動的資源割り当てが不要になった場合は、SIGQUIT シグナルまたは SIGTERM シグナルを使って poold を停止できます。これらのシグナルはどちらも、poold を正常に終了させます。
poold では、資源やプールの構成の変更が自動的に検出されます。ただし、SIGHUP シグナルを使用して、再構成を強制的に実行することもできます。

構成の制約と目標

poold は、管理者の指示に基づいて再構成を行います。これらの指示は、一連の制約および目標として指定します。poold はこれらの指定に基づき、可能性のあるさまざまな構成を、既存の構成に対する相対値として決定します。次に poold は、現在の構成の資源割り当てを変更して、候補となる新しい構成を生成します。

構成の制約

制約は、構成に加えることのできる変更を一部除外することで、作成可能な構成の範囲に影響を与えます。libpool 構成で次の制約を指定できます。

CPU 割り当ての最小値と最大値
セットから移動できない固定構成要素

プールプロパティーの詳細については、libpool(3LIB) のマニュアルページと「プールのプロパティー」を参照してください。

`pset.min` プロパティーと `pset.max` プロパティーの制約

これら 2 つのプロパティーは、プロセッサセットに割り当てることのできるプロセッサの最小数と最大数を制限します。これらのプロパティーの詳細については、表 12–1 を参照してください。

同じ Solaris インスタンスの資源パーティションどうしであれば、これらの制約の範囲内で、あるパーティションから別のパーティションに資源を割り当てることができます。資源セットに関連付けられているプールに結合することで、資源にアクセスできるようになります。この結合はログイン時に実行されるか、または、PRIV_SYS_RES_CONFIG 特権を持っている管理者が手動で行います。

`cpu.pinned` プロパティーの制約

cpu-pinned プロパティーは、DRP で特定の CPU を現在のプロセッサセットから移動してはならないことを示します。この libpool プロパティーを設定すると、プロセッサセット内で実行されている特定のアプリケーションでのキャッシュ使用率を最大限に高めることができます。

このプロパティーの詳細については、表 12–1 を参照してください。

`pool.importance` プロパティーの制約

pool.importance プロパティーは、管理者が定義した、プールの相対的な重要度を示します。

構成の目標

目標は制約と同様の方法で指定されます。目標の全一覧については、表 12–1 を参照してください。

目標には 2 つのカテゴリがあります。

作業負荷に依存する目標: 作業負荷に依存する目標とは、システムで実行される作業負荷の性質によって変化する目標です。たとえば、utilization 目標などがあります。資源セットの使用率の数値は、そのセットでアクティブになっている作業負荷の性質によって変化します。
作業負荷に依存しない目標: 作業負荷に依存しない目標とは、システムで実行される作業負荷の性質によって変化しない目標です。たとえば、CPU の locality 目標などがあります。資源セットの近傍性の評価値は、そのセットでアクティブになっている作業負荷の性質によって変化することはありません。

次の 3 種類の目標を定義できます。

名前	有効な要素	演算子	値
`wt-load`	`system`	なし	なし
`locality`	`pset`	なし	`loose` \| `tight` \| `none`
`utilization`	`pset`	`<` `>` `~`	`0`–`100%`

目標は、libpool 構成内のプロパティー文字列に格納されます。プロパティー名は、次のとおりです。

system.poold.objectives
pset.poold.objectives

目標の構文は次のとおりです。

objectives = objective [; objective]*
objective = [n:] keyword [op] [value]

どの目標にも、オプションで重要性を表す接頭辞を付けることができます。重要性の値は目標に乗算され、この目標が目標関数の評価に与える影響を高めます。指定できる範囲は、0 から INT64_MAX (9223372036854775807) までです。指定されていない場合、重要性のデフォルト値は 1 です。

一部の要素タイプでは、複数の種類の目標がサポートされています。pset などはその一例です。このような要素には、複数の種類の目標を指定できます。また、1 つの pset 要素に複数の使用率目標を指定することもできます。

使用例については、「構成の目標を定義する方法」を参照してください。

`wt-load` 目標

wt-load 目標では、資源の使用率に合わせて資源を割り当てるような構成が有利に導かれます。この目標が有効になっていると、より多くの資源を使用する資源セットには、より多くの資源が与えられることになります。wt-load は「重み付けされた負荷 (weighted load)」を意味します。

最小値と最大値のプロパティーを使って満足のいく制約を設定したあとで、これらの制約の範囲内でデーモンが自由に資源を操作できるようにする場合に、この目標を使用してください。

`locality` 目標

locality 目標は、近傍性グループ (lgroup) データによって測定される近傍性が、選択された構成に対して与える影響を変化させます。近傍性は応答時間と定義することもできます。lgroup は、CPU 資源とメモリー資源を表します。lgroup は、Solaris システムで資源どうしの距離を調べるために使用されます。測定単位は時間です。近傍性グループによる抽象化の詳細については、『プログラミングインタフェース』の「近傍性グループの概要」を参照してください。

この目標には、次の 3 つの値のいずれかを指定できます。

tight: この値を設定すると、資源の近傍性を最大にするような構成が有利に導かれます。
loose: この値を設定すると、資源の近傍性を最小にするような構成が有利に導かれます。
none: この値を設定すると、どのような構成が有利になるかは、資源の近傍性に依存しません。これは locality 目標のデフォルト値です。

一般に、locality 目標は tight に設定することをお勧めします。ただし、メモリー帯域幅を最大にする場合や、資源セットに対する DR 操作の影響を最小にする場合は、この目標を loose に設定するか、デフォルト値の none にしておいてください。

`utilization` 目標

utilization 目標では、指定された使用率目標を満たしていないパーティションに資源を割り当てるような構成が有利に導かれます。

この目標は、演算子と値で指定されます。演算子は次のとおりです。

<: 「小なり」演算子は、指定された値が最大のターゲット値であることを示します。
>: 「大なり」演算子は、指定された値が最小のターゲット値であることを示します。
~: 「ほぼ等しい」演算子は、指定された値がターゲット値であり、いくらかの変動が許容されることを示します。

pset には、演算子の種類ごとに使用率目標を 1 つ設定できます。

~ 演算子を設定した場合、< 演算子や > 演算子は設定できません。
< 演算子や > 演算子を設定した場合、~ 演算子は設定できません。< 演算子の設定と > 演算子の設定が互いに矛盾してはならないことに注意してください。

< 演算子と > 演算子の両方を使用すると、範囲を指定できます。これらの値は、重複しないように検証されます。

構成目標の例

次の例では、pset に対する次のような目標が poold によって評価されます。

utilization を 30% から 80% の範囲に保つ必要がある。
プロセッサセットの locality を最大にする必要がある。
各目標の重要性はデフォルト値の 1 とする。

例 12–1 `poold` の目標の例

pset.poold.objectives "utilization > 30; utilization < 80; locality tight"

その他の使用例については、「構成の目標を定義する方法」を参照してください。

`poold` のプロパティー

プロパティーには 4 つのカテゴリがあります。

構成
制約
目標
目標パラメータ

表 12–1 定義済みのプロパティー名


プロパティー名	種類	カテゴリ	説明
`system.poold.log-level`	string	構成	ロギングレベル
`system.poold.log-location`	string	構成	ログの場所
`system.poold.monitor-interval`	uint64	構成	監視のサンプリング間隔
`system.poold.history-file`	string	構成	決定履歴の場所
`pset.max`	uint64	制約	このプロセッサセットに割り当てられる CPU の最大数
`pset.min`	uint64	制約	このプロセッサセットに割り当てられる CPU の最小数
`cpu.pinned`	bool	制約	CPU がこのプロセッサセットに固定されているかどうか
`system.poold.objectives`	string	目標	`poold` の目標式の構文に従った書式付き文字列
`pset.poold.objectives`	string	目標	`poold` の目標式の構文に従った書式付き文字列
`pool.importance`	int64	目標パラメータ	ユーザーが割り当てた重要性

`poold` の設定可能な機能

デーモンの動作の次のような部分は設定可能です。

監視の間隔
ロギングレベル
ログの場所

これらのオプションは、プール構成で指定します。コマンド行から poold を起動する方法でも、ログレベルを制御できます。

`poold` の監視間隔

プロパティー名 system.poold.monitor-interval を使用して、値をミリ秒単位で指定します。

`poold` のログ情報

ログを通じて 3 つのカテゴリの情報が提供されます。これらのカテゴリは、ログで次のように識別されています。

構成
監視
最適化

プロパティー名 system.poold.log-level を使用して、ログパラメータを指定します。このプロパティーが指定されていない場合、ログレベルのデフォルト値は NOTICE です。パラメータのレベルは階層的になっています。ログレベルとして DEBUG を設定すると、poold は、すべての定義済みメッセージをログに記録します。INFO レベルでは、ほとんどの管理者にとって適度な情報が得られます。

コマンド行で poold コマンドに -l オプションとパラメータを付けて実行すると、生成するログ情報のレベルを指定できます。

次のパラメータを使用できます。

ALERT
CRIT
ERR
WARNING
NOTICE
INFO
DEBUG

これらのパラメータレベルは、syslog に使用される同様のレベルと直接対応づけられます。syslog の使用方法の詳細については、「ログの場所」を参照してください。

poold のログ機能を構成する方法の詳細については、「poold のログレベルを設定する方法」を参照してください。

情報ログ機能の構成

生成されるメッセージの種類は次のとおりです。

ALERT: libpool 構成へのアクセスに関連する問題など、libpool 機能の基本的な予期せぬ障害。これによってデーモンは終了します。今すぐ管理者が対応する必要があります。
CRIT: 予期せぬ障害に起因する問題。これによってデーモンは終了します。今すぐ管理者が対応する必要があります。
ERR: 処理を制御するユーザー指定のパラメータに関連する問題。資源セットの使用率目標が衝突していて、解決不能な場合などです。管理者が介入して目標を修正する必要があります。poold は、衝突している目標を無視することで、改善操作を試みます。ただし、エラーによっては、デーモンが終了することもあります。
WARNING: 構成パラメータの設定に関連する警告。構成パラメータの設定が技術的には正しくても、特定の実行環境には適さない場合などです。たとえば、すべての CPU 資源を固定にすると、poold はプロセッサセット間で CPU 資源を移動することができなくなります。
DEBUG: 構成処理をデバッグするときに必要となる詳細情報が含まれたメッセージ。通常は、管理者がこの情報を使用することはありません。

情報ログ機能の監視

生成されるメッセージの種類は次のとおりです。

CRIT: 予期せぬ監視障害に起因する問題。これによってデーモンは終了します。今すぐ管理者が対応する必要があります。
ERR: 予期せぬ監視エラーに起因する問題。管理者が介入して修正する必要がある場合もあります。
NOTICE: 資源制御の領域移行に関するメッセージ。
INFO: 資源使用率の統計情報に関するメッセージ。
DEBUG: 監視処理をデバッグするときに必要となる詳細情報が含まれたメッセージ。通常は、管理者がこの情報を使用することはありません。

情報ログ機能の最適化

生成されるメッセージの種類は次のとおりです。

WARNING

これらのメッセージは、最適な決定を行う際の問題に関連して表示されることがあります。たとえば、最小値と最大値または固定構成要素の数によって、厳しすぎる制約を資源セットに与えている場合などです。

これらのメッセージは、最適な再割り当てを行う際の、予期せぬ制限に起因する問題について表示されることがあります。たとえば、資源を消費するプロセスがバインドされているプロセッサセットから最後のプロセッサを削除する場合などです。

NOTICE

これらのメッセージは、使用可能な構成や、決定履歴の上書きに起因して実装されない構成について表示されることがあります。

INFO

これらのメッセージは、考慮される代替構成について表示されることがあります。

DEBUG

最適化処理をデバッグするときに必要となる詳細情報が含まれたメッセージ。通常は、管理者がこの情報を使用することはありません。

ログの場所

system.poold.log-location プロパティーを使用して、poold のログの出力先を指定します。poold の出力先として SYSLOG の場所を指定できます (syslog(3C) のマニュアルページを参照)。

このプロパティーが指定されていない場合、poold ログのデフォルトの出力先は /var/log/pool/poold です。

コマンド行から poold を呼び出す場合、このプロパティーは使用しません。ログエントリは、呼び出しを行なった端末の stderr に出力されます。

`logadm` によるログ管理

poold がアクティブになっている場合、logadm.conf ファイル内に、デフォルトファイル /var/log/pool/poold を管理するためのエントリが含まれています。このエントリは次のとおりです。

/var/log/pool/poold -N -s 512k

logadm(1M) および logadm.conf(4) のマニュアルページを参照してください。

動的資源割り当てのしくみ

この節では、資源を動的に割り当てるために poold で使用される手順と要因について説明します。

使用可能な資源について

poold プロセスの有効範囲内で使用できるすべての資源が、使用可能な資源と見なされます。1 つの Solaris インスタンスが最大の制御範囲になります。

ゾーンが有効になっているシステムの場合、実行中の poold インスタンスの有効範囲は、大域ゾーンに制限されます。

使用可能な資源の特定

資源プールには、アプリケーションで消費できるすべてのシステム資源が含まれます。

実行中の Solaris インスタンスごとに、1 つのパーティションには、CPU など 1 種類の資源を割り当てる必要があります。1 種類の資源を 1 つまたはそれ以上のパーティションに割り当ててもかまいません。各パーティションには、一意の資源セットが含まれます。

たとえば、4 つの CPU と 2 つのプロセッサセットを持つマシンは、次のように設定されます。

pset 0: 0 1

pset 1: 2 3

ここで、コロンのあとの 0、1、2、3 という数字は、CPU の ID を表しています。これら 2 つのプロセッサセットで、4 つの CPU すべてが使用されていることに注目してください。

このマシンで次のような設定は不可能です。

pset 0: 0 1

pset 1: 1 2 3

CPU 1 を同時に割り当てることができる pset は 1 つだけなので、このような設定はできません。

資源が属しているパーティション以外のパーティションからは、その資源にアクセスすることはできません。

使用可能な資源を発見するために、poold はアクティブなプール構成を調べてパーティションを見つけます。制御対象となっている資源の種類ごとに、すべてのパーティションに含まれているすべての資源が集計され、使用可能な資源の合計量が求められます。

poold では、この資源量を基にして処理が行われます。ただし、この基本量に制約が適用され、poold で割り当てを行う必要がある際の柔軟性が制限されることもあります。使用可能な制約については、「構成の制約」を参照してください。

資源不足の特定

poold の制御範囲とは、効率のよい区分と管理を主に poold が担当している、使用可能な資源セットのことです。ただし、この制御範囲にある資源を操作できる機構がほかにもあり、それが構成に影響を与えることもあります。poold がアクティブになっている間に特定のパーティションが制御範囲外になった場合、poold は使用可能な資源を適切に操作することによってその制御を取り戻そうとします。poold デーモンは、有効範囲内に追加の資源を見つけられない場合、資源不足に関する情報をログに記録します。

資源使用率の判定

poold は通常、その制御範囲にある資源の使用率を監視することに時間の大部分を費やします。この監視は、作業負荷に依存する目標が満たされているかどうかを確認するために実行されます。

たとえば、プロセッサセットの場合、セット内のすべてのプロセッサについてすべての測定が実行されます。資源使用率は、サンプリング間隔に対して、資源が使用された時間の割合を示します。資源使用率はパーセンテージで表され、0 - 100 の値です。

制御違反の特定

「構成の制約と目標」で説明した指示は、システムが目標を満たさないことを検出するために使用されます。これらの目標は、作業負荷に直接関連しています。

ユーザーが設定した目標を満たしていないパーティションは、制御違反です。制御違反には、同期と非同期の 2 種類があります。

同期目標違反は、デーモンによって作業負荷の監視中に検出されます。
非同期目標違反は、デーモンの監視動作とは無関係に発生します。

非同期の目標違反は、次のようなイベントによって引き起こされます。

制御範囲に対して資源が追加または削除された。
制御範囲が再構成された。
poold 資源コントローラが再起動された。

作業負荷に関連しない目標が目標関数の評価に与える影響は、評価のたびに一定であると見なされます。作業負荷に関連しない目標が再評価されるのは、いずれかの非同期違反によって再評価処理が引き起こされたときだけです。

適切な改善操作の決定

資源コントローラは、資源を消費するプロセスで資源が不足していると判定した場合、まずその資源を増やして性能を改善しようとします。

制御範囲について構成で指定された目標を満たすように、別の構成が検討され評価されます。

この処理では、資源の移動結果を監視し、各資源パーティションの応答性を評価しながら、徐々に細かい調整が行われます。決定履歴を参照して、それまでに行なった再構成のうちで改善効果を示さなかったものが削除されます。履歴データの関連度をより詳しく評価するために、プロセスの名前や数量といったほかの情報も使用されます。

修正操作を実行できない場合、デーモンは状況をログに記録します。詳細は、「poold のログ情報」を参照してください。

`poolstat` によるプール機能と資源使用率の監視

システムのプールが有効になっている場合に資源の使用率を監視するには、poolstat ユーティリティーを使用します。このユーティリティーは、システム上でアクティブになっているすべてのプールを調べ、選択された出力モードに基づいて統計情報を報告します。poolstat の統計を使用すると、どの資源パーティションの使用率が高いかを判定できます。これらの統計情報を解析して、システムで多くの資源が要求されたときに資源の再割り当てを行う方法を決定できます。

poolstat ユーティリティーのオプションを使用すると、特定のプールを調べたり、資源セット固有の統計情報を報告したりできます。

システムにゾーンが実装されている場合は、非大域ゾーンで poolstat を使用すると、そのゾーンのプールに関連付けられている資源に関する情報が表示されます。

poolstat ユーティリティーの詳細については、poolstat(1M) のマニュアルページを参照してください。poolstat の作業と使用方法については、「poolstat を使ってプールに関連付けられている資源について統計情報を報告する」を参照してください。

`poolstat` の出力

デフォルトの出力形式では、poolstat は、見出し行を出力したあと、プールごとに 1 行ずつ表示されます。各プールの行は、プール ID とプール名で始まります。それに続く列は、プールに接続されているプロセッサセットに関する統計データです。複数のプールに接続されている資源セットは、各プールで 1 回ずつ表示されるので、複数回表示されます。

列見出しは次のとおりです。

id

プール ID。

pool

プール名。

rid

資源セット ID。

rset

資源セット名。

type

資源セットの種類。

min

資源セットの最小サイズ。

max

資源セットの最大サイズ。

size

資源セットの現在のサイズ。

used

資源セットのうちで現在使用されている部分のサイズ。

この値は、資源セットの使用率に資源セットのサイズを乗算して計算されます。前回のサンプリング間隔で資源セットが再構成されている場合、この値は報告されないことがあります。報告されなかった値はハイフン (-) で示されます。

load

資源セットに加えられている負荷の絶対値。

このプロパティーの詳細については、libpool(3LIB) のマニュアルページを参照してください。

poolstat の出力では、次のことを指定できます。

列の順序
表示する見出し

`poolstat` の動作間隔の調整

poolstat で実行する操作をカスタマイズできます。報告用のサンプリング間隔、および統計を繰り返す回数を設定できます。

interval: poolstat が実行する定期的な処理の間隔を調整します。すべての間隔は秒単位で指定します。
count: 統計を繰り返す回数を指定します。デフォルトでは、poolstat は 1 回だけ統計情報を報告します。

interval と count を指定しなかった場合、統計は 1 回だけ報告されます。interval を指定し、count を指定しなかった場合、統計報告が無限に繰り返されます。

資源プール機能で使用するコマンド

次の表に示すコマンドは、プール機能を管理するための主要なインタフェースとなります。ゾーンが有効になっているシステムでこれらのコマンドを使用する方法については、「ゾーンで使用される資源プール」を参照してください。

マニュアルページ	説明
pooladm(1M)	システムのプール機能を有効または無効にします。特定の構成をアクティブにします。または、現在の構成を削除して、関連付けられている資源をデフォルトの状態に戻します。オプションを指定しないで実行すると、`pooladm` は、現在の動的プール構成を表示します。
poolbind(1M)	プロジェクト、タスク、およびプロセスを手動で資源プールに結合できます。
poolcfg(1m)	プールやセットに対する構成操作を実行します。このツールを使って作成された構成は、`pooladm` によってターゲットホスト上でインスタンス化されます。 `poolcfg` に `-c` オプションと `info` サブコマンド引数を付けて実行すると、`/etc/pooladm.conf` に保存されている静的構成の情報が表示されます。このコマンドにファイル名の引数を追加すると、そのファイルに保存されている静的構成の情報が表示されます。たとえば、`poolcfg` `-c` `info` `/tmp/newconfig` では、`/tmp/newconfig` というファイルに保存されている静的構成の情報が表示されます。
poold(1M)	プールシステムデーモン。このデーモンは、システムターゲットと観察可能な統計情報を使用して、管理者によって指定されたシステム性能の目標を維持します。目標が満たされていないときに修正操作を実行できない場合、`poold` は状況をログに記録します。
poolstat(1M)	プールに関連付けられている資源について統計情報を表示します。システム管理者にとって性能解析が簡単になり、資源を区分または再区分する作業に役立つ情報が得られます。特定のプールを調べたり、資源セット固有の統計情報を報告したりするためのオプションも用意されています。

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

第 13 章資源プールの作成と管理 (手順)

この章では、システムの資源プールを設定し管理する方法について説明します。

資源プールの概要については、第 12 章資源プール (概要)を参照してください。

動的資源プールの管理 (作業マップ)

タスク	説明	説明
資源プールを有効または無効にします。	システムの資源プールをアクティブまたは無効にします。	「プール機能の有効化と無効化」
動的資源プールを有効または無効にします。	システムの動的資源プール機能をアクティブまたは無効にします。	「プール機能の有効化と無効化」
静的な資源プール構成を作成します。	現在の動的構成と一致する静的構成ファイルを作成します。詳細は、「資源プールのフレームワーク」を参照してください。	「静的構成を作成する方法」
資源プール構成を変更します。	追加のプールを作成するなどして、システムのプール構成を変更します。	「構成の変更方法」
資源プールをスケジューリングクラスに対応付けます。	プールをスケジューリングクラスに対応付けることで、プールに結合されているすべてのプロセスが、指定されたスケジューラを使用できるようにします。	「プールをスケジューリングクラスに対応付ける方法」
構成の制約を設定し、構成の目標を定義します。	`poold` に対して、修正操作を実行するときに考慮する目標を指定します。構成の目標の詳細については、「`poold` の概要」を参照してください。	「構成の制約を設定する方法」および「構成の目標を定義する方法」
ログのレベルを設定します。	`poold` で生成するログ情報のレベルを指定します。	「`poold` のログレベルを設定する方法」
`poolcfg` コマンドでテキストファイルを使用します。	`poolcfg` コマンドにテキストファイルから入力します。	「`poolcfg` でコマンドファイルを使用する方法」
カーネルで資源を転送します。	カーネルで資源を転送します。たとえば、特定の ID を持つ資源をターゲットセットに転送します。	「資源の転送」
プール構成を起動します。	デフォルト構成ファイル内の構成を起動します。	「プール構成を起動する方法」
プール構成を確定する前に、プール構成を検証します。	検証が実行されるとどうなるかをテストするために、プール構成を検証します。	「構成を確定する前に構成を検証する方法」
システムからプール構成を削除します。	プロセッサセットなど、対応付けられているすべての資源がデフォルトの状態に戻ります。	「プール構成を削除する方法」
プロセスをプールに結合します。	システムで実行中のプロセスを資源プールに手動で対応付けます。	「プロセスをプールに結合する方法」
タスクやプロジェクトをプールに結合します。	タスクやプロジェクトを資源プールに対応付けます。	「タスクまたはプロジェクトをプールに結合する方法」
新しいプロセスを資源プールに結合します。	プロジェクト内の新しいプロセスを特定のプールに自動的に結合するには、`project` データベース内の各エントリに属性を追加します。	「プロジェクトの `project.pool` 属性を設定する方法」
`project` 属性を使ってプロセスを別のプールに結合します。	新たに開始されるプロセスについて、プールとの結合を変更します。	「`project` 属性を使ってプロセスを別のプールに結合する方法」
`poolstat` ユーティリティーを使って報告を生成します。	指定した間隔で複数の報告を生成します。	「特定の間隔で複数の報告を生成する」
資源セットの統計情報を報告します。	`poolstat` ユーティリティーを使って pset 資源セットの統計情報を報告します。	「資源セットの統計情報を報告する」

プール機能の有効化と無効化

Solaris 10 11/06 リリースから、svcadm コマンド (svcadm(1M) のマニュアルページを参照) を使って、システム上の資源プールサービスおよび動的資源プールサービスを有効または無効に設定できるようになりました。

pooladmコマンド (pooladm(1M) のマニュアルページを参照) を使用すると、次のタスクも実行できます。

プール機能を有効にして、プールを操作できるようにします
プール機能を無効にして、プールを操作できないようにします

注 –

システムをアップグレードする際に、資源プールフレームワークが有効で、/etc/pooladm.conf ファイルが存在する場合、プールサービスが有効になり、このファイル内の構成がシステムに適用されます。

Solaris 10 11/06 以降: `svcadm` を使って資源プールサービスを有効にする方法

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

資源プールサービスを有効にします。
# svcadm enable system/pools:default

Solaris 10 11/06 以降: `svcadm` を使って資源プールサービスを無効にする方法

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

資源プールサービスを無効にします。
# svcadm disable system/pools:default

Solaris 10 11/06 以降: `svcadm` を使って動的資源プールサービスを有効にする方法

スーパーユーザーになるか、Service Management 権利プロファイルが含まれている役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の作成方法およびユーザーに役割を割り当てる方法については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」と『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の管理 (作業マップ)」を参照してください。

動的資源プールサービスを有効にします。
# svcadm enable system/pools/dynamic:default

例 13–1 資源プールサービスに対する動的資源プールサービスの依存

この例では、DRP を実行する場合に、最初に資源プールを有効にする必要があることを示します。

資源プールと動的資源プールの間には、依存関係があります。DRP は、資源プールに依存するサービスになっています。DRP の有効化/無効化は、資源プールとは関係なく実行できます。

次の例では、資源プールと動的資源プールの両方が現在無効に設定されています。

# svcs *pool*
STATE          STIME    FMRI
disabled       10:32:26 svc:/system/pools/dynamic:default
disabled       10:32:26 svc:/system/pools:default

動的資源プールを有効にします。

# svcadm enable svc:/system/pools/dynamic:default
# svcs -a | grep pool
disabled       10:39:00 svc:/system/pools:default
offline        10:39:12 svc:/system/pools/dynamic:default

DRP サービスはまだオフラインです。

svcs コマンドの -x オプションを使って、DRP サービスがオフラインになっている原因を特定します。

# svcs -x *pool*
svc:/system/pools:default (resource pools framework)
 State: disabled since Wed 25 Jan 2006 10:39:00 AM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: libpool(3LIB)
   See: pooladm(1M)
   See: poolbind(1M)
   See: poolcfg(1M)
   See: poolstat(1M)
   See: /var/svc/log/system-pools:default.log
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/pools/dynamic:default (dynamic resource pools)
 State: offline since Wed 25 Jan 2006 10:39:12 AM GMT
Reason: Service svc:/system/pools:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
   See: poold(1M)
   See: /var/svc/log/system-pools-dynamic:default.log
Impact: This service is not running.

資源プールサービスを有効にして、DRP サービスを実行可能にします。

# svcadm enable svc:/system/pools:default

svcs *pool* コマンドを使用すると、システムによって次の情報が表示されます。

# svcs *pool*
STATE          STIME    FMRI
online         10:40:27 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default

例 13–2 資源プールサービスが無効な場合の動的資源プールへの影響

両方のサービスがオンラインで、資源プールサービスを無効にする場合は、次のコマンドを実行します。

# svcadm disable svc:/system/pools:default

svcs *pool* コマンドを使用すると、システムによって次の情報が表示されます。

# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default
# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default

ただし、資源プールサービスが無効になるため、結果として DRP サービスが offline になります。

# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
offline        10:41:12 svc:/system/pools/dynamic:default

DRP サービスがオフラインになっている原因を特定します。

# svcs -x *pool*
svc:/system/pools:default (resource pools framework)
 State: disabled since Wed 25 Jan 2006 10:41:05 AM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: libpool(3LIB)
   See: pooladm(1M)
   See: poolbind(1M)
   See: poolcfg(1M)
   See: poolstat(1M)
   See: /var/svc/log/system-pools:default.log
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/pools/dynamic:default (dynamic resource pools)
 State: offline since Wed 25 Jan 2006 10:41:12 AM GMT
Reason: Service svc:/system/pools:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
   See: poold(1M)
   See: /var/svc/log/system-pools-dynamic:default.log
Impact: This service is not running.

DRP が機能するためには、資源プールを起動する必要があります。たとえば、pooladm コマンドと -e オプションを使って資源プールを起動できます。

# pooladm -e

その後、svcs *pool* コマンドを実行すると、次のように表示されます。

# svcs *pool*
STATE          STIME    FMRI
online         10:42:23 svc:/system/pools:default
online         10:42:24 svc:/system/pools/dynamic:default

Solaris 10 11/06 以降: `svcadm` を使って動的資源プールサービスを無効にする方法

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

動的資源プールサービスを無効にします。
# svcadm disable system/pools/dynamic:default

`pooladm` を使って資源プールを有効にする方法

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プール機能を有効にします。
# pooladm -e

`pooladm` を使って資源プールを無効にする方法

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プール機能を無効にします。
# pooladm -d

プールの構成

静的構成を作成する方法

-s オプションを付けて /usr/sbin/pooladm を実行して、現在の動的構成と一致する静的構成ファイルを作成します。別のファイル名を指定した場合を除き、デフォルトの場所 /etc/pooladm.conf が使用されます。

pooladm コマンドに -c オプションを付けて実行して、構成を確定します。次に、pooladm コマンドに -s オプションを付けて実行して、動的構成の状態と一致するように静的構成ファイルを更新します。

注 –

動的構成と一致する新しい構成を作成するには、以前の機能 poolcfg -c discover を使用するよりも、新機能 pooladm -s を使用することをお勧めします。

始める前に

使用しているシステムでプールを有効にします。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

現在の動的構成と一致するように静的構成ファイルを更新します。
# pooladm -s

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

構成には、システムによって作成されたデフォルトの要素が含まれています。

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

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment 
                pset    pset_default

        pset pset_default
                int     pset.sys_id -1
                boolean pset.default true
                uint    pset.min 1
                uint    pset.max 65536
                string  pset.units population
                uint    pset.load 10
                uint    pset.size 4
                string  pset.comment 
                boolean testnullchanged true

                cpu
                        int     cpu.sys_id 3
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 2
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 1
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 0
                        string  cpu.comment 
                        string  cpu.status on-line

/etc/pooladm.conf にある構成を確定します。
# pooladm -c

(省略可能) /tmp/backup という静的構成ファイルに動的構成をコピーするには、次のように入力します。
# pooladm -s /tmp/backup

構成の変更方法

構成を拡張するために、pset_batch というプロセッサセットと pool_batch というプールを作成します。次に、このプールとプロセッサセットを結合によって対応付けます。

サブコマンドの引数に空白が含まれている場合は、引用符で囲むことを忘れないでください。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

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

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

pool_batch というプールを作成します。
# poolcfg -c 'create pool pool_batch'

このプールとプロセッサセットを結合によって対応付けます。
# poolcfg -c 'associate pool pool_batch (pset pset_batch)'

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

# poolcfg -c info
system tester
        string  system.comment kernel state
        int     system.version 1
        boolean system.bind-default true
        int     system.poold.pid 177916

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment 
                pset    pset_default

        pset pset_default
                int     pset.sys_id -1
                boolean pset.default true
                uint    pset.min 1
                uint    pset.max 65536
                string  pset.units population
                uint    pset.load 10
                uint    pset.size 4
                string  pset.comment 
                boolean testnullchanged true

                cpu
                        int     cpu.sys_id 3
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 2
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 1
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 0
                        string  cpu.comment 
                        string  cpu.status on-line

        pool pool_batch
                boolean pool.default false
                boolean pool.active true
                int pool.importance 1
                string pool.comment
                pset pset_batch

        pset 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

                cpu
                        int     cpu.sys_id 5
                        string  cpu.comment
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 4
                        string  cpu.comment
                        string  cpu.status on-line

/etc/pooladm.conf にある構成を確定します。
# pooladm -c

(省略可能) /tmp/backup という静的構成ファイルに動的構成をコピーするには、次のように入力します。
# pooladm -s /tmp/backup

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

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

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割を作成してユーザーに割り当てる方法については、『Solaris のシステム管理 (セキュリティーサービス)』の「RBAC の管理 (作業マップ)」を参照してください。

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

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

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

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

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment 
                pset    pset_default

        pset pset_default
                int     pset.sys_id -1
                boolean pset.default true
                uint    pset.min 1
                uint    pset.max 65536
                string  pset.units population
                uint    pset.load 10
                uint    pset.size 4
                string  pset.comment 
                boolean testnullchanged true

                cpu
                        int     cpu.sys_id 3
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 2
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 1
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 0
                        string  cpu.comment 
                        string  cpu.status on-line

        pool pool_batch
                boolean pool.default false
                boolean pool.active true
                int pool.importance 1
                string pool.comment
                string pool.scheduler FSS
                pset batch

        pset 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

                cpu
                        int     cpu.sys_id 5
                        string  cpu.comment
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 4
                        string  cpu.comment
                        string  cpu.status on-line

/etc/pooladm.conf にある構成を確定します。
# pooladm -c

(省略可能) /tmp/backup という静的構成ファイルに動的構成をコピーするには、次のように入力します。
# pooladm -s /tmp/backup

構成の制約を設定する方法

制約は、構成に加えることのできる変更を一部除外することで、作成可能な構成の範囲に影響を与えます。ここでは、cpu.pinned プロパティーを設定する手続きを示します。

次の例では、cpuid は整数です。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

静的構成または動的構成内の cpu.pinned プロパティーを変更します。
- ブート時の (静的) 構成を変更します。
  # poolcfg -c 'modify cpu <cpuid> (boolean cpu.pinned = true)'
- ブート時の構成を変更せずに、実行中の (動的) 構成を変更します。
  # poolcfg -dc 'modify cpu <cpuid> (boolean cpu.pinned = true)'

構成の目標を定義する方法

poold に対して、修正操作を実行するときに考慮する目標を指定できます。

次の手順では、wt-load 目標を設定して、poold が資源の使用率に合わせて資源を割り当てるようにします。この構成目標を達成しやすくするために、locality 目標は無効にします。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

システム tester を変更して、wt-load 目標を優先するようにします。
# poolcfg -c 'modify system tester (string system.poold.objectives="wt-load")'

デフォルトのプロセッサセットの locality 目標を無効にします。

# poolcfg -c 'modify pset pset_default (string pset.poold.objectives="locality none")'

pset_batch プロセッサセットの locality 目標を無効にします。

# poolcfg -c 'modify pset pset_batch (string pset.poold.objectives="locality none")'

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

# poolcfg -c info
system tester
        string  system.comment
        int     system.version 1
        boolean system.bind-default true
        int     system.poold.pid 177916
        string  system.poold.objectives wt-load

        pool pool_default
                int     pool.sys_id 0
                boolean pool.active true
                boolean pool.default true
                int     pool.importance 1
                string  pool.comment 
                pset    pset_default

        pset pset_default
                int     pset.sys_id -1
                boolean pset.default true
                uint    pset.min 1
                uint    pset.max 65536
                string  pset.units population
                uint    pset.load 10
                uint    pset.size 4
                string  pset.comment 
                boolean testnullchanged true
                string  pset.poold.objectives locality none

                cpu
                        int     cpu.sys_id 3
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 2
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 1
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 0
                        string  cpu.comment 
                        string  cpu.status on-line

        pool pool_batch
                boolean pool.default false
                boolean pool.active true
                int pool.importance 1
                string pool.comment
                string pool.scheduler FSS
                pset batch

        pset 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
                string  pset.poold.objectives locality none

                cpu
                        int     cpu.sys_id 5
                        string  cpu.comment
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 4
                        string  cpu.comment
                        string  cpu.status on-line

/etc/pooladm.conf にある構成を確定します。
# pooladm -c

(省略可能) /tmp/backup という静的構成ファイルに動的構成をコピーするには、次のように入力します。
# pooladm -s /tmp/backup

`poold` のログレベルを設定する方法

poold が生成するログ情報のレベルを指定するには、poold 構成の system.poold.log-level プロパティーを設定します。poold の構成は libpool の構成に保存されています。詳細は、「poold のログ情報」および poolcfg(1m) と libpool(3LIB) のマニュアルページを参照してください。

コマンド行で poold コマンドを使用する方法でも、poold で生成するログ情報のレベルを指定できます。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

poold コマンドに -l オプションとパラメータ (INFO など) を付けて実行することで、ログのレベルを設定します。
# /usr/lib/pool/poold -l INFO
使用可能なパラメータについては、「poold のログ情報」を参照してください。デフォルトのログレベルは NOTICE です。

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

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

コマンドファイルでは、# という文字はコメント記号として機能し、その行の残り部分がコメントと見なされます。

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

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

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割を作成してユーザーに割り当てる方法については、『Solaris のシステム管理 (セキュリティーサービス)』の「RBAC の管理 (作業マップ)」を参照してください。

コマンドを実行します。
# /usr/sbin/poolcfg -f poolcmds.txt

資源の転送

-d オプションを付けた poolcfg に -c オプションの transfer サブコマンド引数を付けて実行すると、カーネルで資源を転送できます。-d オプションは、コマンドにファイルから入力するのではなく、直接カーネル上で実行することを示します。

次の手順では、2 つの CPU をプロセッサセット pset1 からプロセッサセット pset2 にカーネルで移動します。

プロセッサセット間で CPU を移動する方法

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

2 つの CPU を pset1 から pset2 に移動します。

from 文節と to 文節は、どの順序で使用してもかまいません。to 文節と from 文節は、1 つのコマンドにそれぞれ 1 つだけ使用できます。
# poolcfg -dc 'transfer 2 from pset pset1 to pset2'

例 13–3 プロセッサセット間で CPU を移動する別の方法

ある資源タイプの特定の資源の ID を指定して転送する場合は、別の構文が用意されています。たとえば、次のコマンドは、ID が 0 と 2 の 2 つの CPU を pset_large プロセッサセットに割り当てます。

# poolcfg -dc "transfer to pset pset_large (cpu 0; cpu 2)"

問題発生時の解決方法

要求を満たすための十分な資源がない場合や、指定された ID が見つからない場合は、転送は失敗し、エラーメッセージが表示されます。

プール構成の起動と削除

pooladm コマンドを使用すると、特定のプール構成をアクティブにしたり、現在アクティブになっているプール構成を削除したりできます。このコマンドの詳細については、pooladm(1M) のマニュアルページを参照してください。

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

デフォルト構成ファイル /etc/pooladm.conf に保存されている構成を起動するには、pooladm に -c オプション (構成の確定) を付けて実行します。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

/etc/pooladm.conf にある構成を確定します。
# pooladm -c

(省略可能) たとえば /tmp/backup という静的構成ファイルに動的構成をコピーするには、次のように入力します。
# pooladm -s /tmp/backup

構成を確定する前に構成を検証する方法

-n オプションと -c オプションをともに使用すると、検証が実行されるとどうなるかをテストできます。構成が実際に確定されることはありません。

次のコマンドは、/home/admin/newconfig に保存されている構成を検証します。検出されたエラー条件が表示されますが、構成自体は変更されません。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

構成を確定する前に構成を検証します。
# pooladm -n -c /home/admin/newconfig

プール構成を削除する方法

現在アクティブになっている構成を削除して、プロセッサセットなどの関連付けられているすべての資源をデフォルトの状態に戻すには、-x オプション (構成の削除) を使用します。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

現在アクティブになっている構成を削除します。
# pooladm -x
-x オプションを付けて pooladm を実行すると、ユーザーが定義したすべての要素が動的構成から削除されます。すべての資源がデフォルトの状態に戻り、プールとの結合もすべてデフォルトプールとの結合で置換されます。

プロセッサセット内におけるスケジューリングクラスの混在

TS クラスのプロセスと IA クラスのプロセスを同一プロセッサセット内で混在させても問題はありません。1 つのプロセッサセット内でその他のスケジューリングクラスを混在させると、予期できない結果が生じる可能性があります。pooladm -x を使用した結果、1 つのプロセッサセット内にスケジューリングクラスが混在している場合は、priocntl コマンドを使用して、実行中のプロセスを別のスケジューリングクラスに移動してください。「プロセスを TS クラスから FSS クラスに手動で移動する方法」を参照してください。priocntl(1) のマニュアルページも参照してください。

プール属性の設定とプールへの結合

資源プールをプロジェクトに関連付けるために、project.pool 属性を設定できます。

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

poolbind コマンド (poolbind(1M) のマニュアルページを参照) を使用して、特定のプロセスを指定された資源プールに結合します。
project データベース内の project.pool 属性を使用して、新しいログインセッションや newtask コマンドで起動されるタスクを結合するプールを指定します。newtask(1)、projmod(1M)、および project(4) のマニュアルページを参照してください。

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

次の手順では、poolbind コマンドに -p オプションを付けて実行して、プロセス (この例では、現在のシェル) を ohare というプールに手動で結合します。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

プロセスをプールに手動で結合します。
# poolbind -p ohare $$

poolbind に -q オプションを付けて実行することで、プロセスとプールの結合を確認します。
$ poolbind -q $$ 155509 ohare
プロセス ID とプールへの結合が表示されます。

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

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

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

airmiles プロジェクト内のすべてのプロセスを laguardia プールに結合します。
# poolbind -i project -p laguardia airmiles

プロジェクトの `project.pool` 属性を設定する方法

プロジェクトのプロセスを資源プールに結合するために、project.pool 属性を設定できます。

スーパーユーザーになるか、Process Management プロファイルが含まれている役割を引き受けます。

System Administrator 役割には、Process Management プロファイルが含まれています。役割の詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

project データベース内の各エントリに project.pool 属性を追加します。
# projmod -a -K project.pool=poolname project

`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 プールに結合されます。

ユーザー paul は、起動するプロセスのプール結合を変更できます。paul は、newtask を使用して (この場合は passes プロジェクト内で起動することで)、作業を backstage プールに結合することもできます。

passes プロジェクトでプロセスを起動します。
$ newtask -l -p passes

poolbind コマンドに -q オプションを付けて実行し、プロセスとプールの結合を確認します。また、二重ドル記号 ($$) を使用して親シェルのプロセス番号をコマンドに渡します。
$ poolbind -q $$ 6384 pool backstage
プロセス ID とプールへの結合が表示されます。

`poolstat` を使ってプールに関連付けられている資源について統計情報を報告する

poolstat コマンドを使用すると、プールに関連付けられている資源について統計情報を表示できます。詳細は、「poolstat によるプール機能と資源使用率の監視」および poolstat(1M) のマニュアルページを参照してください。

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

`poolstat` のデフォルトの出力を表示する

引数なしで poolstat と入力すると、見出し行に続いて、1 行に 1 つずつプールが表示されます。情報の行には、プール ID、プール名、およびプールに接続されているプロセッサセットに関する資源統計が表示されます。

machine% poolstat
                              pset
       id pool           size used load
        0 pool_default      4  3.6  6.2
        1 pool_sales        4  3.3  8.4

特定の間隔で複数の報告を生成する

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

machine% poolstat 5 3
                               pset
 id pool                 size used load
 46 pool_sales              2  1.2  8.3
  0 pool_default            2  0.4  5.2
                              pset
 id pool                 size used load
 46 pool_sales              2  1.4  8.4
  0 pool_default            2  1.9  2.0
                              pset
 id pool                 size used load
 46 pool_sales              2  1.1  8.0
  0 pool_default            2  0.3  5.0

資源セットの統計情報を報告する

次の例では、poolstat コマンドに -r オプションを付けて実行し、プロセッサセットの資源セットの統計情報を報告します。資源セット pset_default は複数のプールに接続されているので、このプロセッサセットは各プールで 1 回ずつ表示されます。

machine% poolstat -r pset
      id pool          type rid rset          min  max size used load
       0 pool_default  pset  -1 pset_default    1  65K    2  1.2  8.3
       6 pool_sales    pset   1 pset_sales      1  65K    2  1.2  8.3
       2 pool_other    pset  -1 pset_default    1  10K    2  0.4  5.2

第 14 章資源管理の構成例

この章では、資源管理のフレームワークについて考察し、仮想的なサーバー統合プロジェクトについて説明します。

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

統合前の構成

この例では、5 つのアプリケーションを 1 つのシステムに統合します。対象となるアプリケーションは、それぞれ資源要件、ユーザー数、およびアーキテクチャーが異なります。現在、各アプリケーションは、それぞれの要件を満たす専用サーバーに置かれています。次の表にアプリケーションとその特性を示します。

アプリケーション	特性
アプリケーションサーバー	2 CPU を超えるとスケーラビリティーが低くなります
アプリケーションサーバー用のデータベースインスタンス	負荷の高いトランザクション処理
テストおよび開発環境用のアプリケーションサーバー	GUI に基づいたコードテスト
トランザクション処理サーバー	応答時間を保証します
スタンドアロンのデータベースインスタンス	大量のトランザクションを処理し、複数のタイムゾーンに対してサービスを提供します

統合後の構成

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

アプリケーションサーバーは、2 つの CPU から構成されるプロセッサセットを持ちます。
アプリケーションサーバーのデータベースインスタンスとスタンドアロンのデータベースインスタンスは、4 つ以上の CPU から構成される 1 つのプロセッサセットに統合されます。スタンドアロンのデータベースインスタンスはその資源の 75% が保証されます。
テストおよび開発用のアプリケーションサーバーには IA スケジューリングクラスを適用して、UI の応答性を保証します。メモリーを制約して、不正なコードによる影響を低減します。
トランザクション処理サーバーには 2 つ以上の CPU から構成される専用のプロセッサセットを割り当てて、応答時間を短縮します。

この構成の対象には、各資源セットのプロセッササイクルを消費している実行中の既知のアプリケーションすべてが含まれます。したがって、プロセッサ資源を必要としているセットにプロセッサ資源をセット間で転送できるように、次のような制約を設定します。

wt-load 目標を設定して、使用率の高い資源セットに、より多くの資源を割り当てるようにします。
locality 目標を tight に設定して、プロセッサの近傍性が最大になるようにします。

また、どの資源セットについても使用率が 80% を超えないようにする制約も適用します。この制約により、アプリケーションは必要な資源に確実にアクセスできます。さらに、トランザクション処理のプロセッサセットについては、使用率を 80% 以下に保つという目標の重要性を、ほかの目標の 2 倍にします。この重要性は構成で定義します。

構成の作成

/etc/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)keep with previous line
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 dev_pset (uint pset.min = 0; uint pset.max = 2)
create pset tp_pset (uint pset.min = 2; uint pset.max=8)
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 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 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)
modify system tester (string system.poold.objectives="wt-load")
modify pset dev_pset (string pset.poold.objectives="locality tight; utilization < 80")
modify pset tp_pset (string pset.poold.objectives="locality tight; 2: utilization < 80")
modify pset db_pset (string pset.poold.objectives="locality tight;utilization < 80")
modify pset app_pset (string pset.poold.objectives="locality tight; utilization < 80")

pool.host 入力ファイルを使って構成を更新します。

# poolcfg -f pool.host

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

# pooladm -c

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

構成の表示

フレームワークの構成には、システムによって作成されたデフォルトの要素も含まれています。この構成を表示するには、次のように入力します。

# pooladm
system host
        string  system.comment
        int     system.version 1
        boolean system.bind-default true
        int     system.poold.pid 177916
        string  system.poold.objectives wt-load

        pool dev_pool
                int     pool.sys_id 125
                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
                int     pool.sys_id 124
                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
                int     pool.sys_id 123
                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
                int     pool.sys_id 122
                boolean pool.default false
                boolean pool.active true
                int     pool.importance 1
                string  pool.comment
                string  pool.scheduler TS
                pset    tp_pset
 
        pool pool_default
                int     pool.sys_id 0
                boolean pool.default true
                boolean pool.active true
                int     pool.importance 1
                string  pool.comment
                string  pool.scheduler TS
                pset    pset_default

        pset dev_pset
                int     pset.sys_id 4
                string  pset.units population
                boolean pset.default false
                uint    pset.min 0
                uint    pset.max 2
                string  pset.comment
                boolean pset.escapable false
                uint    pset.load 0
                uint    pset.size 0
                string  pset.poold.objectives locality tight; utilization < 80

        pset tp_pset
                int     pset.sys_id 3
                string  pset.units population
                boolean pset.default false
                uint    pset.min 2
                uint    pset.max 8
                string  pset.comment
                boolean pset.escapable false
                uint    pset.load 0
                uint    pset.size 0
                string  pset.poold.objectives locality tight; 2: utilization < 80

                cpu
                        int     cpu.sys_id 1
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 2
                        string  cpu.comment 
                        string  cpu.status on-line

        pset db_pset
                int     pset.sys_id 2
                string  pset.units population
                boolean pset.default false
                uint    pset.min 4
                uint    pset.max 6
                string  pset.comment
                boolean pset.escapable false
                uint    pset.load 0
                uint    pset.size 0
                string  pset.poold.objectives locality tight; utilization < 80

                cpu
                        int     cpu.sys_id 3
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 4
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 5
                        string  cpu.comment 
                        string  cpu.status on-line

                cpu
                        int     cpu.sys_id 6
                        string  cpu.comment 
                        string  cpu.status on-line
        pset app_pset
                int     pset.sys_id 1
                string  pset.units population
                boolean pset.default false
                uint    pset.min 1
                uint    pset.max 2
                string  pset.comment
                boolean pset.escapable false
                uint    pset.load 0
                uint    pset.size 0
                string  pset.poold.objectives locality tight; utilization < 80
                cpu
                        int     cpu.sys_id 7
                        string  cpu.comment 
                        string  cpu.status on-line

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

                cpu
                        int     cpu.sys_id 0
                        string  cpu.comment 
                        string  cpu.status on-line

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

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

注 –

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

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

この章では、Solaris 管理コンソールの資源制御機能と性能監視機能について説明します。このコンソールを使って制御できるのは、資源管理機能の一部だけです。

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

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

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

タスク	説明	説明
Solaris 管理コンソールを使用します	ローカル環境、ネームサービス環境、またはディレクトリサービス環境で Solaris 管理コンソールを起動します。ネームサービス環境では、パフォーマンスツールは使用できません。	『Solaris のシステム管理 (基本編)』の「Solaris 管理コンソールを起動する」および『Solaris のシステム管理 (基本編)』の「ネームサービス環境で Solaris 管理ツールを使用する (作業マップ)」
システムのパフォーマンスの監視	「System Status」の下にあるパフォーマンスツールにアクセスします。	「パフォーマンスツールにアクセスする方法」
プロジェクトに資源制御機能を追加します	「System Configuration」の下にある「資源制御 (Resource Controls)」タブにアクセスします。	「「資源制御 (Resource Controls)」タブへのアクセス方法」

コンソールの概要

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

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

管理範囲

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

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

パフォーマンスツール

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

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

この画面は、左側の「ナビゲーション」区画に性能の場所を、右側の「属性」と「値」区画にシステム性能の概要を表示しています。

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

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

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

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

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

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

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

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

システム単位の監視

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

属性	説明
アクティブプロセス (Active Processes)	システム上でアクティブなプロセス数
物理メモリー使用量 (Physical Memory Used)	使用中のシステムメモリーのサイズ
物理メモリー空き容量 (Physical Memory Free)	使用可能なシステムメモリーのサイズ
スワップ使用量 (Swap Used)	使用中のシステムスワップ領域のサイズ
スワップ空き容量 (Swap Free)	使用可能なシステムスワップ領域のサイズ
ページング頻度 (Page Rate)	システムページングの頻度
システムコール (System Calls)	秒あたりのシステムコール数
ネットワークパケット (Network Packets)	秒あたりに送信されるネットワークのパケット数
CPU 使用率 (CPU Usage)	現在使用中の CPU の比率
平均負荷率 (Load Average)	過去 1 分、5 分、または 15 分の間にシステム実行キューに存在した平均プロセス数

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

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

属性	短い名前	説明
入力ブロック (Input Blocks)	`inblk`	読み取られたブロック数
書き込まれたブロック (Blocks Written)	`oublk`	書き込まれたブロック数
読み取られた/書き込まれた文字数 (Chars Read/Written)	`ioch`	読み取りおよび書き込みが行われた文字数
データページフォルトのスリープ時間 (Data Page Fault Sleep Time)	`dftime`	データページフォルトの処理で経過した時間
強制的なコンテキストスイッチ (Involuntary Context Switches)	`ictx`	コンテキストの強制的な切り替え数
システムモード時間 (System Mode Time)	`stime`	カーネルモードで経過した時間
メジャーページフォルト (Major Page Faults)	`majfl`	メジャーページフォルト数
受信したメッセージ (Messages Received)	`mrcv`	受信されたメッセージ数
送信したメッセージ (Messages Sent)	`msend`	送信されたメッセージ数
マイナーページフォルト (Minor Page Faults)	`minf`	マイナーページフォルト数
プロセス数 (Num Processes)	`nprocs`	ユーザーまたはプロジェクトが所有するプロセス数
LWP 数 (Num LWPs)	`count`	軽量プロセスの数
その他のスリープ時間 (Other Sleep Time)	`slptime`	`tftime`、`dftime`、`kftime`、および `ltime` を除いたスリープ時間
CPU 時間 (CPU Time)	`pctcpu`	プロセス、ユーザー、またはプロジェクトが使用した最新の CPU 時間の比率
使用メモリー (Memory Used)	`pctmem`	プロセス、ユーザー、またはプロジェクトが使用したシステムメモリーの比率
ヒープサイズ (Heap Size)	`brksize`	プロセスのデータセグメントに割り当てられているメモリーサイズ
常駐サイズ (Resident Set Size)	`rsssize`	プロセスによって要求されている現在のメモリーサイズ
プロセスイメージサイズ (Process Image Size)	`size`	プロセスイメージのサイズ (K バイト)
受信したシグナル (Signals Received)	`sigs`	受信されたシグナルの数
停止時間 (Stopped Time)	`stoptime`	停止状態で経過した時間
スワップ操作 (Swap Operations)	`swaps`	進行中のスワップ操作の数
実行されたシステムコール (System Calls Made)	`sysc`	設定された (直前の) 時間間隔で実行されたシステムコール数
システムページフォルトのスリープ時間 (System Page Fault Sleep Time)	`kftime`	ページフォルトの処理で経過した時間
システムトラップ時間 (System Trap Time)	`ttime`	システムトラップの処理で経過した時間
テキストページフォルトのスリープ時間 (Text Page Fault Sleep Time)	`tftime`	テキストページフォルトの処理で経過した時間
ユーザーロック待機のスリープ時間 (User Lock Wait Sleep Time)	`ltime`	ユーザーロックを待機している間に経過した時間
ユーザーモード時間 (User Mode Time)	`utime`	ユーザーモードで経過した時間
ユーザーおよびシステムモード時間 (User and System Mode Time)	`time`	CPU 実行の累積時間
任意コンテキストスイッチ (Voluntary Context Switches)	`vctx`	コンテキストの自主的な切り替え数
待機 CPU 時間 (Wait CPU Time)	`wtime`	CPU を待機している間に経過した時間 (応答時間)

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

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

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

この画面は、「資源制御 (Resource Controls)」タブを示しています。このタブには、資源制御とその値が表示されます。

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

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

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

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

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

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

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

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

設定可能な資源制御

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

数量は制限される量を意味します。
インデックスは最大有効識別子を意味します。

表 15–1 Solaris 管理コンソールで使用できる標準の資源制御


制御名	説明	デフォルトの単位
`project.cpu-shares`	このプロジェクトに対して、公平配分スケジューラ (FSS) で使用することが許可されている CPU 配分 (FSS(7) のマニュアルページを参照)	数量 (配分)
`task.max-cpu-time`	タスクのプロセスで使用できる最長 CPU 時間	時間 (秒)
`task.max-lwps`	タスクのプロセスで同時に使用できる LWP の最大数	数量 (LWP 数)
`process.max-cpu-time`	プロセスで使用できる最長 CPU 時間	時間 (秒)
`process.max-file-descriptor`	プロセスで使用できる最大のファイル記述子インデックス	インデックス (最大ファイル記述子)
`process.max-file-size`	プロセスで書き込むことができるファイルオフセットの最大サイズ	サイズ (バイト)
`process.max-core-size`	プロセスによって作成されるコアファイルの最大サイズ	サイズ (バイト)
`process.max-data-size`	プロセスで使用できるヒープメモリーの最大サイズ	サイズ (バイト)
`process.max-stack-size`	プロセスで使用できるスタックメモリーセグメントの最大サイズ	サイズ (バイト)
`process.max-address-space`	プロセスで使用できる、セグメントサイズの総計としての最大アドレス空間	サイズ (バイト)

値の設定

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

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

注 –

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

コンソールのリファレンス

プロジェクトとタスクについては、第 2 章プロジェクトとタスク (概要)を参照してください。資源制御については、第 6 章資源制御 (概要)を参照してください。公平配分スケジューラ (FSS) については、第 8 章公平配分スケジューラ (概要)を参照してください。

注 –

すべての資源制御をコンソールで設定できるわけではありません。コンソールで設定できる資源制御の一覧については、表 15–1 を参照してください。

パート I 資源管理

第 1 章 Solaris 10 資源管理の紹介

資源管理の概要

資源の分類

資源管理の制御機構

制約機構

スケジューリング機構

区分機構

資源管理構成

Solaris ゾーンとの相互動作

資源管理機能を使用する場合

サーバーを統合する場合

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

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

第 2 章 プロジェクトとタスク (概要)

Solaris 10 におけるプロジェクトデータベースと資源制御コマンドの新機能

プロジェクトとタスクの機能

プロジェクト識別子

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

useradd 、usermod、および passmgmt コマンドによるユーザー属性の設定

project データベース

PAM サブシステム

ネームサービス構成

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

NIS のプロジェクト構成

LDAP のプロジェクト構成

タスク識別子

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

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

第 3 章 プロジェクトとタスクの管理

プロジェクトとタスクの管理 (作業マップ)

コマンドとコマンドオプションの例

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

ps コマンド

id コマンド

pgrep コマンドと pkill コマンド

prstat コマンド

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

cron コマンド

su コマンド

プロジェクトの管理

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

参照

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

/etc/project ファイルの内容を検証する方法

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

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

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

プロジェクト属性の編集と検証

属性と属性値をプロジェクトに追加する方法

属性値をプロジェクトから削除する方法

資源制御属性をプロジェクトから削除する方法

プロジェクトの属性と属性値を置換する方法

資源制御属性の既存の値を削除する方法

第 4 章 拡張アカウンティング (概要)

Solaris 10 における拡張アカウンティングの新機能

拡張アカウンティングの紹介

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

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

拡張可能な形式

exacct レコードとその形式

ゾーンがインストールされている Solaris システムでの拡張アカウンティングの使用

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

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

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

第 5 章 拡張アカウンティングの管理 (手順)

拡張アカウンティング機能の管理 (作業マップ)

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

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

参照

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

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

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

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

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

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

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

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

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

第 6 章 資源制御 (概要)

第 2 章プロジェクトとタスク (概要)

`useradd` 、`usermod`、および `passmgmt` コマンドによるユーザー属性の設定

`project` データベース

ローカルの `/etc/project` ファイルの形式

第 3 章プロジェクトとタスクの管理

`ps` コマンド

`id` コマンド

`pgrep` コマンドと `pkill` コマンド

`prstat` コマンド

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

`cron` コマンド

`su` コマンド

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

`/etc/project` ファイルの内容を検証する方法

第 4 章拡張アカウンティング (概要)

`exacct` レコードとその形式

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

第 5 章拡張アカウンティングの管理 (手順)

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

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

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

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

第 6 章資源制御 (概要)

第 7 章資源制御の管理 (手順)

`prctl` コマンドの使用

`prctl` コマンドを使ってデフォルトの資源制御値を表示する方法

`prctl` コマンドを使って特定の資源制御の情報を表示する方法

`prctl` を使って値を一時的に変更する方法

`prctl` を使って資源制御値を下げる方法

`prctl` を使ってプロジェクトの制御値を表示、置換、確認する方法

`rctladm` の使用

`rctladm` を使用する方法

`ipcs` の使用

`ipcs` を使用する方法

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

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

第 9 章公平配分スケジューラの管理 (手順)