WebLogic Server パフォーマンスチューニングガイド

WebLogic Server のチューニングにおける重要推奨事項

WebLogic Server および WebLogic Server アプリケーションのパフォーマンスのチューニングは、複雑で繰り返し実施しなければならない作業です。ここでは、チューニングを始めるにあたり、アプリケーションのパフォーマンスを最適化する上で重要な推奨事項について説明します。ここで説明するチューニング方法は、ほとんどの WebLogic アプリケーションに適用できます。

パフォーマンスに関する目標の設定

サーバで実行するアクティビティのレベルに関する情報を収集します。収集すべき情報としては、予期されるユーザ数やリクエスト数、許容できる応答時間、最適なハードウェアコンフィグレーション (CPU の速度、ディスクのサイズと速度のバランス、必要なメモリ容量など) があげられます。

ハードウェア要件を決定するための一定の公式というのはありません。アプリケーションのニーズを十分に満たすために、必要なソフトウェアおよびハードウェアコンフィグレーションを決定するプロセスをキャパシティプランニングといいます。キャパシティプランニングでは、システムパフォーマンスの目標を評価し、アプリケーションを理解する必要があります。サーバハードウェアのキャパシティプランニングでは、最大のパフォーマンス要件に焦点を絞って検討します。

オペレーティングシステムのチューニング

設定されているデフォルトのチューニングパラメータは、オペレーティングシステムによって異なります。Windows プラットフォームの場合、通常はデフォルト設定を変更する必要はありません。一方、UNIX および Linux オペレーティングシステムでは、通常は適切なチューニングを行う必要があります。

UNIX チューニングパラメータ

WebLogic Server でサポートされている UNIX オペレーティングシステムをチューニングする場合は、以下のガイドラインに従ってください。

Solaris TCP チューニングパラメータ

TCP (transmission control protocol) ソケットのパフォーマンスを向上させるには、tcp_time_wait_interval パラメータを次のように設定します。

ndd -set /dev/tcp tcp_time_wait_interval 60000

このパラメータには、close の呼び出しを発行した後に TCP ソケットを生存させる時間間隔を指定します。Solaris の場合、このパラメータのデフォルト値は 4 分となります。短時間に数多くのクライアントが接続する場合、これらのソケットリソースを保持するとパフォーマンスに大きな悪影響を及ぼします。Solaris でのベンチマーク JSP テストでは、このパラメータの値を 60000 (60 秒) に設定するとスループットがかなり改善するという結果が出ています。オープン途中の接続のキューでサーバがバックアップされている場合は、この値をもっと小さくすることも可能です。

注意 : Solaris 2.7 以前では、tcp_time_wait_interval パラメータを tcp_close_wait_interval と呼んでいました。

その他の Solaris チューニングパラメータの推奨値については以下を参照してください。

Solaris のチューニングオプションの詳細については、以下を参照してください。

「Solaris Tunable Parameters Reference Manual」(Solaris 8)
「Solaris Tunable Parameters Reference Manual」(Solaris 9)

HP-UX チューニングパラメータ

HP-UX のチューニング情報については以下を参照してください。

「Tunable Kernel Parameters」リファレンスドキュメント
「Java Performance Tuning on HP-UX」

AIX チューニングパラメータ

「AIX 5L Version 5.2 Performance Management Guide」を参照してください。

Linux チューニングパラメータ

パケット転送のパフォーマンスを向上させるには、/sbin/ifconfig lo mtu パラメータを次のように設定します。

/sbin/ifconfig lo mtu 1500

mtu (maximum transfer unit) パラメータは、ネットワーク上のパケットに格納できる最大バイト数を表します。設定したパケットサイズが小さすぎると、データのフラグメントが原因でネットワークのパフォーマンスが低下します。

WebLogic Server 用のその他の Linux チューニングパラメータの推奨値については、「Linux チューニングパラメータ」を参照してください。Linux のチューニングの概要については、Linux ベンダのマニュアルを参照してください。また、「Ipsysctl Tutorial 1.0.4」では、Linux で提供されるすべての IP オプションについて説明されています。

