WebSphere Application Server, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

接続プール設定

このページを使用して、接続プール設定を構成します。

この管理コンソール・ページは、特定のリソース・タイプ (例えば、JDBC データ・ソースや JMS キュー接続ファクトリーなど) に共通のものです。 このページを表示する際のパスはリソースのタイプによって異なります。 一般的な表示手順としては、リソース・プロバイダーのインスタンスを選択し、次にそのリソース・タイプのインスタンスを選択し、「接続プール」をクリックします。

例えば、「リソース」>「JDBC プロバイダー」>「JDBC_provider」>「データ・ソース」>「data_source」>「接続プール」とクリックします。 JMS キュー接続ファクトリーのパスはもう少し複雑で、「リソース」>「JMS プロバイダー」>「デフォルトの メッセージング」>「JMS キュー接続ファクトリー」>「JMS_queue_connection_factory」>「Connection Pool Properties」の順にクリックします。

「構成」タブ

接続タイムアウト

接続要求がタイムアウトになり、 ConnectionWaitTimeoutException がスローされるまでの時間 (秒) を指定します。

この値は、通常、特定接続プールの接続数が最大値に達したために、空きプール内に使用可能な接続がなく、また新規接続が作成できない時に、接続要求が待機する秒数を示します。 例えば、接続タイムアウトが 300 に設定されていて、最大数の接続がすべて使用中の場合は、プール・マネージャーは、物理接続が使用可能になるのを 300 秒待機します。 物理接続がこの時間内に使用可能にならない場合は、プール・マネージャーが ConnectionWaitTimeout 例外を開始します。 getConnection() メソッドを再試行しても、通常は効果がありません。待機時間を長くする必要がある場合、接続タイムアウトの設定値を増加させる必要があります。 ConnectionWaitTimeout 例外がアプリケーションによってキャッチされた場合、 管理者は予期されるアプリケーションの接続プールの使用法を確認し、それに従って接続プールとデータベースを調整する必要があります。

接続タイムアウトが 0 に設定されている場合、 プール・マネージャーは、接続が使用可能になるまで必要なだけ待機します。 これは、アプリケーションがトランザクションを完了して接続をプールに戻す時、または接続数が最大接続値を下回り、新規物理接続の作成が許可された時に起こります。

最大接続数が 0 に設定されていると、物理接続の数が無制限になるので、 接続タイムアウト値は無視されます。

データ型 整数
単位
デフォルト 180
範囲 0 から最大の整数
最大接続数

このプールに構築できる物理接続の最大数を指定します。

これらは、バックエンド・リソースへの物理接続です。 一度この数値に到達すると、新規の物理接続は構築されず、 リクエスターは、現在使用中の物理接続がプールに戻されるか、 ConnectionWaitTimeoutException がスローされるまで待機します。例えば、最大接続数 が 5 に設定されていて、5 つの物理接続が 使用中の場合、プール・マネージャーは、接続タイムアウトに指定された 時間、物理接続が空くのを待機します。

バックエンド (DB2 データベースまたは CICS サーバー) から接続を要求する可能性がある接続プールの数を把握しておくと、最大接続プロパティーの値の決定に役立ちます。

同じデータ・ソース構成または J2C 接続ファクトリー構成を使用する、複数のスタンドアロン・アプリケーション・サーバーの場合、別の物理接続プールが各サーバーについて存在します。 これらの同じアプリケーション・サーバーを複製する場合、WebSphere Application Server は各クローンについて別々の接続プールを実装します。

これらのすべての接続プールは、同じデータ・ソースまたは接続ファクトリー構成に対応します。 したがって、これらすべての接続プールは、同時に同じバックエンド・リソースから接続を要求する可能性があります。 このコンソール・パネルでユーザーが設定する単一の最大接続値は、これらの接続プールのそれぞれに適用されます。 その結果、最大接続値を高く設定すると、接続要求が、バックエンド・リソースに大きな負荷をかける数になる可能性があります。

