test

Solaris Resource Manager 1.1 のシステム管理

性能上の問題

root l ノードに接続されたプロセス

システム管理のために、root l ノードに接続されるプロセスには、要求するほとんどすべての CPU 資源が与えられます。したがって、root l ノードに CPU 使用量の多いプロセスを接続すると、このプロセスによって CPU が占有されるため、他の l ノードのプロセスが遅くなるか停止します。

これを避けるために、次の予防措置をとることができます。

setuid-root として動作するプログラムは、root l ノードに自動的に接続しません。通常、プロセスは、それを作成した親の l ノードに接続されたままで、実効ユーザー ID だけが変更されます。

CPU 資源が Solaris Resource Manager によって制御されない

Solaris Resource Manager は、SHR スケジューリングクラスのプロセスによる CPU の使用だけを制御します。他のスケジューリングクラス、特にリアルタイム (RT) とシステム (SYS) から高い優先順位で過度の要求があると、SHR は残りの CPU 資源でプロセスのスケジューリングを行います。

RT クラスの使用は、Solaris Resource Manager のシステムを制御する能力と対立するものです。リアルタイムプロセスはシステムをいつでも使用できるので、応答をリアルタイムに (通常、数百マイクロ秒で) 返すことができます。定義によって SHR クラスで動作するプロセスは、リアルタイムで動作するどれよりも低い優先順位を与えられます。Solaris Resource Manager は、RT プロセスを制御できません。したがって、使用可能なすべての資源をリアルタイムプロセスが使用したために、Solaris Resource Manager が他のプロセスに割り当てる資源がなくなることもあります。

SYS クラスだけで動作する重要なシステムに NFS サーバーがあります。NFS デーモンは SYS クラスで動作するため、Solaris Resource Manager はこれを制御できません。NFS サービスがよく使われるシステムでは、Solaris Resource Manager がプロセッサ資源を割り当てる余地は少なくなります。

プロセスがシステムコールの中でカーネルコードを実行している間は、通常のタイムスライス横取り規則は適用されません。ほとんどのシステムコールは、横取り点に達するほどの作業量をしません。しかし、システムがそれより強力なシステムコールによる高い負荷のもとにあると、全体的な応答性が低下することがあります。これはスケジューリングクラスによる制御の範囲外です。

システムの実メモリーが十分でないと、ページフォルト率が増加し、プロセススワップが増加するため入出力のボトルネックが生じ、カーネルがより多くの CPU を使用します。入出力待ちの時間が多くなることは、CPU の処理能力が失われていることを示します。これもまたスケジューリングクラスによる制御の範囲外です。

SHR スケジューリングクラスはタイムシェアリング (TS) スケジュールです。このクラスは、TS や対話式 (IA) スケジューラと同じ大域優先順位範囲を使用します。すべてのプロセスを SHR クラスに移行したり、そこから他のクラスへ移行する期間を除き、SHR と TS、IA を混在して使用するのは適切ではありません。SHR クラスと TS クラスのプロセスが混在した状態でシステムを操作すると、両方のクラスでスケジューリングの質が低下します。そのため、Solaris Resource Manager は、root 以外のプロセスが自らのプロセスや他のプロセスを TS や IA クラスに移すのを防止します。RT クラスは別の優先順位範囲を使用します。RT クラスは TS や IA クラスとともに使用できますが、SHR クラスとも一緒に使用できます。

root が実行するプロセスに、setpriority(3C) ライブラリルーチンの代わりに priocntl(2) システムコールを直接使って優先順位を調整するコードが入っている場合には、それらのプロセスがターゲットプロセスを別のスケジューリングクラス (通常は TS) に移動することがあります。setpriority ライブラリルーチンコードは、SHR への priocnt1 インタフェースが TS のインタフェースとバイナリ互換であるという事実を考慮に入れるため、問題が避けられます。ps(1) の -c オプションか priocntl(1) の -d オプションを使用すれば、プロセスのスケジューリングクラスを表示できます。

root 特権を持つプロセスが priocntl(2) を明示的に使ってプロセスのスケジューリングクラスのメンバーを管理する場合にも、同じ問題が生じます。