Windows チューニングパラメータ

Windows プラットフォームの場合、通常はデフォルト設定を変更する必要はありません。Windows 2000 のチューニングオプションの詳細については、以下を参照してください。

「Microsoft Windows 2000 TCP/IP Implementation Details」
「Windows 2000 Performance Tuning」ホワイトペーパー

データベースの最適化

データベースがエンタープライズレベルのボトルネックになる可能性もあります。データベースの最適なパフォーマンスを実現するには、この節のチューニングガイドラインと、使用しているデータベースの製品マニュアルのチューニングガイドラインに従ってください。

一般的な推奨事項

ここでは、データベースのチューニングに関する一般的な推奨事項を示します。

優れたデータベース設計 - データベースの負荷を複数のディスクに分散して、ディスクへの過負荷ができるだけ発生しないようにします。また、テーブル、インデックス、およびログのサイズや構成を適切に設定することも重要です。
ディスクの I/O の最適化 - ディスクの I/O の最適化は、スループットとスケーラビリティに直接影響します。最高速のディスクへのアクセスでも、メモリへのアクセスに比べると大幅に時間がかかります。ディスクへのアクセス数は、可能なかぎり最適化する必要があります。通常は、I/O に使用するブロックやバッファのサイズを大きくするとディスクへのアクセス数が減り、負荷の大きいプロダクション環境でのスループットがかなり改善します。
チェックポイント - チェックポイントメカニズムでは、すべての不要なキャッシュデータを定期的にディスクにフラッシュ (クリーンアップ) することで、チェックポイントの期間の I/O アクティビティおよびシステムリソースの利用状況を改善します。チェックポイントの間隔を狭めると、ディスク上のデータの一貫性は保持されますが、データベースのパフォーマンスは低下します。チェックポイントメカニズムはほとんどのデータベースシステムに備わっていますが、ユーザレベルの制御が許可されていないデータベースシステムもあります。たとえば、Oracle の場合、管理者はチェックポイントの間隔を設定できますが、ユーザが SQLServer 7.x チェックポイントを制御することはできません。推奨設定については、使用しているデータベースの製品マニュアルを参照してください。

データベース固有のチューニング

ここでは、Oracle、SQL Server、および Sybase のチューニングに関する基本的な推奨事項を示します。各データベースのベンダが提供するマニュアルのチューニングガイドラインも確認してください。

Oracle

この節では、Oracle のパフォーマンスのチューニングについて説明します。

プロセス数 - ほとんどのオペレーティングシステムでは、Oracle サーバへの接続ごとにシャドウプロセスを生成して接続をサービスします。したがって、Oracle で使用できるプロセスの最大数は、同時に処理できるユーザの数と、Oracle サーバが使用するバックグラウンドプロセスの数をカバーできる値に設定しなければなりません。通常、デフォルトの最大数では、並行処理するオペレーションの数が多いシステムには対応できません。プラットフォーム固有の問題については、Oracle の管理者ガイドを参照してください。このパラメータの現在の設定値は、次のクエリを使用して取得できます。

SELECT name, value FROM v$parameter WHERE name = 'processes';

共有プールサイズ - 共有プールは、Oracle サーバの SGA (system global area) の重要な部分です。SGA は、Oracle データベースインスタンスのデータおよび制御情報を格納する共有メモリのグループです。複数のユーザが同時に同じインスタンスに接続した場合、これらのユーザはそのインスタンスの SGA のデータを共有します。SGA の共有プール部分には、2 つの主な領域 (ライブラリキャッシュとディクショナリキャッシュ) のデータがキャッシュされます。ライブラリキャッシュには、SQL 関連の情報と制御構造 (解析済みの SQL 文、ロックなど) が格納されます。ディクショナリキャッシュには、SQL の処理に必要なメタデータが格納されます。