データ型 整数
デフォルト 10
範囲 0 から最大の整数

最大接続数が 0 に設定されていると、接続タイムアウト値は無視されます。

ヒント: パフォーマンスを改善するには、接続プールの値を Web コンテナー・オプションの 最大接続数の値より低く設定します。 低い設定 (例えば、10 から 30 の接続) では、高い設定 (例えば、100) の場合よりもパフォーマンスが向上します。

Tivoli Performance Viewer を使用して、最適なプール内の接続数を見つけます。同時待機数が 0 より 大きいにもかかわらず、CPU 負荷が 100% 近くに達しない場合は、接続プール・サイズを大きくすることを検討します。通常のワークロード下で使用パーセントが常に低い場合は、プール内の接続数を減らすことを検討します。

最小接続数

維持する物理接続の最小数を指定します。

接続プールのサイズが最小接続プール・サイズと同じかまたはそれより小さい場合、「未使用タイムアウト」スレッドは物理接続を破棄しません。 しかし、プールは単独では接続を作成して最小接続プール・サイズを維持することを保障しません。 また、経過タイムアウトの値を設定すると、最小プール・サイズ設定にかかわらず、経過時間の有効期限が切れた接続は破棄されます。

例えば、「最小接続数」の値が 3 に設定されていて、1 つの物理接続が作成される場合、その接続が「未使用タイムアウト」スレッドによって廃棄されることはありません。 同じトークンによって、スレッドが自動的に 2 つの追加の物理接続を作成し、 「最小接続数」の設定値に達することはありません。

データ型 整数
デフォルト 1
範囲 0 から最大の整数
リープ時間

プール維持スレッドの実行とその次の実行との間隔 (秒) を指定します。

例えば、「リープ時間」が 60 に設定されていると、プール維持スレッドは 60 秒ごとに実行されます。 リープ時間 の間隔は、 未使用タイムアウト経過タイムアウト の設定値の精度に影響を与えます。 間隔が短いほど精度は高まります。 プール維持スレッドが使用可能である場合は、 リープ時間値を、未使用タイムアウトや経過タイムアウトの値より少なく設定してください。 プール維持スレッドが実行されると、 未使用タイムアウトで指定された値より長い時間使用されていない接続をすべて廃棄します。 廃棄は、最小接続数 で指定された接続数になるまで行われます。プール維持スレッドは、 経過タイムアウトで指定された時間値よりも長い間アクティブである接続も、すべて廃棄します。

リープ時間間隔も、パフォーマンスに影響を与えます。間隔が短いということは、 プール維持スレッドの実行回数が増え、パフォーマンスが低下することを意味します。

プール維持スレッドを使用不可にするには、リープ時間を 0 に設定するか、 または未使用タイムアウトと経過タイムアウトの両方を 0 に設定します。 プール維持スレッドを使用不可にするためには、リープ時間を 0 に設定する方法をお勧めします。 この場合、未使用タイムアウトと経過タイムアウトは無視されます。 ただし、未使用タイムアウトと経過タイムアウトが 0 に設定されている場合は、 プール維持スレッドは実行されますが、 タイムアウト値が非ゼロであるためにタイムアウトになる物理接続だけは廃棄されます。

データ型 整数
単位
デフォルト 180
範囲 0 から最大の整数
未使用タイムアウト

未使用またはアイドルの接続が廃棄されるまでの時間 (秒) を指定します。

パフォーマンスを最適化するためには、未使用タイムアウト値を、リープ時間より高く設定してください。 未使用の物理接続が廃棄されるのは、接続の現行数が、 最小接続数の設定値を超える場合に限られます。例えば、未使用タイムアウト値が 120 に設定され、 プール維持スレッドが使用可能 (リープ時間が 0 でない) である場合、 2 分間未使用の状態が続いた物理接続は廃棄されます。 パフォーマンスと同様、このタイムアウトの精度も「リープ時間」値の影響を受けることに注意してください。詳しくは、『リープ時間』を参照してください。

