| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Integration > WebLogic Integration ソリューションのデプロイメント > パフォーマンスのチューニング |
|
WebLogic Integration ソリューションのデプロイメント
|
パフォーマンスのチューニング
以下の節では、WebLogic Integration デプロイメントのパフォーマンスをチューニングする方法について説明します。
WebLogic Integration のパフォーマンスのチューニング
以下の節では、WebLogic Integration のパフォーマンスのチューニング方法について説明します。
一次チューニング リソース
この節では、サーバが実行する作業を管理するためのチューニング可能な WebLogic Integration の一次リソースについて説明します。
また、J2EE-CA リソースのプール サイズをアダプタごとに設定する必要があります。アダプタのチューニング方法については、アダプタのマニュアルを参照してください。
その他の WebLogic Integration リソースはすべて、一次リソースをサポートするためにのみ変更します。
WebLogic Server のパフォーマンスをチューニングする
以下の節では、WebLogic Integration デプロイメント用の WebLogic Server リソースのコンフィグレーション方法について説明します。
WebLogic Server のパフォーマンスのチューニングの概要については、次の URL にある『BEA WebLogic Server パフォーマンス チューニング ガイド』を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/perform/index.html
EJB のプール サイズおよびキャッシュ サイズをコンフィグレーションする
EJB のプール サイズおよびキャッシュ サイズをコンフィグレーション、つまりデフォルト設定で開始して必要に応じて変更することで、WebLogic Integration のパフォーマンスをチューニングできます。一般に、パフォーマンスという点では、プールまたはキャッシュのサイズは小さすぎるよりも大きすぎる方が問題は少なくなります。これらの設定の詳細については、次の URL にある『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「WebLogic Serverへの EJB のデプロイ」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/ejb/deploy.html
BPM イベント リスナ メッセージ駆動型 Bean のプール サイズをコンフィグレーションする
wlpi-mdb-ejb.jar ファイルには、イベント キューのイベントを取り出すイベント リスナ メッセージ駆動型 Bean のプールが格納されています。プール サイズの設定は、受け取ったイベントに基づいて、WebLogic Integration システムで実行されるワークフロー数を制御します。イベントおよび検証イベントキュー用のmessage-driven bean 同様、時限イベント リスナも、wlpi-mdb-ejb.jar ファイルで指定されたクラスタにデプロイされます。これらのmessage-driven bean は、com.bea.wli.bpm.TimerQueueから作業を取り出します。
EventListener と TimeListener のデフォルトのプール サイズにアクセスするには、Administration Console でWLI-BPM イベント プロセッサ EJB (wlpi-mdb-ejb.jar) に対する [EJB 記述子の編集] を選択します。たとえば、イベント リスナ message-driven bean のデフォルト設定は 10 (順序付けされているリスナと順序付けされていないリスナが 5 つずつ) です。
システムに対してカスタム JMS キューをコンフィグレーションする場合は、MDB Generator ユーティリティを使用してプールサイズと関連付けられたキューを設定します。『WebLogic Integration の起動、停止およびカスタマイズ』、「WebLogic Integration のカスタマイズ」の「カスタム Java Message Service キューのコンフィグレーション」を参照してください。
最初は20個のBeanを設定し、モニタを行って Bean の追加が必要かどうか判断することをお勧めします。詳細については、メッセージ駆動型 Bean 数の確認するを参照してください。
その他の EJB のプール サイズおよびキャッシュ サイズをコンフィグレーションする
システムのチューニングを行う場合、以下のキャッシュおよびプール サイズについて考慮することをお勧めします。これらのパラメータは、WebLogic Integration クラスタ内のノードごとにチューニングすることができます。
JDBC 接続プールのサイズをコンフィグレーションする
JDBC 接続プールのサイズをコンフィグレーションすることで、WebLogic Integration のパフォーマンスをチューニングできます。概要については、JDBC 接続プールを参照してください。
WebLogic Integration クラスタ内の各ノードで必要な JDBC 接続プールのサイズを決めるには、次の表のガイドラインに基づいて、サーバごとに必要な接続数を計算します。
各リソースに必要な接続数を計算したら、すべてのリソースに必要な合計を計算し、その値に基づいてクラスタ内の各ノードの JDBC 接続プールをコンフィグレーションします。 パフォーマンスを最適化するには、初期容量と最大容量に同じ値を設定してください。 JDBC 接続のモニタ方法については、JDBC 接続数を確認するを参照してください。 JDBC 接続プールの詳細については、以下の節を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/perform/WLSTuning.html
http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/jdbc.html
実行スレッド プールをコンフィグレーションする
実行スレッド プールで説明されているように、実行スレッド プールをコンフィグレーションすることで、WebLogic Integration のパフォーマンスをチューニングできます。WebLogic Integration クラスタ内の各ノードについて、次の表のガイドラインに基づいて実行スレッド数を計算します。
各リソースに必要なスレッド数を計算したら、すべてのリソースに必要な合計を計算し、その値に基づいてクラスタ内の各サーバのスレッド プール サイズをコンフィグレーションします。 WebLogic Server Administration Console を使用してスレッド プール サイズをコンフィグレーションする方法については、次の URL にある『Adminstration Console オンライン ヘルプ』、「サーバ」の「サーバ コンフィグレーション タスク」を参照してください。 スレッドのモニタ方法については、スレッド数を確認するを参照してください。 J2EE コネクタ アーキテクチャ アダプタ用のリソース接続プールをコンフィグレーションする J2EE コネクタ アーキテクチャ（J2EE-CA）アダプタのリソース接続プールをコンフィグレーションすることで、WebLogic Integration のパフォーマンスをチューニングできます。J2EE コネクタ アーキテクチャを参照してください。特定のアダプタのリソース接続プールをチューニングする方法については、アダプタのマニュアルを参照してください。 B2B の大容量メッセージ サポートをコンフィグレーションする B2B の会話時に交換されるメッセージが大きくメモリに収まらない場合、WebLogic Integration B2B Console で大容量メッセージ サポート機能を有効にしてから、サーバを再起動します（20MB を超えるメッセージは、大容量メッセージとみなされる）。図6-1 は、大容量メッセージ サポート機能を有効にする際に使用するコンソール パネルの領域です。 注意: 大容量メッセージに対する EJB トランザクションのコンフィグレーションに関する詳細については、EJB トランザクションをコンフィグレーションするを参照してください。 図6-1 B2B Console の大容量メッセージ サポート領域
http://edocs.beasys.co.jp/e-docs/wls/docs70/ConsoleHelp/servers.html
EJB トランザクションをコンフィグレーションする メッセージ処理中にトランザクション タイムアウトを示す例外が返される場合は、次の BPM リソースにあるトランザクション タイムアウト パラメータをチューニングすることをお勧めします。
注意: トランザクション タイムアウトは、容量の小さいメッセージの場合より大容量メッセージの処理中の方が発生しやすくなります。
トランザクションタイムアウトパラメータをチューニングするには、wlpi-ejb.jar ファイルと wlpi-mdb-ejb.jar ファイルの trans-timeout-seconds 属性を、90 秒から 1090 秒に変更することをお勧めします。JAR ファイルにアクセスする手順は次のとおりです。
Java 仮想マシン（JVM）をモニタおよびチューニングする
Java 仮想マシン（JVM）は、WebLogic Integration Java コードの実行場所です。WebLogic Integration デプロイメントのパフォーマンスを最適化するには、JVM のコンフィグレーションをチューニングします。たとえば、JVM ヒープ サイズによって、VM がガベージ コレクションを行う頻度と時間が決定されます。WebLogic Integration の場合、最小推奨ヒープ サイズは 512KB です。JVM のコンフィグレーションの詳細については、次の URL にある『BEA WebLogic Server パフォーマンス チューニング ガイド』の「Java 仮想マシン（JVM）のチューニング」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/perform/JVMTuning.html
Sun HotSpot JVM ヒープの構成とガベージ コレクションの詳細については、次の URL を参照してください。
http://java.sun.com/docs/hotspot/gc/index.html
Sun Hotspot JVM のコマンドライン オプションの完全なリストについては、次の URL を参照してください。
http://java.sun.com/docs/hotspot/VMOptions.html
JVM オプションの多くは、setenv.cmd または setenv.sh、および startWeblogic.cmd または startweblogic.sh で設定します。ローエンド システムに対応するため、一部のデフォルト値は低めに設定されています。大規模システムの場合は、JVM をチューニングすることでパフォーマンスを向上させることができます。次の節では、一般的に使用されるオプションについて説明します。
JVM を選択する
WebLogic Server に付属する JDK のバージョンは、何種類かの JVM 実装をサポートしています。Solaris では、サーバ JVM を使用することをお勧めします。サーバ JVM の使用を指定するには、-server 引数を使用します。この引数は、Java 実行プログラム名の直後に指定する必要があります。
Windows システムでは、Hotspot JVM を使用します（WebLogic Integration スクリプトでは、デフォルトでは、-hotspot オプションが使用される）。Windows システムでの Hotspot JVM の使用に問題が発生する場合は、スクリプトに次のオプションを追加することをお勧めします。
-xxMaxPermSize=131072K
Classic JVM では、JIT コンパイラが使用できない、推奨していません。また、Classic JVM を使用すると、Hotspot JVM や サーバ JVM を使用した場合に比べ、サーバの実行速度が低下します
実行時に使用されるコンパイル アルゴリズムを除くと Hotspot JVM とサーバ JVM は、まったく同様です（Hotspot JVM は、クライアント JVM と呼ばれることもある）。
JVM ヒープ サイズをチューニングする
JVM ヒープの最小（初期）サイズと最大サイズは、同じにします。大規模な WebLogic Integration サーバの場合、次のオプション設定のように両方のサイズを 512MB にすることをお勧めします。
-Xms512m -Xmx512m
Solaris システムでは、非常に大きなヒープ向けの追加オプションが用意されています。仮想メモリを使用せずに、物理メモリをヒープに対して直接使用できるオプションは、特に重要です。この機能は、「Intimate Shared Memory（親和型共有メモリ）」と呼ばれます。詳細については、以下のURL を参照してください。
http://java.sun.com/docs/hotspot/ism.html
Hotspot JVM でのガーベジコレクション制御
Hotspot JVM のヒープ領域は、育成ヒープと終身ヒープという 2 つの領域に分割されます。
すべての新しいオブジェクトは、育成ヒープで作成されます。ガベージ コレクションの実行後に残ったオブジェクトのみが、育成ヒープから終身ヒープに移されます。終身ヒープのガベージ コレクションは、終身ヒープほど頻繁には実行されず、そのコレクション処理は、育成ヒープに対するコレクション処理よりもコストが高くなります。
一般的に、育成ヒープのコンフィグレーション時には、一時オブジェクトを格納するのに十分なサイズを設定してください。一般的なアプリケーション サーバ、特に WebLogic Integration の場合、アプリケーションの実際の状態はデータベースに保存されます。要求の処理中に割り当てられたメモリの大部分は、要求が終了すると解放されます。したがって、1 つの要求の中で使用されるオブジェクトが終身ヒープに移されることを防ぐには、育成ヒープのコンフィグレーション時に十分な容量を割り当てることが重要になります。このようにコンフィグレーションすることで、育成ヒープでのガベージ コレクションに比べ、終身ヒープに対するガベージ コレクションの頻度が大幅に減ります（このため、この方法はガベージ コレクションの頻度低下と呼ばれることがある）。
育成ヒープのガベージ コレクションは世代別に実行されます。一般的なガベージコレクションでは、すべての新しいオブジェクトは、育成ヒープ領域から割り当てられます。育成ヒープ領域のすべてのオブジェクトは、オブジェクトの若い世代を構成します。育成ヒープ領域がフルになると、ガベージ コレクタは、部分的なガベージ コレクションを実行します。また、アクセスできなくなった、言い換えれば死滅したオブジェクトが占有していた育成領域のメモリを回復します。育成領域にある、まだ生存しているオブジェクトは、古いオブジェクトを格納するメモリ領域に移動します。世代別ガベージ コレクションの場合、ガベージ コレクタは死滅したオブジェクトのすべてのメモリを検索する必要がないため、フル ガベージ コレクションと比べて、大幅に実行速度が向上します。
ガベージ コレクションおよび JVM パフォーマンスについての詳細は、次の URL にある、『 A Test of JavaTM Virtual Machine Performance』を参照してください。
http://developer.java.sun.com/developer/technicalArticles/Programming/JVMPerf/
グローバル ヒープが 512MB の場合、育成ヒープの妥当なサイズを 128MB にすることをお勧めします。次のコマンドラインの指定では、初期育成ヒープ サイズは 128MBに、サイズの最大値は128MBに、それぞれ設定されています。
-XX:NewSize=128m -XX:MaxNewSize=128m
育成領域は、Eden 領域 1 つと同サイズの下位領域 2 つから構成されています。ガベージ コレクションの実行中に、最後まで残るオブジェクトは下位領域に移動します。サバイバル領域は、2つの下位領域を合わせたサイズです。
サバイバル領域のサイズをチューニングするには、SurvivorRatio パラメータを使用します。サバイバル領域の比率の初期推奨値は 2 です。アプリケーションをモニタして、この値を変更する必要があるかどうか判断します。サバイバル領域の比率を 2 と指定するには、次のオプション設定を使用します。
-XX:SurvivorRatio=2
このパラメータにより、Eden 領域と各下位領域の比率は 2:1 となります。言い換えれば、Eden 領域のサバイバル領域に対する比率は 1:1 で、各下位領域は、育成ヒープのサイズの 1/4 です（同じサイズの下位領域が 2 つあるので 1/2 にはならない）。サバイバル領域が小さすぎた場合、コレクションのコピー時に、直接古い世代用の領域にオーバーフローしてしまいます。サバイバル領域が過剰に大きい場合は、無用な空き領域が発生します。
JVM のヒープ使用率をモニタする
次のフラグを指定して、冗長ガベージ コレクションを有効にすると、ヒープの使用率とガベージ コレクションを最も効率的にモニタできます。
-verbosegc
結果は、標準形式で出力されます。Hotspot JVM の場合は、2 種類の行が表示され、Eden (GC) ヒープおよび 終身ヒープ（フル GC）内のコレクション数が示されます。
また、Weblogic Server Administration Console を使用して、実行時のヒープ使用率をモニタすることもできます。これは、ヒープの要件を定義したり、メモリのリークを識別する際に便利です。
実行時パフォーマンスのモニタおよびチューニング
以下の節では、WebLogic Integration のデプロイメントで実行時のパフォーマンスをモニタする方法について説明します。
WebLogic Server のパフォーマンスをモニタおよびチューニングする
WebLogic Server Administration Console を使用すると、サーバ、JDBC 接続プール、JCA、HTTP、JTA サブシステム、JNDI、EJB などのリソースを含む WebLogic Server ドメインの状態とパフォーマンスをモニタできます。詳細については、次の URL にある『BEA WebLogic Server ドメイン管理』の「WebLogic Server ドメインのモニタ」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/admin_domain/monitoring.html
スレッド数を確認する
システムに十分なスレッドがコンフィグレーションされているかを判断する手順は次のとおりです。
図6-2 アクティブ実行キュー テーブル
ThreadPoolSize パラメータが、スレッド数を制御します。ThreadPoolSize パラメータは、サーバごとに個別に設定されます。
図6-3 サーバのパフォーマンス情報
スレッドを追加するには、次のように、デフォルト キューを選択して、スレッド数を指定します。
スレッドは、次のようにして指定することができます。
図6-5 デフォルトの実行キーのコンフィグレーション
Solaris システムでは、スレッド数の変更によってパフォーマンスが向上するかどうかを調べるには、負荷レベルを変えずにスレッド数の設定変更の前後に mpstat コマンドを実行します。コンテキストが切り替わる回数が低下すれば、パフォーマンスが向上したことになります。
トランザクションの実行回数を確認する
各種トランザクションの実行回数を表示するには、Weblogic Server Administration Console で該当するサーバ名を選択します。右フレームで、[モニタ] タブ、[JTA] タブの順に選択します。[すべてのインスタンスのモニタ] を選択します。
BPM フレームに関連付けられている一部のトランザクションは、変更できません。アプリケーションに関連付けられているトランザクションは変更可能です。トランザクション タイプを変更したり、トランザクションを組み合わせるには、次の手順を実行します。
図6-6 [モニタ] タブ
JDBC 接続数を確認する
JDBC 接続はデータベースへの接続で、データベースにアクセスするたびに新しい接続を確立する必要がなくなるため、スレッドのパフォーマンス問題を回避できます。JDBC 接続用に複数のプールを設定できます。各プールに十分な接続数を設定し、スレッド接続の待機時間が長くならないようにしてください。アクティブ JDBC 接続プールをモニタする手順は次のとおりです。
図6-7 JDBC 接続プール
接続プールのコンフィグレーションを変更する手順は次のとおりです。
図6-8 接続プールのコンフィグレーション
BPM のパフォーマンスをモニタおよびチューニングする
WebLogic Integration Studio を使用すると、ワークフローおよびワークフロー変数のステータスを含むワークフローのパフォーマンスのさまざまな側面をリアル タイムでモニタできます。Studio では、ワークフロー インスタンスを削除したり、負荷およびパフォーマンスの統計に関するレポートを表示したりすることができます。詳細は、『WebLogic Integration Studio ユーザーズ ガイド』の「ワークフローのモニタリング」を参照してください。
BPM のパフォーマンスの主な測定項目は以下のとおりです。
これらのパフォーマンス測定項目の統計値を取得する 1 つの方法は、SQL 文を使用してデータベース インスタンス テーブルから統計値を抽出することです。たとえば、次の SQL コードでは、インスタンス数に関する統計値が計算されます。
コード リスト 6-1 ワークフロー インスタンスの統計値を調べるための SQL コード
select 'INSTANTIATIONS', count(*),
avg((completed-started)*86400),
max((completed-started)*86400),
86400*(max(started)-min(started)) total_duration,
from instance
次の SQL コードでは、終了数に関する統計値が計算されます。
コード リスト 6-2 ワークフロー終了数の統計値を調べるための SQL コード
select 'COMPLETIONS', count(*),
avg((completed-started)*86400),
max((completed-started)*86400),
86400*(max(completed)-min(started)) total_duration
from instance where completed is not null
メッセージ駆動型 Bean 数の確認する
メッセージ駆動型 Bean に関する情報を表示する手順は、次のとおりです。
図6-9 イベント キューのモニタ
message-driven bean の数を変更する手順は次のとおりです。
図6-10 MDB のコンフィグレーション
Bean タイプ数を確認する
WebLogic Server Administration Console を使用して、Bean のタイプと数量を表示できます。
これらの JAR ファイルの詳細については、EJB のプール サイズおよびキャッシュ サイズをコンフィグレーションするを参照してください。次の各図（図6-11、図6-12、図6-13）は、ステートフル Bean、エンティティ Bean、およびメッセージ駆動型 Bean が表示されるウィンドウの領域を示したものです。
次の図は、WLI-BPM Server EJB (wlpi-ejb.jar)に対するステートフル EJBRuntimesb を示しています。
図6-11 ステートフル Bean 情報
次の図は、WLI-BPM Server EJB (wlpi-ejb.jar) に対するエンティティ EJBRuntimesb を示しています。 図6-12 エンティティ Bean 情報
次の図は、WLI-BPM イベント プロセッサ EJB (wlpi-mdb-ejb.jar) に対するメッセージ駆動型 EJBRuntimes を示しています。 図6-13 MDB 情報
キャッシュ フルに関するシステム メッセージが表示される場合、EJB 記述子を編集して、Cache パラメータで該当する EJB の [Max Beans] の値を増やします。 キャッシュがフルになるまでパッシベーションが行われないエンティティ Bean が多数ある場合は、そのエンティティ Bean の Idle Timeout Seconds パラメータ値を小さくできます。
図6-14 アイドル タイムアウトのコンフィグレーション
メッセージ送信を保証する
ビジネス プロセスの設計要件に応じて、ワークフローへのメッセージの送信を保証する 2 つの機能を活用すると便利な場合があります。この節で要約する機能は、具体的には、JMS クライアントからワークフローに送信されるメッセージに適用されます。これには、ワークフロー間のメッセージ送信が含まれます。トレーディング パートナ間で送信されるビジネス メッセージは含まれません（トレーディング パートナのビジネス メッセージはデフォルトでアドレス指定メッセージ配信を使用する）。
以下の機能によってメッセージ配信が保証されます。
これら 2 つの機能を併用することで、ワークフローへのメッセージの配信が保証されます。これらの機能の使い方については、以下を参照してください。
アドレス指定メッセージ配信の使い方の例については、『BPM ユーザーズ ガイド』、「サンプルについて」の「ビジネス プロセスおよびワークフローのモデル化」を参照してください。
トレーディング パートナ間のビジネス メッセージの配信に関する詳細については、『B2B Integration ワークフローの作成』を参照してください。
B2B Integration のパフォーマンスをモニタおよびチューニングする
B2B Integration の機能のパフォーマンスをモニタするには、以下のヒントを検討します。
B2B Integration のパフォーマンスの主な測定項目は以下のとおりです。
詳細は、『B2B Integration 管理ガイド』の「B2B Integration のモニタ」を参照してください。
B2B アクティビティをモニタする
WebLogic Integration B2B Console を使用して B2B アクティビティのレベルを判断します。
図6-15 B2B ログのモニタ
図6-16 B2B 統計のモニタ
Application Integration のパフォーマンスをモニタおよびチューニングする この節では、Application Integration のモニタとチューニングに関する情報を提供します。内容は以下のとおりです。
Application Integration のパフォーマンスをモニタおよびチューニングする
アプリケーション ビューに対して十分な接続数が設定されているかどうかを確認するには、以下の手順で Weblogic Server Administration Console を使用します。
図6-17 アプリケーション ビューの接続のモニタ
アプリケーション ビューに対する最大接続数を表示または変更する手順は次のとおりです。
図6-18 最大プール サイズのモニタ
[Maximum Pool Size] の値は、接続の最大数を表しています。 最大プールサイズの変更手順は次のとおりです。
図6-19 最大プール サイズのモニタ
Application Integration 用の EJB プールをモニタおよびチューニングする
Application Integration のパフォーマンスのチューニングを行う場合は、以下の EJB プールのチューニングについて考慮してください。
EJP のプールのモニタリングおよびチューニングに関する情報については、Bean タイプ数を確認するおよびメッセージ駆動型 Bean 数の確認する参照してください。
アプリケーションのプロファイリング
Java プロファイラ ツール（Jprobe や OptimizeIt など）を使用すると、実行時にアプリケーションのプロファイリングできます。これらのツールでは、システムのパフォーマンスのボトルネックやスレッドの競合を識別できます。起動時のパフォーマンスではなく、必ず実行時のパフォーマンスをプロファイリングしてください。
ハードウェア、オペレーティング システム、およびネットワークのリソースのチューニング
以下の節では、ハードウェア、オペレーティング システム、およびネットワークをチューニングする際に考慮すべき要因について説明します。
詳細については、次の URL にある『BEA WebLogic Server パフォーマンス チューニング ガイド』の「ハードウェア、オペレーティング システム、およびネットワーク パフォーマンスのチューニング」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/perform/HWTuning.html
パフォーマンスのボトルネック
デプロイメントにおける WebLogic Integration のパフォーマンスを最適化するには、以下のハードウェア リソースが互いに会話する方法を理解しておく必要があります。パフォーマンスのボトルネックは、これらのハードウェア リソースが適切にチューニングされていないことが原因で発生します。
ハードウェアをチューニングする デプロイメントにおける WebLogic Integration のパフォーマンスを最適化するには、以下のハードウェアの要因を検討します。
オペレーティング システムをチューニングする
デプロイメントにおける WebLogic Integration のパフォーマンスを最適化するには、以下のオペレーティング システムの要因を検討します。
Windows NT/2000 でコンフィグレーション可能な TCP のチューニング パラメータ
Windows NT または Windows 2000 を搭載したサーバの場合、TcpTimedWaitDelay パラメータをデフォルト値の 240 秒ではなく、60 秒に設定することをお勧めします。このパラメータは Windows レジストリにあり、regedit utility (regedit.exe) を使用して変更、編集することができます。このエントリは次の場所にあります。
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters
デフォルトでは、このエントリは存在しません。
TcpTimedWaitDelayでは、TCP が終了した接続を解放し、そのリソースを再利用できるまでに必要な経過時間を定義します。接続の終了から解放までの期間は、TIME_WAIT ステート、または 2MSL ステートと呼ばれます。この間は、新しい接続を確立するよりも非常に低いコストで、クライアントやサーバへの接続を再開できます。
RFC 793 では、ネットワーク上にあるセグメントの最大有効期間の少なくとも 2 倍以上の間（2MSL）、TCP は終了した接続を維持する必要があります。接続が解放されると、そのソケットの組み合わせと TCP 制御ブロック（TCB）を使用して、別の接続をサポートできます。デフォルトで、MSL は 120 秒に定義されているので、この値は MSL の 2 倍、つまり 4 分になります。ただし、レジストリ エントリを使用して、この間隔をカスタマイズできます。
このエントリの値を小さくすると、終了した接続がより早く解放されるため、新しい接続に対して提供されるリソースが増えます。ただし、この値を小さくしすぎると、接続が完了する前に接続リソースが解放されることがあります。この場合、接続を再確立するためには、追加リソースが必要になります。
注意: 通常、このエントリ値を超えるまで、終了した接続が解放されることはありません。ただし、TCP 制御ブロック（TCB）の範囲外で接続が行われている場合には、この期間を過ぎる前に TCP は接続を解放できます。システムで作成される TCB 番号は、MaxFreeTcbs のパラメータ値で示されます。
Windows NT/2000 システムをモニタする
パフォーマンス モニタ（perfmon.exe）を使用すると、すべてのシステム リソースおよびタスク マネージャ（CPU、メモリ、スレッドなど）をモニタできます。
Solaris のスワップ領域をコンフィグレーションする
ヒープやスレッド限度が小さすぎるあんど、スワップ場所が不十分な場合、メモリ不足エラーを発生することがあります。
Solaris ネットワークをチューニングする
Solaris システムにおけるネットワークのチューニング方法については、次の URL にある WebLogic Server プラットフォームに関するページを参照してください。
http://e-docs.bea.com/wls/platforms/sun/index.html
Solaris システムをモニタする
Solaris システムをモニタする際の推奨コマンドを次の表で示します。
ネットワークのパフォーマンスをチューニングする
デプロイメントにおける WebLogic Integration のパフォーマンスを最適化するには、ネットワークで高いパフォーマンスを実現するための以下の要件を検討します。
データベースのチューニング
デプロイメントにおける WebLogic Integration のパフォーマンスを最適化するには、基盤となるリソースを最大限に活かす必要があります。WebLogic Integration は、実行時の処理を行うためやアプリケーション データの永続性を保証するためにデータベース リソースに深く依存しています。以下の節では、WebLogic Integration デプロイメント内のデータベースのチューニング方法について説明します。
これらの節には、WebLogic Integration のパフォーマンスを最適化する作業を行う場合に検討すべき問題からなるチェックリストを用意してあります。特定のデータベース製品についての詳しい手順については、各製品の適切なマニュアルを参照してください。
一般的なデータベース チューニングの注意点
以下の節では、デプロイメントのさまざまなパラメータおよび機能の設定を調整することでデータベースのパフォーマンスを最適化する方法について説明します。
オープンしているカーソル
一般的に、複数のカーソルを使用することで、並行して実行する処理を増やす（1 つのオープン カーソルが更新を実行する間に、別のオープン カーソルが挿入を実行するなど）ことができますが、データベース サーバが対応できる最大カーソル数には限度があります。この最大プールは、データベース サーバのすべてのセッションおよび接続で共有されます。1 つの接続で使用するカーソルが多すぎた場合、他の接続でカーソルが不足するため、データベースのパフォーマンスとシステムのスケーラビリティが低下します。データベース サーバが対応できる最大オープン カーソル数および同時接続ユーザ数の平均値から、システムに適した値を見積もることができます。その他に、カーソルのオープン時間を最小限に抑えるという方法もあります。
ディスク I/O の最適化
ディスク I/O の最適化は、主要なデータベース チューニング パラメータの中でスループットとスケーラビリティに直接関連するものです。最速のディスクでも、アクセス速度はメモリ アクセスよりはるかに低速です。できる限り、ディスク アクセス数を最適化します。一般に、I/O のブロック/バッファ サイズを大きくするとディスク アクセス数が減るので、プロダクション環境で大きな負荷がかかった場合の実質的なスループットが向上する可能性があります。
推奨設定については、後述するデータベースのチューニングに関する節で該当するデータベースの説明を参照してください。
データベースのサイズ変更とテーブル スペースの編成
データベースの負荷を複数のディスク間で分散すると、ディスクの過負荷を防いだり、過負荷の発生回数を抑えたりできます。データベースのパフォーマンスを最適化する手順は次のとおりです。
たとえば、各ワークフロー インスタンスとその子は、WORKFLOWINSTANCE テーブル内の行を作成します。これらのテーブルは、挿入および更新処理用に最適化する必要があります。このテーブルでの削除処理は、WebLogic Integration Studio を通じてバッチ処理されます。ワークフロー インスタンスを削除するためのバッチ削除処理については、削除処理に対応できるように、十分なサイズを持つロールバック セグメントをコンフィグレーションします。
チェックポイント
チェックポイントは、不要なキャッシュ データを定期的にクリーン アップするための機能です。チェックポイントの実行時には、I/O アクティビティおよび使用されるシステム リソースが増加します。チェックポイントを頻繁に実行すると、ディスク上のデータの整合性は増しますが、データベースのパフォーマンスは低下します。多くのデータベース システムにはチェックポイントの機能がありますが、すべてのデータベース システムがユーザレベルの制御を提供している訳ではありません。たとえば、Oracle の場合、システム管理者はチェックポイントの頻度を設定できますが、ユーザは SQLServer 7.X のチェックポイントは制御できません。推奨設定については、使用しているデータベースの製品マニュアルを参照してください。
データベースの互換性
推奨されているバージョンのクライアントおよびサーバのみを使用します。サポートされているデータベースのリストについては、使用している WebLogic Integration のリリースの『WebLogic Integration リリース ノート』にあるソフトウェア要件を参照してください。
データベースのモニタ
データベース使用の以下の面をモニタします。
Oracle データベースをチューニングする
この節では、Oracle 8.1.7 のパフォーマンスのチューニング方法について説明します。
V$ テーブル
Oracle 8.1.7 には V$ テーブルと呼ばれる一連の動的パフォーマンス ビューが搭載されているため、ユーザは SQL クエリを使用してシステム統計をモニタできます。このとき、ユーザは SYS または SYSTEM ユーザとしてデータベースにログインするか、これらの動的ビューにアクセスするための管理者権限が必要です。これらの動的ビューについては以下の節で説明します。動的ビューの詳細については、Oracle 管理者ガイドおよびチューニングガイドを参照してください。
初期化パラメータ
初期化パラメータ ファイル（init.ora）には、Oracle サーバの初期化パラメータとその値が記述されています。
Windows NT/2000 の場合、このファイルのパスは次のとおりです。
d:¥oracle¥admin¥sid¥pfile¥init.ora
このパス名において、d:¥oracle はインストール先のディレクトリで、sid is データベースのインスタンス ID です（例 : d:¥Oracle¥admin¥hsundb¥pfile¥init.ora）。
このファイルは、PROCESSES = 100 のように、属性と値の組み合わせで編成されます。
ファイルを変更する前に、必ずバックアップを作成してください。変更内容を反映するには、サーバを再起動する必要があります。
サーバの再起動後、このファイルが変更されていることを確認してください。確認を行うには、SQL 文または SQL*Plus コマンドを使用します。パラメータとその値は、動的パフォーマンス ビュー V$PARAMETER に保存されます。
PROCESSES パラメータに対して行われた変更の有効性は、次のクエリを使用して検証します。属性名は、小文字で指定してください。
SELECT name, value FROM v$parameter WHERE name = ‘processes’
あるいは、SQL*Plus シェルで SHOW PARAMETERS parameter_name コマンドを使用します。たとえば、次のコマンド、
SHOW PARAMETERS “parameter”
は、次のクエリと同様の機能があります。
SELECT name, value FROM v$parameter WHERE name LIKE ‘%parameter%’;
パラメータを完全に理解したうえで、パラメータ値を変更してください。パラメータの詳細については、Oracle のマニュアルを参照してください。
共有プールのサイズ
共有プールは、Oracle サーバのシステムグローバル領域（SGA）の重要な部分です。SGA は共有メモリ構造のグループで、Oracle データベース インスタンスに関するデータと制御情報が格納されます。複数のユーザが同時に同一インスタンスに接続すると、そのインスタンスの SGA 内のデータがユーザ間で共有されます。
SGA の共有プール部分では、2 つの主要領域であるライブラリ キャッシュとディクショナリ キャッシュにデータが格納されます。ライブラリ キャッシュには、SQL 関連の情報および制御構造（例: 解析済みの SQL 文、ロック）が格納されます。ディクショナリ キャッシュには、SQL 処理に必要なメタデータが格納されます。
ほとんどのアプリケーションにおいて、共有プールのサイズは Oracle システムのパフォーマンスに重要な影響を及ぼします。共有プールが小さすぎる場合、サーバは限られた使用可能領域の管理のためにリソースを確保する必要があります。Oracle ではさまざまなキャッシュの並行管理に制限があるため、CPU リソースが消費されて、リソースの競合が発生します。使用するトリガや保存手順が多いほど、大きな共有プールが必要です。
HARED_POOL_SIZE 初期化パラメータでは、共有プールのサイズをバイト単位で指定します。プロダクション システムの場合、この値を 9MB 以上にすることをお勧めします。75MB の共有プールを必要とするシステムも珍しくありません。共有プール内の空き容量をモニタするには、次のクエリを使用します。
SELECT * FROM v$sgastat
WHERE name = 'free memory' AND pool = 'shared pool';
共有プール内に常に空き容量がある場合、プール サイズを増やしてもほとんどメリットはありません。また、共有プールが一杯だからといって、必ず問題が発生するとは限りません。一旦共有プール内に格納されたデータは補助記憶装置に移すことができます。アプリケーションとデプロイメントの要件は異なる場合があるため、特定のデプロイメントおよびアプリケーションにもとづいて、この値を設定する必要があります。
最大オープン カーソル
Oracle サーバ内のすべてのリソースが 1 つの接続によって占有されるのを防ぐため、システム管理者は OPEN_CURSORS 初期化パラメータを使用して、接続ごとに最大オープン カーソル数を制限できます。このパラメータのデフォルト値は、WebLogic Server や WebLogic Integration などのシステムでは小さすぎます。175 から 255 の範囲内で値を指定することをお勧めします。カーソル情報は、次のクエリを使用してモニタできます。
SELECT name, value FROM v$sysstat
WHERE name LIKE 'opened cursor%';
最大プロセス数
多くのオペレーティング システムでは、Oracle サーバに接続するたびに、接続に対するシャドウ プロセスが発生しますOracle サーバが対応できる最大プロセス数は、同時接続ユーザ数および Oracle サーバによって使用されるバックグラウンド プロセス数によって決まります。多くの並行処理をサポートする必要のあるシステムの場合、デフォルト値では小さすぎます。200 から 255 の範囲内の値を指定することをお勧めします。固有の情報については、Oracle 管理者ガイドを参照してください。このパラメータの現行設定は、次のクエリを使用して確認できます。
SELECT name, value FROM v$parameter WHERE name = 'processes';
データベースのブロック サイズ
ブロックは、Oracle システムにデータを保存する際の基本単位で、I/O の最小単位です。1 つのデータ ブロックは、ディスク上にある物理データベース領域の特定バイト数に対応しています。ブロックに関するこの概念は、Oracle RDBMS 固有のものです。基盤となるオペレーティング システムのブロック サイズと混同しないでください。このブロック サイズは物理的な記憶域に影響を与えるため、この値を設定できるのはデータベースの作成時に限られます。データベースの作成後は変更できません。
WebLogic Integration リポジトリの特徴とアクセス パターンから想定すると、WebLogic Integration で使用するデータベースを作成する際、ブロック サイズを 8K にすることをお勧めします。このパラメータの現行設定は、次のクエリを使用して確認できます。
SELECT name, value FROM v$parameter WHERE name = 'db_block_size';
一般的なブロック サイズの利点と欠点を以下の表に示します。
システム管理者向けのオプションをチューニングする
この節で説明するチューニング手順は、該当するシステムに精通したシステム管理者またはユーザが実行する必要があります。
警告: この節で説明するチューニング オプションすべてを使用してもパフォーマンスが向上するとは限りません。経験的アプローチでパラメータ値を指定しなければならない場合があります
SNP プロセス
デフォルトで、Oracle サーバにはスケジュール済みのタスクを実行するためのバックグラウンド処理がいくつか作成されています。これらのタスクは、Job Queue 機能または Advanced Replication 機能を使用した場合にのみスケジュールできます（詳細は、Oracle のマニュアルを参照）。これらの Oracle 機能を使用しない場合は、バックグラウンド処理はリソースを無駄に消費します。これらのプロセスを、実際に必要になるまで無効にするには、init.ora ファイルを変更します。
init.ora ファイルで以下のセクションをコメント行にするのが、最も安全な方法です。
# The following parameters are needed for the Advanced Replication #Option
#job_queue_processes = 4
#job_queue_interval = 10
ソート領域のサイズ
ソート領域を拡張すると、クエリの実行時にメモリ内でソートを実行できるため、大容量データのソート処理のパフォーマンスが向上します。どの時点においても、各接続で使用されるソート領域は 1 つしかないため、ソート領域の拡張は重要です。init.ora パラメータのデフォルト値は、通常 6 〜 8 個のデータ ブロックのサイズになります。OLCP 処理の場合は、この値で十分ですが、意思決定支援処理、大容量データの一括処理、および大容量の索引関連処理（索引の再作成など）の場合は、この値を増やす必要があります。これらのタイプの処理を実行する際、次の init.ora パラメータをチューニングしてください（現行では、8K のデータ ブロックが設定されている）。
sort_area_size = 65536
sort_area_retained_size = 65536
テーブルの物理記憶域パラメータ
挿入、更新、削除処理によって、データベース テーブルのサイズは拡張および縮小されます。テーブルが拡張されると追加 I/O が発生するため、データベースの処理速度は低下します。このため、予想されるアクセス数および使用パターンに応じて、各テーブルの物理記憶域のパラメータを設定する必要があります。したがって、パラメータは、主に、テーブルを使用するアプリケーション次第で決まることになります。通常、Oracle システムで使用されているデフォルト値のままでも特に支障はありませんが、パラメータをチューニングすることで、パフォーマンスを飛躍的に向上させることができるインスタンスが数多くあります。この作業は、Oracle RDBMS に精通した DBA のエキスパートが実行してください。以下の節では、スキーマ オブジェクトに共通する保存域パラメータの中でも特に CREATE TABLE コマンドにとって重要なパラメータについて説明します。これらのパラメータの推奨値については、このマニュアルでは扱いません（詳細については、Oracle マニュアルまたは DBA を参照）。ここでは、問題点を事前にチェックする際に便利なパラメータとクエリをいくつか紹介します。
トランザクションによってブロックに変更が加えられると、ブロックのヘッダにフラグが付けられます。トランザクションのコミット時に、このフラグは削除されます。フラグによってブロック内の領域が使用されるため、トランザクションのフラグが増えるとデータの保存領域が減ります。フラグがない場合、トランザクションはブロックへの変更が許可されず、処理を待機する必要があります。Oracle では、ユーザがテーブルごとにブロック当たりのフラグ数を制御できます（更に細かい制御を行うことができるテーブルもありますが、そのような制御については、このマニュアルでは扱わない）。NITRANS パラメータを使用すると、各ブロックに割り当てる初期フラグ数を指定できます（最小値は 1）。MAXTRANS で指定した数まで、フラグを追加できます。空きフラグがない場合、トランザクションはブロックされます。トランザクションがブロックされると、デッドロックが発生する可能性が高くなります（つまり、トランザクションは処理を完了できず、ロックされたリソースが解放されるまで待機する）。MAXTRANS のデフォルト値は 255 ですが、次のクエリを使用して、OLTP に含まれるテーブルに適した値がパラメータに指定されているかを確認してください。
SELECT owner, table_name, ini_trans, max_trans, FROM all_tables;
各ワークフローはアプリケーションのライフサイクルの中で一連のトランザクションを WORKFLOWINSTANCE に対して実行するので、これらの設定はアプリケーションが同時に複数のワークフローに関与する場合に重要となります。
これらのパラメータによって、テーブルの拡張および縮小が制御されます。拡張テーブルは、任意の数のデータ ブロックから構成されます（データベースのブロック サイズを参照）。これらのパラメータによって、テーブルの作成時に割り当てられる拡張テーブルの数（テーブルのサイズは、MINEXTENTS で指定されている値より小さくはできない）、および 1 つのテーブルに割り当てられる拡張ブロックの最大数が制御されます。通常、テーブルを作成する際に、次の設定オプションを使用します。
CREATE TABLE foo (col1 number, col2 date)
STORAGE (MINEXTENTS 1 MAXEXTENTS UNLIMITED);
これらのパラメータ値を確認するには、次のクエリを使用します。
SELECT owner, table_name, min_extents, max_extents
FROM all_tables;
MAXEXTENTSでUNLIMITED オプションを指定すると、クエリによって返される値が非常に大きな整数（2147483645 など）となります。
Redo ログをスワップする
回復処理をサポートするため、Oracle RDBMS に対して実行されるすべての処理は、Redo ログに記録されます（特定の処理に対するロギングが明示的に無効になっている場合を除く）。時間の経過とともに、ログ内の情報量が増え、最終的には処理のパフォーマンスに影響を与え始めます。回復処理はバックアップデータを使用して実行できるため、データベースのバックアップを実行した直後は、Redo ログ内の情報は必要なくなります。このため、バックアップ後に不要になった情報をクリーン アップして 新しい Redo ログを開始し、システム パフォーマンスを回復することをお勧めします。この処理を実行するには、次の SQL コマンドを使用します。
ALTER SYSTEM SWITCH LOGFILE
Redo ロギング、Redo ログとログ グループの管理、および RDBMS のバックアップの最適な実行方法の詳細については、Oracle のマニュアルを参照してください。
テーブルの再編成
SQL 処理（OLTP および Bulk）によってテーブルが拡張または縮小される際、テーブルの保存領域が断片化する場合があります。これによってパフォーマンスが低下するため、領域のギャップを回収してテーブル データをひとまとめにするユーザ介入処理が必要になります。通常、この処理はテーブルの再編成と呼ばれます。Oracle 8.1.7 には、この処理をサポートする機能が組み込まれていないため、ユーザはこの処理を手動で行う必要があります。推奨手順に従って、データベースのバックアップ直後に、この処理を実行してください。テーブル foo の再編成手順は、次のとおりです。
CREATE TABLE foo_bkup AS SELECT * FROM FOO;
DELETE TABLE foo;
RENAME foo_bkup TO foo
プロセスの各手順には、DDL 文（CREATE TABLE、DROP TABLE など）が含まれます。DDL statements are not transactional in Oracle. 厳密には、DDL 文は完全に独立したトランザクションの中で実行されます。このため、テーブルの再編成中は ROLLBACK コマンドは実行されません。
Microsoft SQL Server データベースをチューニングする
次の表では、Microsoft SQL Server データベースに固有のパフォーマンス チューニング パラメータについて説明します。パラメータの詳細については、Microsoft SQL Server のマニュアルを参照してください。
Sybase データベースをチューニングする 次の表では、Sybase データベースに固有のパフォーマンス チューニング パラメータについて説明します。パラメータの詳細については、Sybase のマニュアルを参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