ほとんどのアプリケーションでは、共有プールサイズが Oracle のパフォーマンスに大きく影響します。共有プールが小さすぎると、限られた大きさの空間を管理するためだけにサーバのリソースが消費されてしまいます。これにより CPU リソースが消費され、複数のキャッシュの並行管理に制限のある Oracle では競合が発生する原因となります。トリガやストアドプロシージャを数多く使用すると、より大きな共有プールが必要となります。SHARED_POOL_SIZE 初期化パラメータを使用して、共有プールのサイズをバイト単位で指定できます。
次のクエリを使用すると、共有プール内の空きメモリ量をモニタできます。 SELECT * FROM v$sgastat WHERE name = 'free memory' AND pool = 'shared pool';

最大オープンカーソル数 - Oracle サーバのすべてのリソースが 1 つの接続によって消費されないようにするには、OPEN_CURSORS 初期化パラメータを使用して接続ごとのオープンカーソルの最大数を制限します。残念ながら、このパラメータのデフォルト値は WebLogic Server のようなシステムには小さすぎます。カーソル情報は、次のクエリを使用してモニタできます。

SELECT name, value FROM v$sysstat
WHERE name LIKE 'opened cursor%';

データベースブロックサイズ - ブロックは、Oracle におけるデータ格納の基本単位で、I/O の最小単位でもあります。1 つのデータブロックは、ディスク上の物理データベースの特定のバイト数に相当します。このブロックという概念は Oracle RDBMS に固有のものですので、使用しているオペレーティングシステムのブロックサイズと混同しないようにしてください。ブロックサイズは物理的なストレージに影響するため、この値を設定できるのはデータベースの作成時に限られ、データベース作成後は変更できません。このパラメータの現在の設定値は、次のクエリを使用して取得できます。

SELECT name, value FROM v$parameter WHERE name = 'db_block_size';

ソート領域のサイズ - ソート領域を大きくすると、クエリの処理中にメモリ内でソートを実行できるため、大規模なソートのパフォーマンスが向上します。ソート領域は接続ごとに 1 つしか確保できないため、このサイズの設定は重要になります。通常、この init.ora パラメータのデフォルト値は 6 ～ 8 データブロックです。この値は通常の OLTP 処理には十分ですが、意思決定支援処理、大規模なバルク処理、大規模なインデックス関連の処理などを行う場合は、より大きな値を設定しておく必要があります。この種の処理を実行する場合は、init.ora パラメータを次のようにチューニングします (デフォルトの設定値は 8K データブロック)。

sort_area_size = 65536
sort_area_retained_size = 65536

Microsoft SQL Server

以下に、Microsoft SQL Server データベースのパフォーマンスチューニングパラメータに関するガイドラインを示します。これらのパラメータの詳細については、Microsoft SQL Server のマニュアルを参照してください。

高速 I/O デバイスには tempdb を格納する。
perfmon が I/O の増加を示す場合は回復間隔を広くする。
2KB 以上の I/O ブロックサイズを使用する。

Sybase

以下に、Sybase データベースのパフォーマンスチューニングパラメータに関するガイドラインを示します。これらのパラメータの詳細については、Sybase のマニュアルを参照してください。

回復間隔を狭めると、チェックポイント処理がより頻繁に発生するため I/O 処理が増加する。
2KB 以上の I/O ブロックサイズを使用する。
Sybase では SMP (symmetric multiprocessor) 環境でエンジンの数を制御するが、この設定の推奨値は CPU 数から 1 を引いた値とされている。

最適な JVM 設定の特定

JVM のパフォーマンスを向上させるには、JVM のヒープガベージコレクションおよびヒープサイズのパラメータをチューニングします。Sun HotSpot および BEA JRockit JVM のパラメータのうち、パフォーマンスにもっとも大きく影響するものを以下に示します。詳細については、JVM ベンダのチューニングマニュアルや、「Java 仮想マシン (JVM) の情報」の JVM 関連の情報を参照してください。

Sun JDK

HotSpot VM オプション (-server または -client) を使用する場合は、以下のガベージコレクションパラメータを調整します。

-Xms および -Xmx (起動時には同じ設定を使用)
-XX:NewSize および -XX:MaxNewSize
-XX:SurvivorRatio
-XX:+UseISM -XX:+AggressiveHeap

