JDBC 接続プールの設定 (Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド)

Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド

JDBC 接続プールの設定

データベース集約型アプリケーションで最適なパフォーマンスが得られるよう、Application Server によって管理される JDBC 接続プールの調整を行います。これらの接続プールは生存中のデータベース接続を多数維持しますが、そうした接続を再利用すれば、データベース接続のオープン/クローズによるオーバーヘッドの低減が図れます。この節では、JDBC 接続プールをチューニングしてパフォーマンスを改善する方法について説明します。

J2EE アプリケーションは、JDBC 接続プールによって維持されている接続を、JDBC リソース経由で取得します。複数の JDBC リソースが同一の JDBC 接続プールを参照してもかまいません。そのような場合、1 つの物理的な接続プールがすべてのリソースで共有されます。

JDBC 接続プールの監視

JDBC 接続プールの統計収集は、デフォルトで有効になっています。監視される属性は次のとおりです。

numConnFailedValidation (カウント) 検証に失敗した接続の数。
numConnUsed (範囲) 使用された接続の数。
numConnFree (カウント) プール内の未使用接続の数。
numConnTimedOut (制限付きの範囲) タイムアウトが発生したプール内の接続の数。

統計を取得するには、次のコマンドを使用します。

asadmin get --monitor=true 
serverInstance.resources.jdbc-connection-pool.*asadmin get 
--monitor=true serverInstance.resources.jdbc-connection-pool. poolName.* *

JDBC 接続プールのチューニング

管理コンソールで JDBC 接続プールの属性を設定するには、「リソース」>「JDBC」>「接続プール」>「PoolName」を選択します。パフォーマンスに影響を与える属性は、次のとおりです。

プールサイズの設定

接続プールのサイズを制御する設定は、次のとおりです。

初期および最小プールサイズ: 作成時のプールのサイズおよびその最小許容サイズ。
最大プールサイズ: プールのサイズの上限。
プールサイズ変更量: アイドルタイムアウト発生時に削除される接続の数。タイムアウトよりも長い間アイドル状態になっていた接続が、削除対象の候補となります。プールサイズが初期および最小プールサイズに達すると、接続の削除が停止します。

次の表に、接続プールのサイジング時に考慮すべき利点と欠点をまとめます。

表 3–6 接続プールのサイジング


接続プール	利点	欠点
小さい接続プール	接続テーブルへのアクセスがより高速になります。	要求の処理に必要な接続を十分に確保できない可能性があります。要求がキュー内で費やす時間がより長くなります。
大きい接続プール	要求を処理するための接続がより多く存在します。要求がキュー内で費やす時間が、より少なくなるか、まったくなくなります	接続テーブルへのアクセスがより低速になります。

タイムアウトの設定

タイムアウト設定には次の 2 つがあります。

最大待ち時間: 接続タイムアウトになる呼び出し元 (接続を要求するコード) が待つ時間。デフォルト値は 60 秒です。値ゼロを指定すると、呼び出し元が無制限に待機します。

パフォーマンスを改善するため、「最大待ち時間」をゼロ (0) に設定してください。この場合は基本的に、接続が利用可能になるまで呼び出し元のスレッドがブロックされます。また、この場合、要求ごとに経過した待機時間を追跡する作業の一部からサーバーが解放されるため、パフォーマンスが向上します。
アイドルタイムアウト: プールで接続がアイドル状態のままでいられる最長時間を指定します。この時間が経過すると、プールはその接続を閉じることができます。このプロパティーは、データベースサーバーの接続タイムアウトを制御しません。

使用不可能な接続が Application Server 内に蓄積されないよう、このタイムアウトがデータベースサーバーのタイムアウトよりも短くなるようにしてください (データベース上でそのようなタイムアウトが設定されている場合)。

最高のパフォーマンスを得るには、アイドル接続が削除されないように、アイドルタイムアウトをゼロ (0) 秒に設定します。これにより、通常は新しい接続の作成に伴う不利益がなくなり、アイドルスレッドの監視が無効化されます。ただし、長期間使用されていない接続をデータベースサーバーがリセットしてしまう危険性があります。

遮断レベルの設定

データベースサーバー上での接続プールのトランザクション遮断レベルを制御する設定には、次の 2 つがあります。

トランザクション遮断レベル: プール内のデータベース接続のトランザクション遮断レベルを指定します。このパラメータが指定されなかった場合、プールは、JDBC ドライバが提供するデフォルトの遮断レベルを使用します。
遮断レベルを保証: プールから取得されたすべての接続が、「トランザクション遮断レベル」パラメータに指定された遮断レベルを持つことを保証します。トランザクション遮断レベルが指定された場合にのみ適用されます。デフォルト値は true です。

この設定は、一部の JDBC ドライバのパフォーマンスに、ある程度の影響を与える可能性があります。アプリケーションが接続を返す前にその遮断レベルを変更しないことが確実である場合には、false に設定します。

トランザクション遮断レベルを指定しないようにしてください。それが不可能な場合は、「遮断レベルを保証」を false に設定することを検討し、アプリケーションがプログラミングによって接続の遮断レベルを変更しないことを確認してください。

遮断レベルを指定する必要がある場合には、できるだけ高いパフォーマンスが得られるレベルを指定してください。次に、遮断レベルの一覧をパフォーマンスの高い順に示します。

READ_UNCOMMITTED
READ_COMMITTED
REPEATABLE_READ
SERIALIZABLE

最高のパフォーマンスが得られ、かつ並行性や整合性に関するアプリケーションのニーズも満たせるような遮断レベルを選択してください。

接続検証の設定

次の各設定によって、プールが接続検証を実行するかどうか、およびその実行方法が決まります。

接続検証

Required がチェックされている場合、プールは、接続の検証 (接続が使用可能かどうかのチェック) を行なったあとで、その接続をアプリケーションに渡します。

可能であれば、デフォルト値の false のままにしてください。接続検証を要求すると、プールが接続を返すたびにサーバーが検証アルゴリズムを適用しなければいけなくなるため、getConnection() の待ち時間のオーバーヘッドが増大します。データベースの接続が信頼できる場合には、検証を省略できます。

検証方法

実行する接続検証のタイプ。必ず次のどれかになります。

auto-commit: 接続上で自動コミットの実行を試みます。
metadata: 接続からのメタデータの取得を試みます。
table (指定されたテーブルに対してクエリーを実行する): 「表名」も設定する必要があります。JDBC ドライバが setAutoCommit() や getMetaData() への呼び出しをキャッシュに書き込む場合、この方法を使用しなければいけない可能性があります。

表名

検証方法が「table」の場合にクエリー対象となる表の名前。

「すべての障害ですべての接続を閉じる」チェックボックス

ある単一の検証チェックが失敗した場合にプール内のすべての接続を閉じるかどうか。デフォルトはチェックなしです。失敗した接続を再確立する試行は、1 回行われます。