Solaris 2.6 リリースから、UltraSPARC ( sun4u) プラットフォームでさまざまなページ配置ポリシーを使用する機能が導入されました。ページ配置ポリシーは、L2 キャッシュの使用が最適化されるように物理ページアドレスを割り当てようとするものです。デフォルトアルゴリズムとしてどのアルゴリズムが選択されたとしても、特定のアプリケーション群にとって、そのアルゴリズムが別のアルゴリズムよりも適していない可能性があります。このパラメータは、システムのすべてのプロセスに適用される配置アルゴリズムを変更します。
メモリーは、L2 キャッシュのサイズに基づいて区画に分割されます。マップされていないページでページフォルトが最初に起こると、ページ配置コードは 1 つの区画から 1 つのページを割り当てます。選択されるページは、次の 3 つのアルゴリズムのどれが使用されているかによって異なります。
ページ彩色 – ページが選択される区画は、仮想アドレスのさまざまなビットに基づいて決められます。Solaris 8 リリースでは、これがデフォルトのアルゴリズムです。このアルゴリズムを使用するには、consistent_coloring をゼロに設定します。このアルゴリズムでは、プロセス別の履歴はありません。
仮想アドレス=物理アドレス – プログラム内の連続するページに、連続する区画からページを選択します。このアルゴリズムを使用するには、consistent_coloring に 1 を設定します。このアルゴリズムでは、プロセス別の履歴はありません。
区画飛び越し – プログラム内の連続するページに、通常、1 つおきの区画からページを割り当てます。ただし、このアルゴリズムは、ときには 2 つ以上の区画を飛び越すこともあります。このアルゴリズムを使用するには、consistent_coloring に 2 を設定します。各プロセスは、無作為に選択された区画から開始し、割り当てられた最後の区画のプロセスごとの記録が保管されます。
はい
ありません。値が 2 より大きいと、コンソールに一連の「WARNING: AS_2_BIN: bad consistent coloring value」メッセージが表示されます。その後、ただちにシステムが停止します。復旧には、電源を再投入する必要があります。
システムの主な作業負荷が、長い時間動作するハイパフォーマンスコンピューティング (HPC) アプリケーションである場合。この値を変更すると、パフォーマンスが向上することがあります。ファイルサーバーやデータベースサーバー、それに多数のアクティブプロセスが動作するシステム (たとえばコンパイルやタイムシェアリングサーバーなど) では、この値を変更しても効果はありません。
変更の可能性あり
tsb_alloc_hiwater を初期化して、変換記憶バッファー (TSB) に割り当てることのできる物理メモリー量に、次のように上限を設けます。
tsb_alloc_hiwater = 物理メモリー (バイト数) / tsb_alloc_hiwater_factor
TSB に割り当てられたメモリーが tsb_alloc_hiwater の値と等しい場合、TSB メモリー割り当てアルゴリズムはマッピングされていないページとして TSB メモリーを再利用しようとします。
この係数を使用して tsb_alloc_hiwater の値を増やす場合は、注意が必要です。システム停止を防止するには、高位境界値が swapfs_minfree と segspt_minfree の値よりかなり小さくなるようにする必要があります。
整数
32
1 から MAXINIT
係数 1 の場合、すべての物理メモリーを TSB に割り当てることができるようになるので、システムが停止する可能性があります。また、係数が大きすぎると、TSB に割り当てることのできるメモリーが残らないので、システムパフォーマンスが低下します。
はい
なし
非常に大型の共有メモリーセグメントに接続するプロセスがシステムに多数ある場合、このパラメータ値を変更します。ほとんどの場合、この変数のチューニングは不要です。
変更の可能性あり
整数
デフォルト値は 0 (8K バイト) です。これは 512 エントリに対応します。
指定可能な値は、次のとおりです。
値 |
説明 |
---|---|
0 |
8K バイト |
1 |
16K バイト |
3 |
32K バイト |
4 |
128K バイト |
5 |
256K バイト |
6 |
512K バイト |
7 |
1M バイト |
はい
なし
通常、この値を変更する必要はありません。しかし、システム上のプロセスの大半が平均より大きい作業用セットを使用する場合、または常駐セットサイズ (RSS) のサイズ調整が無効な場合は、この値を変更することによって利益が得られることもあります。
変更の可能性あり
詳細は、「default_tsb_size (Solaris 10 リリース)」を参照してください。
ブール型
1 (TSB のサイズ変更が可能)
0 (TSB は tsb_default_size のまま) または 1 (TSB のサイズ変更が可能)
0 に設定した場合、tsb_rss_factor は無視されます。
はい
はい
0 に設定すると、TSB の増加を防ぐことができます。ほとんどの場合、このパラメータはデフォルト設定のままにしておくべきです。
変更の可能性あり
詳細は、「enable_tsb_rss_sizing (Solaris 10 リリース)」を参照してください。
RSS 発見的容量調整の RSS 対 TSB 期間比を制御します。この係数を 512 で割ると、TSB がサイズ変更候補とみなされるまでに、メモリーに常駐していなければならない TSB 期間の割合が出ます。
整数
384。これは 75% の値になります。このため、TSB が 3/4 に達するとサイズが増やされます。いくつかの仮想アドレスは通常、TSB の同じスロットにマップされます。したがって、TSB が 100% に達する前に衝突が起こることがあります。
0 から 512
はい
なし
TSB での仮想アドレスの衝突による場合など、システムが TSB ミスに起因する過度の数のトラップに直面している場合は、この値を 0 に減らしてもよいかもしれません。
たとえば、tsb_rss_factor を 384 (事実上は 75%) ではなく 256 (事実上は 50%) に変更すると、状況によっては、TSB における仮想アドレスの衝突を排除できることがありますが、特に負荷の大きいシステムでは、カーネルメモリーの使用量が増えます。
TSB の動きは、trapstat -T コマンドで監視できます。
変更の可能性あり
詳細は、「tsb_rss_factor (Solaris 10 リリース)」を参照してください。