HotSpot JVM のチューニングの詳細については、「JVM のヒープサイズとガベージコレクション」を参照してください。

BEA JRockit JDK

BEA の JRockit の JVM を使用する場合は、以下のガベージコレクションパラメータを調整します。

-Xms および -Xmx (起動時には同じ設定を使用)
-Xns
-Xgc: parallel
-XXenablefatspin
-XXaggressive

『JRockit JVM チューニングガイド』も参照してください。

WebLogic Server パフォーマンスパラメータのチューニング

WebLogic Server では、実際の環境やアプリケーションに合わせて細かくチューニングできるパフォーマンス関連の多数の OOTB (out-of-the-box) パラメータを使用しています。これらのパラメータをシステム要件に基づいてチューニングすることで、デフォルト設定のまま実行する場合に比べ、単一ノードのパフォーマンスおよびアプリケーションのスケーラビリティ特性を大きく向上させることができます。

使用しているシステムに最適なパフォーマンスを特定するには、以下の WebLogic Server コンフィグレーションチューニングパラメータを調整します。

可能であれば、ネイティブパフォーマンスパック (NativeIOEnabled=true) を使用する。詳細については、「WebLogic Server「ネイティブ IO」パフォーマンスパックの使い方」を参照してください。
ワークマネージャを使用する。詳細については、『WebLogic Server 環境のコンフィグレーション』の「ワークマネージャについて」を参照してください。
JDBC 接続プールを使用する場合は、以下の属性を変更する。

DriverName : Thin Driver または jDriver を使用する。詳細については、「JDBC アプリケーションのパフォーマンスチューニングのヒント」を参照してください。
InitialCapacity : この属性を、MaxCapacity と同じ値に設定する。詳細については、「データベース接続数のチューニング」を参照してください。
MaxCapacity : この値を [スレッド数] と同じ値に設定し、必要であれば適切な値が見つかるまで増加させる。詳細については、「データベース接続数のチューニング」を参照してください。

Statement キャッシュを設定する。詳細については、「浪費の回避」を参照してください。
JSP のコンパイルに使用するデフォルトの Java コンパイラを、jikes や sj に比べてかなり遅い javac に変更することを検討する。詳細については、「Java コンパイラの設定」を参照してください。

ディスクおよび CPU の使用状況のモニタ

上記のパラメータを調整したら、高い負荷をかけた状態でアプリケーションを実行して以下をモニタします。

アプリケーションサーバ (ディスクおよび CPU の使用率)
データベースサーバ (ディスクおよび CPU の使用率)

Solaris および Linux でディスク使用率を確認するには、iostat -D <interval> コマンドを使用します。interval には、モニタサイクルの間隔を秒単位で指定します。CPU 使用率を確認するには、単純に -D フラグをオフにします (iostat <interval>)。

Windows の場合は、パフォーマンスモニタツール (perfmon) を使用してディスクと CPU の使用率をモニタします。

アプリケーションサーバの使用率を 100% にすることを目標とします。アプリケーションサーバの CPU 使用率が 100% に満たない場合は、データベースにボトルネックがないかどうかを確認します。データベースサーバの CPU 使用率が 100% に達する場合は、アプリケーションの SQL 呼び出しクエリのプランを見直します。たとえば、SQL 呼び出しで、インデックスを使用したりリニア検索を実行したりしていないかを確認します。また、データベースサーバの CPU に負荷がかかる ORDER BY 句を、アプリケーションで使用しすぎていないかどうかも確認します。

データベースサーバのディスクがボトルネックになっている (ディスクの使用率が 100% に達している) ことが判明したら、アプリケーションで必要とされるだけの書き込みが実行できていないとみなし、より高速なディスクに交換するか、RAID (redundant array of independent disks) コンフィグレーションに変更します。

データベースサーバがボトルネックではないと判明したら、アプリケーションサーバのディスクがボトルネックになっていないかどうかを確認します。アプリケーションサーバのディスクがボトルネックになる原因としては以下が考えられます。

