この項では、Solaris固有のチューニングについて説明します。これらのプラットフォーム固有のチューニングのヒントおよび実行するすべての変更は、システム上の他のプロセスに影響を与える可能性があることに注意してください。
プラットフォームが異なると、1つのプロセスで一度に開くことができるファイル数の制限が異なります。ビジー状態のサイトでは、この数値を大きくします。Solarisシステムでは、/etc/system
ファイルのrlim_fd_max
およびrlim_fd_cur
を設定して、この制限を制御します。Solaris 11の場合、rlim_fd_max
のデフォルトは65536、rlim_fd_cur
のデフォルト値は256です。
/etc/system
ファイルにこの変更またはなんらかの変更を加えた後は、新しい設定を有効にするため、Solarisを再起動します。また、Solarisを新しいバージョンにアップグレードする場合は、/etc/system
に追加したすべての行を削除し、その行がアップグレード後も有効であることを確認した後にのみ、追加しなおします。
この変更を行うもう一つの方法は、ulimit –n <value>
コマンドを使用することです。このコマンドを使用する場合、システムの再起動は不要です。ただし、このコマンドはログイン・シェルを変更するのみであるのに対し、etc/system
ファイルの編集はすべてのシェルに影響を与えます。
Oracle Traffic Directorインスタンスに大きな負荷がかかり、クライアントで接続タイムアウトが発生する場合は、HTTPリスナー・バックログ・キューのサイズを増やすことができます。この設定値を増やすには、HTTPリスナーのリスニング・キューの値を編集します。
これに加えて、Solaris TCP/IPネットワーキング・コード内の制限値も増やす必要があります。次のコマンドを実行して変更されるパラメータは2つあります。
ipadm set-prop -p _conn_req_max_q=4096 tcp ipadm set-prop -p _conn_req_max_q0=4096 tcp
これら2つの設定で、待機接続で満たされる可能性がある2つのSolarisリスニング・キューの最大値が増加します。設定_conn_req_max_q
は、accept()
コールからの戻りを待つ完了済の接続数を増やします。設定_conn_req_max_q0
は、ハンドシェイクが未完了の接続の最大数を増やします。_conn_req_max_q
および_conn_req_max_q0
のデフォルト値はそれぞれ、128および1024です。
これらの変更の効果は、netstat -s
コマンドを使用し、tcpListenDrop
、tcpListenDropQ0
およびtcpHalfOpenDrop
の値を見ることで監視できます。その値を確認してから、これらの値を調整します。カウンタが0でない場合は、最初に値を2048に調整し、netstat
の出力の監視を継続します。
Oracle Traffic Directorで処理できる数よりも多くの接続を受け入れないでください。tcpListenDrop
、tcpListenDropQ0
およびtcpHalfOpenDrop
パラメータの値を2048に設定すると、通常は接続リクエストの失敗が減少し、4096までの値で改善効果が見られます。
HTTPリスナーのリスニング・キュー設定および、関連するSolarisの_conn_req_max_q
および_conn_req_max_q0
の設定は、Oracle Traffic Directorのスループットと一致することになります。これらのキューは、Webユーザーからの不規則な接続率を管理するバッファとして機能します。これらのキューを使用することで、Solarisでは、Oracle Traffic Directorで接続が処理されるまで、その接続を受け入れて保持できます。
TCPバッファリングは、send_buf
パラメータおよびrecv_buf
パラメータを使用してチューニングできます。これらのパラメータの詳細は、表17-1を参照してください。
UNIXファイル・システム(UFS)ボリュームは、各ファイルがアクセスされた時刻を保持しています。使用中の環境ではファイルのアクセス時刻の更新が重要でない場合、/etc/vfstab
のデータ・ボリュームのマウント・ポイントにnoatime
パラメータを追加することにより、アクセス時刻の更新をオフにできます。次に例を示します。
/dev/dsk/c0t5d0s6 /dev/rdsk/c0t5d0s6 /data0 ufs 1 yes noatime
注意:
noatime
パラメータは、ファイルが変更されたときにはアクセス時刻の更新をオフにせず、ファイルへのアクセスがあるとオフにします。
ZFSでは、zfs set
コマンドを使用して、設定可能なデータセット・プロパティを変更できます。次の例では、tank/home
のatime
プロパティをoff
に設定します。
zfs set atime=off tank/home
Oracle Traffic Directorインスタンスのレスポンス時間は、ディスク・サブシステムのパフォーマンスに大きく影響されます。iostat
ユーティリティを使用して、ディスクのビジー状態やI/Oリクエストの完了の速さ(それぞれ%b
およびsvc_t columns
)を監視できます。サービス時間は、ビジー状態が30%未満のディスクでは重要ではありません。ただし、よりビジーなディスクの場合は、サービス時間が20ミリ秒を超えないようにする必要があります。ビジーなディスクでサービスが遅い場合は、ディスク・パフォーマンスを向上させると、パフォーマンスがかなり改善する可能性があります。ビジーなディスクと負荷が少ないディスクが混在する場合は、ビジーなディスクから負荷が少ないディスクにファイルをいくつか移動して、負荷を分散します。
Solarisでは、システム動作を追跡するツールがいくつか提供されています。それらの出力をファイルに取得して後日分析することもできますが、次に示すツールは、主としてリアル・タイムにシステム動作を監視するために用意されています。
iostat -x 60
コマンドは、ディスク・パフォーマンスの統計を60秒間隔でレポートします。
各ディスクのビジー状態の度合を確認するには、%b
列を見ます。その時点でビジー状態が20%を超えるディスクについては、svct
列でレポートされるサービス時間に注目します。その他の列は、I/O操作率、転送データ量などについての情報を示します。
vmstat 60
コマンドは、仮想メモリー・アクティビティおよび一部のCPU統計を60秒間隔でまとめます。
sr
列を見ると、ページ・スキャン率を追跡できます。その率が高すぎる場合には対処します。また、us
列、sy
列およびid
列を監視して、CPUの使用率を確認します。突然爆発的に増加する処理に対応するため、多くのCPUパワーを予約しておく必要があることに注意してください。また、r
列を追跡して、CPU時間で競合するスレッド数を確認します。この数がCPU数の約4倍を超えたままの場合は、サーバーの並行性を減らします。
mpstat 60
コマンドはCPU統計の詳細を表示し、dlstat show-link -i 60
コマンドはネットワーク・アクティビティの概要を示します。
前述のツールでシステム・パフォーマンスを監視することは重要ですが、その一方で、より長期のパフォーマンス履歴を収集することも、傾向の把握に役立つため、同様に重要です。たとえば、システムのベースライン・レコードは、システムの動作が悪くなり始めた場合に、何が変わったかのかを解明するのに役立ちます。次の手順を実行して、システム・アクティビティ・レポート・パッケージを有効化します。
次のコマンドを実行します。
svcadm enable system/sar
crontab -e sys
コマンドを実行して、sa1
コマンドおよびsa2
コマンドを含む行からコメント文字#
を削除します。サイトのアクティビティ・プロファイルに応じて、コマンドを実行する頻度および時間を調整できます。このファイルの形式の説明は、crontab
manのページを参照してください。
このコマンドを使用すると、システムにより/var/adm/sa
ディレクトリのファイルにパフォーマンス・データが保存され、デフォルトで1か月保持されます。次に、sar
コマンドを使用して、目的の期間の統計を調査します。
次の表は、パフォーマンスおよびスケーラビリティのベンチマークの際に使用されるSolarisのオペレーティング・システムのチューニングを示しています。これらの値は、目的の結果を得るためのシステムのチューニング方法の例を示しています。
表17-1 パフォーマンス・ベンチマークのためのSolarisのチューニング
パラメータ | 有効範囲 | デフォルト値 | チューニング後の値 | 備考 |
---|---|---|---|---|
|
|
256 |
65536 |
弱い制限 |
|
|
65536 |
65536 |
プロセスのオープン・ファイル・ディスクリプタの制限。(関連するソケット、ファイルおよびパイプ(ある場合)の)予想される負荷の詳細の原因となります。 |
|
|
60000 |
600000 |
クライアントにも設定します。 |
|
|
128 |
1024 |
|
|
|
1024 |
4096 |
|
|
|
300000 |
600000 |
|
|
|
7200000 |
9000000 |
トラフィックの多いWebサイトでは、この値を低くします。 |
|
|
1000 |
3000 |
再伝送が30-40%を超える場合、この値を高くします。 |
|
|
60000 |
100000 |
|
|
|
200 |
3000 |
|
|
|
32768 |
65535 |
クライアントにも設定します。 |
|
|
49152 |
128000 |
送信バッファを増やすため。 |
|
|
128000 |
1048576 |
受信バッファを増やすため。 |