この章では、次の機能について説明します。
資源プール。マシン資源の区分に使用されます
動的資源プール (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) の構成やスケジューリングクラスの割り当て (任意) に対して一貫した構成機構を提供します。
プールは、システムで使用可能なさまざまな資源セットを結合した特定のものと考えることができます。資源のさまざまな組み合わせを表す各種のプールを作成できます。
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 システムデーモンで使用するコマンドについては、次のマニュアルページを参照してください。
次の要素は、動的構成も含め、すべての資源プール構成に使用できます。
システムの全体的な動作に影響を与えるプロパティー
資源プールの定義
プロセッサセットの定義
プロセッサの定義
これらの要素に含まれているプロパティーを操作することで、資源プールフレームワークの状態と動作を変更できます。たとえば、プールプロパティー 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 資源コントローラは、動的資源プール機能とともに起動されます。
/etc/project ファイル内のプロジェクトエントリに project.pool 属性を追加すると、そのエントリに単一のプールを関連付けることができます。プロジェクトで開始される新しい作業は、適切なプールに結合されます。詳細は、第 2 章プロジェクトとタスク (概要)を参照してください。
たとえば、projmod コマンドを使用して、/etc/project ファイル内のプロジェクト sales に project.pool 属性を設定できます。
# projmod -a -K project.pool=mypool sales |
動的再構成 (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 では決定の履歴が保持され、確認に使用されます。決定履歴を使用すると、それまでに行なった再構成のうち、改善効果を示さなかったものを削除できます。
作業負荷の目標が変更された場合や、システムで使用可能な資源が変更された場合は、再構成が非同期に実行されることもあることに注意してください。
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) のマニュアルページと 「プールのプロパティー」を参照してください。
これら 2 つのプロパティーは、プロセッサセットに割り当てることのできるプロセッサの最小数と最大数を制限します。これらのプロパティーの詳細については、表 12–1 を参照してください。
同じ Solaris インスタンスの資源パーティションどうしであれば、これらの制約の範囲内で、あるパーティションから別のパーティションに資源を割り当てることができます。資源セットに関連付けられているプールに結合することで、資源にアクセスできるようになります。この結合はログイン時に実行されるか、または、PRIV_SYS_RES_CONFIG 特権を持っている管理者が手動で行います。
cpu-pinned プロパティーは、DRP で特定の CPU を現在のプロセッサセットから移動してはならないことを示します。この libpool プロパティーを設定すると、プロセッサセット内で実行されている特定のアプリケーションでのキャッシュ使用率を最大限に高めることができます。
このプロパティーの詳細については、表 12–1 を参照してください。
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 は「重み付けされた負荷 (weighted load)」を意味します。
最小値と最大値のプロパティーを使って満足のいく制約を設定したあとで、これらの制約の範囲内でデーモンが自由に資源を操作できるようにする場合に、この目標を使用してください。
locality 目標は、近傍性グループ (lgroup) データによって測定される近傍性が、選択された構成に対して与える影響を変化させます。近傍性は応答時間と定義することもできます。lgroup は、CPU 資源とメモリー資源を表します。lgroup は、Solaris システムで資源どうしの距離を調べるために使用されます。測定単位は時間です。近傍性グループによる抽象化の詳細については、『プログラミングインタフェース』の「近傍性グループの概要」を参照してください。
この目標には、次の 3 つの値のいずれかを指定できます。
この値を設定すると、資源の近傍性を最大にするような構成が有利に導かれます。
この値を設定すると、資源の近傍性を最小にするような構成が有利に導かれます。
この値を設定すると、どのような構成が有利になるかは、資源の近傍性に依存しません。これは locality 目標のデフォルト値です。
一般に、locality 目標は tight に設定することをお勧めします。ただし、メモリー帯域幅を最大にする場合や、資源セットに対する DR 操作の影響を最小にする場合は、この目標を loose に設定するか、デフォルト値の none にしておいてください。
utilization 目標では、指定された使用率目標を満たしていないパーティションに資源を割り当てるような構成が有利に導かれます。
この目標は、演算子と値で指定されます。演算子は次のとおりです。
「小なり」演算子は、指定された値が最大のターゲット値であることを示します。
「大なり」演算子は、指定された値が最小のターゲット値であることを示します。
「ほぼ等しい」演算子は、指定された値がターゲット値であり、いくらかの変動が許容されることを示します。
pset には、演算子の種類ごとに使用率目標を 1 つ設定できます。
~ 演算子を設定した場合、< 演算子や > 演算子は設定できません。
< 演算子や > 演算子を設定した場合、~ 演算子は設定できません。< 演算子の設定と > 演算子の設定が互いに矛盾してはならないことに注意してください。
< 演算子と > 演算子の両方を使用すると、範囲を指定できます。これらの値は、重複しないように検証されます。
次の例では、pset に対する次のような目標が poold によって評価されます。
utilization を 30% から 80% の範囲に保つ必要がある。
プロセッサセットの locality を最大にする必要がある。
各目標の重要性はデフォルト値の 1 とする。
pset.poold.objectives "utilization > 30; utilization < 80; locality tight"
その他の使用例については、「構成の目標を定義する方法」を参照してください。
プロパティーには 4 つのカテゴリがあります。
構成
制約
目標
目標パラメータ
プロパティー名 |
種類 |
カテゴリ |
説明 |
---|---|---|---|
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 を起動する方法でも、ログレベルを制御できます。
プロパティー名 system.poold.monitor-interval を使用して、値をミリ秒単位で指定します。
ログを通じて 3 つのカテゴリの情報が提供されます。これらのカテゴリは、ログで次のように識別されています。
構成
監視
最適化
プロパティー名 system.poold.log-level を使用して、ログパラメータを指定します。このプロパティーが指定されていない場合、ログレベルのデフォルト値は NOTICE です。パラメータのレベルは階層的になっています。ログレベルとして DEBUG を設定すると、poold は、すべての定義済みメッセージをログに記録します。INFO レベルでは、ほとんどの管理者にとって適度な情報が得られます。
コマンド行で poold コマンドに -l オプションとパラメータを付けて実行すると、生成するログ情報のレベルを指定できます。
次のパラメータを使用できます。
ALERT
CRIT
ERR
WARNING
NOTICE
INFO
DEBUG
これらのパラメータレベルは、syslog に使用される同様のレベルと直接対応づけられます。syslog の使用方法の詳細については、「ログの場所」を参照してください。
poold のログ機能を構成する方法の詳細については、「poold のログレベルを設定する方法」を参照してください。
生成されるメッセージの種類は次のとおりです。
libpool 構成へのアクセスに関連する問題など、libpool 機能の基本的な予期せぬ障害。これによってデーモンは終了します。今すぐ管理者が対応する必要があります。
予期せぬ障害に起因する問題。これによってデーモンは終了します。今すぐ管理者が対応する必要があります。
処理を制御するユーザー指定のパラメータに関連する問題。資源セットの使用率目標が衝突していて、解決不能な場合などです。管理者が介入して目標を修正する必要があります。poold は、衝突している目標を無視することで、改善操作を試みます。ただし、エラーによっては、デーモンが終了することもあります。
構成パラメータの設定に関連する警告。構成パラメータの設定が技術的には正しくても、特定の実行環境には適さない場合などです。たとえば、すべての CPU 資源を固定にすると、poold はプロセッサセット間で CPU 資源を移動することができなくなります。
構成処理をデバッグするときに必要となる詳細情報が含まれたメッセージ。通常は、管理者がこの情報を使用することはありません。
生成されるメッセージの種類は次のとおりです。
予期せぬ監視障害に起因する問題。これによってデーモンは終了します。今すぐ管理者が対応する必要があります。
予期せぬ監視エラーに起因する問題。管理者が介入して修正する必要がある場合もあります。
資源制御の領域移行に関するメッセージ。
資源使用率の統計情報に関するメッセージ。
監視処理をデバッグするときに必要となる詳細情報が含まれたメッセージ。通常は、管理者がこの情報を使用することはありません。
生成されるメッセージの種類は次のとおりです。
これらのメッセージは、最適な決定を行う際の問題に関連して表示されることがあります。たとえば、最小値と最大値または固定構成要素の数によって、厳しすぎる制約を資源セットに与えている場合などです。
これらのメッセージは、最適な再割り当てを行う際の、予期せぬ制限に起因する問題について表示されることがあります。たとえば、資源を消費するプロセスがバインドされているプロセッサセットから最後のプロセッサを削除する場合などです。
これらのメッセージは、使用可能な構成や、決定履歴の上書きに起因して実装されない構成について表示されることがあります。
これらのメッセージは、考慮される代替構成について表示されることがあります。
最適化処理をデバッグするときに必要となる詳細情報が含まれたメッセージ。通常は、管理者がこの情報を使用することはありません。
system.poold.log-location プロパティーを使用して、poold のログの出力先を指定します。poold の出力先として SYSLOG の場所を指定できます (syslog(3C) のマニュアルページを参照)。
このプロパティーが指定されていない場合、poold ログのデフォルトの出力先は /var/log/pool/poold です。
コマンド行から poold を呼び出す場合、このプロパティーは使用しません。ログエントリは、呼び出しを行なった端末の stderr に出力されます。
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(1M) のマニュアルページを参照してください。poolstat の作業と使用方法については、「poolstat を使ってプールに関連付けられている資源について統計情報を報告する」を参照してください。
デフォルトの出力形式では、poolstat は、見出し行を出力したあと、プールごとに 1 行ずつ表示されます。各プールの行は、プール ID とプール名で始まります。それに続く列は、プールに接続されているプロセッサセットに関する統計データです。複数のプールに接続されている資源セットは、各プールで 1 回ずつ表示されるので、複数回表示されます。
列見出しは次のとおりです。
プール ID。
プール名。
資源セット ID。
資源セット名。
資源セットの種類。
資源セットの最小サイズ。
資源セットの最大サイズ。
資源セットの現在のサイズ。
資源セットのうちで現在使用されている部分のサイズ。
この値は、資源セットの使用率に資源セットのサイズを乗算して計算されます。前回のサンプリング間隔で資源セットが再構成されている場合、この値は報告されないことがあります。報告されなかった値はハイフン (-) で示されます。
資源セットに加えられている負荷の絶対値。
このプロパティーの詳細については、libpool(3LIB) のマニュアルページを参照してください。
poolstat の出力では、次のことを指定できます。
列の順序
表示する見出し
poolstat で実行する操作をカスタマイズできます。報告用のサンプリング間隔、および統計を繰り返す回数を設定できます。
poolstat が実行する定期的な処理の間隔を調整します。すべての間隔は秒単位で指定します。
統計を繰り返す回数を指定します。デフォルトでは、poolstat は 1 回だけ統計情報を報告します。
interval と count を指定しなかった場合、統計は 1 回だけ報告されます。interval を指定し、count を指定しなかった場合、統計報告が無限に繰り返されます。
次の表に示すコマンドは、プール機能を管理するための主要なインタフェースとなります。ゾーンが有効になっているシステムでこれらのコマンドを使用する方法については、「ゾーンで使用される資源プール」を参照してください。
マニュアルページ |
説明 |
---|---|
システムのプール機能を有効または無効にします。特定の構成をアクティブにします。または、現在の構成を削除して、関連付けられている資源をデフォルトの状態に戻します。オプションを指定しないで実行すると、pooladm は、現在の動的プール構成を表示します。 |
|
プロジェクト、タスク、およびプロセスを手動で資源プールに結合できます。 |
|
プールやセットに対する構成操作を実行します。このツールを使って作成された構成は、pooladm によってターゲットホスト上でインスタンス化されます。 poolcfg に -c オプションと info サブコマンド引数を付けて実行すると、/etc/pooladm.conf に保存されている静的構成の情報が表示されます。このコマンドにファイル名の引数を追加すると、そのファイルに保存されている静的構成の情報が表示されます。たとえば、poolcfg -c info /tmp/newconfig では、/tmp/newconfig というファイルに保存されている静的構成の情報が表示されます。 |
|
プールシステムデーモン。このデーモンは、システムターゲットと観察可能な統計情報を使用して、管理者によって指定されたシステム性能の目標を維持します。目標が満たされていないときに修正操作を実行できない場合、poold は状況をログに記録します。 |
|
プールに関連付けられている資源について統計情報を表示します。システム管理者にとって性能解析が簡単になり、資源を区分または再区分する作業に役立つ情報が得られます。特定のプールを調べたり、資源セット固有の統計情報を報告したりするためのオプションも用意されています。 |
ライブラリの API は、libpool で提供されます (libpool(3LIB) のマニュアルページを参照)。プログラムからプール構成を操作するには、このライブラリを使用します。