永続ストアの書き込み
トランザクションロギング (tlog)
HTTP ロギング
サーバロギング

アプリケーションサーバでのディスク I/O を最適化する方法としては、より高速なディスクや RAID の使用、JMS の同時書き込みの無効化、tlog への JTA 直接書き込みの使用、HTTP ログバッファの増設などがあります。

ネットワーク上のデータ転送のモニタ

アプリケーションとアプリケーションサーバの間、およびアプリケーションサーバとデータベースサーバの間のデータ転送の量を確認します。このデータ量がネットワークの帯域幅を超えないようにします。帯域幅を超える場合、ネットワークがボトルネックとなります。これを確認するには、パケットの再転送や重複に関するネットワーク統計値をモニタします。次のコマンドを使用します。

netstat -s -P tcp

netstat -s -P コマンドを使用してその他の TCP パラメータを表示する手順については、「ndd コマンドを使用した TCP パラメータの設定」を参照してください。

頻繁に発生する標準 I/O およびログの確認

アプリケーションにおいて、標準 I/O やログの発生が多すぎないかどうかを確認します。システムのパフォーマンスは、これらのどちらが多すぎる場合でも大幅に低下します。プロダクション環境では、コード内のすべての system.out.println 文を削除します。これらの文は、デバッグを目的として開発環境でのみ使用します。

アプリケーションのボトルネックの特定

ネットワークおよびデータベースサーバがボトルネックになっていないことが判明したら、WebLogic Server アプリケーションを調べます。もっとも重要なのは、クライアントの負荷が高い状態で、WebLogic Server を実行するマシンの CPU 使用率が 100% に達するかどうかです。100% に達しない場合は、アプリケーション内でロックが発生していないかどうかを確認します。ボトルネックを特定してアプリケーションのパフォーマンスを向上するには、市販されているツール (JProbe、OptimizeIt など) を使用してアプリケーションをプロファイリングします。

ヒント : CPU 使用率が 100% に達している場合でも、アプリケーションをプロファイリングしてパフォーマンスを向上させることをお勧めします。

アプリケーションのチューニング

この節では、アプリケーション固有のチューニングによってパフォーマンスを向上させるための推奨事項を示します。

EJB

ステートレスセッション Bean および MDB (メッセージ駆動型 Bean) - 同時実行性を最大化するため、これらの Bean へのリクエストを処理する実行キューのスレッド数と同じかそれ以上の値をプールサイズとして設定する。
同時実行性戦略を使用する。
EJB プールの設定を調整する。
Call-by-reference を使用する。
EJB をキャッシュする。
非同期メッセージの消費用に MDB プールのサイズを大きくする。

「WebLogic Server EJB のチューニング」を参照してください。

JSP とサーブレット

JSP ページチェックおよびサーブレット再ロードを無効にする。
インメモリセッションの永続性を使用する。詳細については、「セッション管理」を参照してください。
JSP をプリコンパイルしておく。詳細については、『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「Precompiling JSPs」を参照してください。
「Servlet Best Practices」

JMS

JMS メッセージセレクタではなく、複数のキューやトピックを使用してメッセージを選択する。
同期レシーバの代わりに、非同期 (onMessage) JMS コンシューマを使用する。
JMS の確認応答およびコミットをできるだけ延期する。

『WebLogic JMS のコンフィグレーションと管理』の「WebLogic JMS のチューニング」を参照してください。

JDBC

新しい接続を作成するのではなく、JDBC 接続プールの [初期容量] および [最大容量] をチューニングして、データベースリクエストができるだけ高速に処理されるようにする。
アプリケーション内で使用する Prepared Statement および Callable Statement をキャッシュして処理コストを最小化する。
一連のデータ処理を収集し、更新トランザクションを単一の文で発行することで、トランザクションを単一のバッチにする。

「JDBC アプリケーションのパフォーマンスチューニングのヒント」および『WebLogic JDBC プログラマーズガイド』の「JDBC アプリケーションのパフォーマンスチューニング」を参照してください。