この例では、次のコマンドを使用します。
l ノードに接続されているすべての動作中のプロセスを強制終了する
財務部門がデータベースシステムを所有しているが、技術部門のユーザー (Joe) が計算バッチジョブを実行する必要があり、財務部門のシステムが空いている時間にこのマシンを使用したいと思っています。財務部門は、システムの主要なジョブを妨げない限り、Joe の仕事を実行してもよいことにし、Joe の仕事がデータベースよりも重要ではないと判断しました。このポリシーを設定するには、新しいグループ (batch) を l ノード database に追加し、Joe をサーバーの l ノード階層の新しい batch グループに追加します。
# limadm set cpu.shares=20 databases # limadm set cpu.shares=1 batch # limadm set cpu.shares=1 joe # limadm set sgroup=batch joe |
このコマンドシーケンスによって与えられる割当数が変更され、databases グループが 20 の割当数、batch グループが 1 つの割当数を持ちます。つまり、batch グループのメンバー (Joe のみ) は、databases グループが動作中なら、最大でマシンの 1/21 を使用します。databases グループは、20/21 または 95.2% を受け取ります。データベース作業の処理には 60% + 20% = 80% があれば十分であると以前判断しましたが、この値はそれ以上です。databases が割り当てをすべて要求しなければ、Joe が自分の 4.8% よりも多い割り当てを得ます。databases が動作中でなければ、Joe の割り当てが 100% になることもあります。databases に割り当てられている割当数を 1 から 20 に増やす場合、db1 と db2 の割当数を変更する必要はありません。databases グループ内には、まだ 4 つの割当数が 3:1 の割合であります。スケジューリングツリーのそれぞれのレベルは完全に独立しています。重要なのは、ピアのグループ間の割当数の割合です。
このような保証をしたにもかかわらず、財務部門は、Joe が使用量の多い昼の時間にログインできないようにすることを望んでいます。そのためには、batch グループに対し何らかのログイン制御を行う必要があります。この制御は時刻に関係するので、特定の時間に batch グループのログインを許可するだけのスクリプトを実行します。 たとえば、この制御を行うには、次のような crontab エントリを使用します。
0 6 * * * /usr/srm/bin/limadm set flag.nologin=set batch 0 18 * * * /usr/srm/bin/limadm set flag.nologin=clear batch |
午前 6:00 では、batch はログインする許可を与えられていませんが、18:00 時 (午後 6 時) になると、この制限は解除されます。
さらに厳しいポリシーを導入する場合は、crontab エントリに次の行を追加します。
01 6 * * * /usr/srm/bin/srmkill joe |
この場合、午前 6:01 に l ノード Joe に接続されているプロセスがあれば、srmkill(1MSRM) コマンドを使って終了させます。ジョブに必要な資源が Solaris Resource Manager が制御する資源だけであれば、これは必要ありません。このアクションは、通常の仕事を妨げるそれ以外の資源が Joe の作業で使用されるような場合には役立ちます。この例としては、キーデータベースロックを保持したり、入出力チャネルを占有したりするジョブがあげられます。
これで Joe は夜だけログインしてジョブを実行できます。Joe (と batch グループ全体) の割当数は他のアプリケーションよりもはるかに少ないため、Joe のアプリケーションはマシンの 5 パーセント未満で実行されます。これと同様に、nice(1) を使用すれば、このジョブに接続されるプロセスの優先順位を低くできます。それによって、このジョブは、Solaris Resource Manager の同じ割当数で動作する他のジョブよりも低い優先順位で実行されます。
この時点で、財務部門は、データベースアプリケーションがシステムを十分に使用でき、相互の仕事を妨げないようにできました。さらに、Joe の夜間バッチ処理の負荷を吸収する一方で、この仕事が部門の基幹業務処理を妨げないようにできました。