データ型 整数
単位
デフォルト 1800
範囲 0 から最大の整数
経過タイムアウト

物理接続が廃棄されるまでの時間 (秒) を指定します。

経過タイムアウト」を 0 に設定すると、 アクティブな物理接続を無制限にプールに残しておくことができます。 パフォーマンスを最適化するには、「経過タイムアウト」を「リープ時間」より高い値に設定してください。 例えば、経過タイムアウト値を 1200 に設定し、リープ時間の値が 0 でない 場合は、1200 秒間 (20 分間) 存在し続けている物理接続はプールから廃棄されます。 唯一の例外は、経過タイムアウトに達したときに、接続がトランザクションに含まれている場合です。 その場合には、トランザクションが完了したあと、即時に接続がクローズされます。

パフォーマンスと同様、このタイムアウトの精度もリープ時間値の影響を受けます。 詳しくは、『リープ時間』を参照してください。

データ型 整数
単位
デフォルト 0
範囲 0 から最大の整数
パージ・ポリシー

不整合な接続 または致命的接続エラー が検出されたときに、 接続をパージする方法を指定します。

有効な値は「EntirePool」および「FailingConnectionOnly」です。

データ型 ストリング
デフォルト
  • J2C 接続ファクトリーおよび JMS 関連接続ファクトリーの場合は EntirePool
  • WebSphere バージョン 4.0 データ・ソースの場合は EntirePool
  • 管理コンソールで作成する現行バージョンのデータ・ソースの場合は EntirePool
  • wsadmin AdminConfig コマンドでスクリプトを実行する現行バージョンのデータ・ソースの場合は EntirePool。これは、WebSphere Application Server に組み込まれる JDBC テンプレートを呼び出します (コマンド createUsingTemplate について詳しくは、インフォメーション・センターの項目『AdminConfig オブジェクトのコマンド』を参照してください。)
  • JDBC テンプレートを呼び出さないで wsadmin でスクリプトを実行するデータ・ソースの場合は FailingConnectionOnly
:
範囲
EntirePool
プール内の接続は、すべて失効とマークされます。使用されていない接続は、直ちに閉じられます。 使用中の接続は閉じられ、その接続に次回操作が行われたときに不整合接続の例外が発行されます。 アプリケーションからの後続の getConnection() 要求の結果、 開かれているデータベースへの新規接続が発生します。 このパージ・ポリシーを使用しているときは、 プール内の一部の接続が、失効していない場合に不必要に閉じられる可能性が若干あります。 ただし、これはめったに起こりません。たいていの場合は、パージ・ポリシーを EntirePool に設定するのが最善の選択です。
FailingConnectionOnly
不整合接続例外の発生原因である接続だけがクローズされます。この設定により、有効な接続が不必要に閉じられなくなる一方で、アプリケーション・パースペクティブからのリカバリーがより複雑になります。 現在失敗している接続だけが閉じられるため、 アプリケーションからの次の getConnection() 要求により、 プールからやはり失効した接続が戻され、結果的により多くの不整合接続の例外が 発生する可能性が極めて高くなります。

接続の事前テスト機能は、 無効なプール済み接続からアプリケーションを分離させます。 データベースなどのバックエンド・リソースが停止した場合、無効なプール済み接続が、空きプールに存在していることがあります。 これは、パージ・ポリシーが failingConnectionOnly の場合、特に発生します。この場合には、障害のある接続は、 そのプールから除去されます。障害によっては、プール内の残りの接続が、無効になっている場合があります。




関連概念
リソース・アダプター
JDBC プロバイダー
接続プール
関連タスク
データ・アクセス・アプリケーションの管理
関連資料
管理コンソールの設定の変更
管理コンソール・ページのフィーチャー
AdminConfig オブジェクトのコマンド
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 22, 2008 12:07:38 AM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/udat_conpoolset.html