資源管理機能を利用すると、アプリケーションが利用可能なシステム資源をどのように使用するかを制御できます。次のような制御が可能になります。
プロセッサ時間などのコンピュータ資源を割り当てる
割り当てた資源の使用状況を監視し、必要に応じて調整する
分析、課金、および容量計画のために拡張アカウンティング情報を生成する
今日のコンピューティング環境では、システム上で実行されるアプリケーションによって生成されるさまざまな作業負荷に柔軟に対応できる能力が求められます。資源管理機能を使用しない場合、Solaris オペレーティング環境は、新しいアプリケーションの要求に動的に適応することによって作業負荷の要求に対応しています。このデフォルトの動作は、通常、システムのすべてのアクティビティに対して資源へのアクセスを同等に与えることを意味します。Solaris の資源管理機能を使用すると、作業負荷を個別に扱うことができるようになります。次のような制御が可能になります。
特定の資源へのアクセスを制限する
優先順位に基づいて作業負荷に資源を提供する
作業負荷を互いに分離する
作業負荷が相互に影響し合うことによるパフォーマンスの低下を最小限に抑える機能と、資源の使用状況や使用率を監視する機能を総称して「資源管理機能」といいます。資源管理機能は、いくつかのアルゴリズムの集合として実装されます。これらのアルゴリズムは、アプリケーションがその実行過程で発行する一連の資源要求を処理します。
資源管理機能を使用すると、さまざまな作業負荷に対してオペレーティングシステムのデフォルトの動作を変更できます。この場合の「動作」とは、主に、アプリケーションが 1 つ以上の資源要求をシステムに発行したときに、オペレーティングシステムのアルゴリズムが行う一連の決定処理のことです。 資源管理機能は、次の目的で使用できます。
あるアプリケーションに対して、資源の割り当てを拒否したり、他のアプリケーションに許可されているよりも大きい割り当てを与えたりする
特定の割り当てを個別にではなく一括して行う
次のような目的を達成したいときは、資源管理機能を使用できるようにシステムを構成します。次のような制御が可能になります。
アプリケーションが際限なく資源を浪費するのを防止する
外部イベントに基づいてアプリケーションの優先順位を変更する
一連のアプリケーションに資源の使用を保証する一方で、システムの使用率を最大限に高める
資源管理機能をシステム構成に組み込むときは、次のような作業が事前に必要です。
システム上で競合する作業負荷を特定する
競合しない作業負荷と、主要な作業負荷に影響を与えるようなパフォーマンス要件を伴った作業負荷を区別する
競合しない作業負荷と競合する作業負荷を特定したら、システムの能力が許す範囲内で、業務サービスへの影響を最小限に抑えた資源構成を構築できます。
効率のよい資源管理を実現するために、Solaris 環境には制御メカニズム、通知メカニズム、および監視メカニズムが用意されています。制御メカニズムについては、資源管理の制御メカニズムで説明します。通知および監視メカニズムについては、第 8 章「資源制御」で説明します。これらの機能の多くは、proc(4) ファイルシステム、プロセッサセット、スケジューリングクラスなどの既存メカニズムの拡張機能として提供されます。その他の機能は資源管理に固有です。これらの機能については、以降の章で説明します。
資源は、アプリケーションの動作を変更する目的で操作されるコンピューティングシステムのあらゆる側面を意味します。つまり、資源は、アプリケーションが暗黙的または明示的に要求する機能です。この機能が拒否または制限された場合は、堅固に作成されているアプリケーションの実行速度が低下します。
資源の分類は、資源の識別とは対照的に、多くの基準に基づいて行うことができます。たとえば、資源は、暗黙的な要求か明示的な要求か、時間ベース (CPU 時間など) の要求か時間に無関係な要求 (割り当てられた CPU シェアなど) か、などを基準に行うことができます。
通常、スケジューラベースの資源管理は、アプリケーションが暗黙的に要求する資源に適用されます。たとえば、実行を継続するときは、アプリケーションは暗黙的に追加の CPU 時間を要求します。ネットワークソケットにデータを書き込むときは、アプリケーションは暗黙的に帯域幅を要求します。暗黙的に要求される資源の総使用量に対して制約を設けることができます。
帯域幅または CPU サービスのレベルを明示的に折衝できるように、インタフェースを追加することもできます。追加スレッドの要求のように明示的に要求される資源は、制約によって管理できます。
Solaris オペレーティング環境では、制約、スケジューリング、パーティション分割の 3 種類の制御メカニズムを使用できます。
制約を使用すると、管理者やアプリケーション開発者は、作業負荷が使用する特定の資源の消費にいくつかの制限を設定できます。制限を設定すると、資源の消費シナリオを簡単にモデル化できます。また、制限を設定することにより、無秩序に資源を要求してシステムのパフォーマンスや可用性に悪影響を及ぼす可能性がある悪質なアプリケーションを制御できます。
制約は、アプリケーションに制限を課します。アプリケーションとシステムの関係は、アプリケーションが動作できないところまで悪化してしまう可能性があります。そのような事態を回避する方法の 1 つは、資源に関する動作が不明なアプリケーションに対する制約を徐々に強めていくことです。第 8 章「資源制御」で説明する資源制御機能は、制約メカニズムを提供します。新たに作成するアプリケーションであれば、資源の制約をアプリケーションが認識するようにすることもできます。ただし、すべての開発者がこの機能を使用するとは限りません。
スケジューリングとは、一定の間隔で割り当てを決定することです。この決定は、予測可能なアルゴリズムに基づいて行われます。現在割り当てられている必要としないアプリケーションは、他のアプリケーションが使用できるように、その資源を解放します。スケジューリングに基づいて資源管理を行うと、資源に余裕がある構成の場合は使用率を最大限にできると同時に、資源が限界まで、あるいは過剰に使用されている場合には、割り当てを制御できます。スケジューリングのアルゴリズムにより、「制御」という用語の意味が決まります。場合によっては、スケジューリングアルゴリズムは、すべてのアプリケーションが資源にある程度アクセスできることを保証します。第 9 章「フェアシェアスケジューラ」で説明するフェアシェアスケジューラ (FSS) は、アプリケーションが制御された方法で CPU 資源にアクセスするように管理します。
パーティション分割は、作業負荷をシステム上で使用可能な資源のサブセットに結合 (バインド) するために使用されます。資源と結合することにより、作業負荷は常に一定量の資源を使用できることが保証されます。第 10 章「資源プール」で説明する資源プール機能は、マシンの特定のサブセットに結合する作業負荷を制限します。パーティション分割を使用する構成では、システム全体が過剰使用されるのを防ぐことができます。ただし、この方法では、高い使用率の達成は難しくなります。予約済みの資源 (プロセッサなど) に結合されている作業負荷がアイドル状態になっている場合でも、別の作業負荷がその資源を使用することはできないためです。
資源管理構成の一部をネットワークのネームサービスに置くことができます。この機能により、管理者は、資源管理制約をマシンごとに排他的に適用するのではなく、複数のマシンに対して一括して適用できます。関連する作業は共通識別子を共有でき、その作業の使用状況はアカウンティングデータに基づいて表形式で表すことができます。
資源管理構成と作業負荷識別子の詳細については、第 6 章「プロジェクトとタスク」を参照してください。これらの識別子をアプリケーションの資源使用状況と結び付ける拡張アカウンティング機能については、第 7 章「拡張アカウンティング」を参照してください。
資源管理機能を使用して、アプリケーションが必要な応答時間を確保できるようにします。
また、資源管理機能により、資源の使用率を向上することができます。使用状況を分類して優先付けすることにより、オフピーク時に余った資源を効率よく使用でき、処理能力を追加する必要がなくなります。また、負荷の変動が原因で資源を無駄にすることもなくなります。
資源管理機能は、多くのアプリケーションを 1 台のサーバー上で統合できる環境で使用すると最も高い効果を発揮します。
多数のマシンの管理は複雑でコストがかかるため、より大規模で拡張性の高いサーバーにアプリケーションを統合することが望まれます。個々の作業負荷を別々のシステムで実行して、そのシステムの資源へのフルアクセスを与える代わりに、資源管理ソフトウェアを使用すれば、システム内の作業負荷を分離できます。資源管理機能を使用すると、1 つの Solaris システムで複数の異なるアプリケーションを実行して制御することにより、システムの総保有コスト (TCO) を低減することができます。
インターネットサービスやアプリケーションサービスを提供する場合は、資源管理を使用すると、次のことが可能になります。
1 台のマシンに複数の Web サーバーを配置する。各 Web サイトの資源消費を制御し、各サイトを他のサイトで起こる可能性のある過剰使用から保護する
欠陥のある CGI (Common Gateway Interface) スクリプトが CPU 資源を浪費するのを防止する
不正な動作をするアプリケーションによって引き起こされる、仮想メモリーのリークを防止する
顧客のアプリケーションが、同じサイトで実行されている別の顧客のアプリケーションの影響を受けないようにする
同一マシン上で異なるレベルまたはクラスのサービスを提供する
課金目的でアカウンティング情報を取得する
資源管理機能は、特に、教育機関のように大規模で多様なユーザーが利用するシステムでその効果を発揮します。さまざまな作業負荷が混在している場合は、特定のプロジェクトに高い優先順位を与えるようにソフトウェアを構成できます。
たとえば、大きな証券会社のトレーダは、データベースのクエリーや計算を実行するために、一時的に高速なアクセスが必要になる場合があります。一方、他のユーザーの作業負荷は、一定しています。トレーダのプロジェクトに、作業量に応じてより高い処理能力を割り当てれば、トレーダは必要とする応答性を確保できます。
また、資源管理機能は、シン (thin) クライアントシステムをサポートするのにも適しています。これらのプラットフォームは、スマートカードのようなフレームバッファーと入力デバイスを持つステートレスなコンソールを備えています。実際の処理は共有サーバー上で行われるため、タイムシェアリング型の環境とみなすことができます。資源管理機能を使ってサーバー上のユーザーを分離してください。こうすることで、過剰な負荷を引き起こしたユーザーがハードウェア資源を占有し、システムを使用する他のユーザーに重大な影響を与えることがなくなります。
次の作業マップに、システム上で資源管理機能を設定する際に必要となる作業の概要を示します。
作業 |
説明 |
参照先 |
---|---|---|
システム上の作業負荷を特定する |
/etc/project データベースファイル、または NIS マップか LDAP ディレクトリサービスでプロジェクトエントリを確認する | |
システム上の作業負荷に優先順位を付ける |
どのアプリケーションが重要かを判定する。重要な作業負荷には資源への優先的なアクセスが必要になる場合がある |
サービスの目的を考慮する |
システム上で実際のアクティビティを監視する |
パフォーマンスツールを使用して、システムで実行されている作業負荷の現在の資源消費量を表示する。その上で、特定の資源へのアクセスを制限する必要があるかどうか、あるいは作業負荷を互いに分離する必要があるかどうかを判定できる |
システム単位の監視、cpustat(1M)、iostat(1M)、mpstat(1M)、prstat(1M)、sar(1)、および vmstat(1M) |
システムで実行されている作業負荷を一時的に変更する |
変更可能な設定値を決めるには、Solaris 環境で使用できる資源制御を参照する。タスクまたはプロセスが実行している間は、コマンド行から値を更新できる |
使用可能な資源制御、資源制御値に対応付けられたアクション、動作中のシステム上の資源制御値を一時的に更新する、rctladm(1M)、および prctl(1) |
project データベースまたはネームサービスプロジェクトテーブル内のプロジェクトエントリごとに資源制御属性を設定する |
/etc/project データベースまたはネームサービスプロジェクトテーブル内の各プロジェクトエントリには、資源制御を 1 つ以上含めることができる。これらの資源制御は、そのプロジェクトに属するタスクとプロセスを制約する。資源制御で指定する各しきい値に対しては、その値に達したときに行われるアクションを 1 つ以上対応付けることができる。 資源制御は、コマンド行インタフェースまたは Solaris 管理コンソールを使って設定できる。多数のシステムの構成パラメータを設定するときは、Solaris 管理コンソールを使用する |
project データベース、ローカルの project ファイルの形式、使用可能な資源制御、資源制御値に対応付けられたアクション、および 第 9 章「フェアシェアスケジューラ」 |
資源プール構成を作成する |
資源プールは、プロセッサなどのシステム資源をパーティション分割する手段を提供し、再起動時にもそのパーティションを保持する。/etc/project データベースの各エントリに project.pool 属性を追加できる | |
フェアシェアスケジューラ (FSS) をデフォルトのシステムスケジューラとして設定する |
単一の CPU システムまたはプロセッサセット内のすべてのユーザープロセスが同じスケジューリングクラスに属すようにする |
FSS の構成例および dispadmin(1M) |
拡張アカウンティング機能を起動し、タスクまたはプロセスベースで資源消費を監視して記録する |
拡張アカウンティングデータを使って現在の資源制御を評価し、将来の作業負荷のための容量要件を計画する。システム全体の総使用状況を追跡できる。複数のシステムに渡って相互に関連しあう作業負荷について完全な使用統計を取得するために、プロジェクト名は複数のマシンで共有できる |
プロセス、タスク、およびフローの拡張アカウンティングを起動する方法および acctadm(1M) |
(省略可能) 構成をさらに調整する必要があると判断した場合、タスクまたはプロセスが実行している間は、引き続きコマンド行から値を変更できる |
既存のタスクに対しては、プロジェクトを再起動しなくても、変更を一時的に適用できる。満足のいくパフォーマンスが得られるまで値を調整する。次に、/etc/project データベースまたはネームサービスプロジェクトテーブルで現在の値を更新する |
動作中のシステム上の資源制御値を一時的に更新する、rctladm(1M)、および prctl(1) |
(省略可能) 拡張アカウンティングデータを取得する |
アクティブなプロセスおよびタスクの拡張アカウンティングレコードを書き込む。作成されるファイルは、計画、チャージバック、および課金のために使用できる |
wracct(1M) |