•
アプリケーションがデータソースを利用して接続を要求した時、データソースの接続プールに未使用 のConnectionオブジェクトがあれば、それを「予約」してアプリケーションが利用します。•
アプリケーションは利用後colose
メソッドを実行すると、接続プールにConnection
オブジェクトが戻 されます。•
アプリケーションがリリースを行わないと、接続プールにConnectionオブジェクトが戻らず、他のア プリから使用できない状態になります。これをConnectionリークといい、接続プールにおいては発 生させてはならない事象の一つです。接続プール
データソース
dsA WebLogic管理対象サーバ
アプリケーション
① getConnection() で予約
② 使用
③ Connectionの
Close()でリリース
WebLogic11g データソースの動作
アプリケーション接続要求時に未使用接続が無い場合①
•
接続プール中のConnectionオブジェクト数が最大容量に達していない場合は、プール中に「増分容 量」で指定した分、新たなConnectionオブジェクトが生成され、アプリケーションはそれを予約、使用 することが可能です。接続プール
データソース dsA
WebLogic管理対象サーバ
アプリケーション
アプリケーション アプリケーション アプリケーション
① getConnection() で予約
②最大容量5で設定し、現在接続数3の場合、
まだプールにConnectionを追加することが可能。
増分容量1なので、接続を1つ追加作成する
③ アプリケーションで 利用可能
WebLogic11g データソースの動作
アプリケーション接続要求時に未使用接続が無い場合②
•
接続プール中のConnectionオブジェクト数が最大容量に達している場合は、接続プールにConnectionオブジェクトが戻るまで「接続予約のタイムアウト」で指定した秒数分だけ待機します。
•
「接続予約のタイムアウト」で待機してもConnection
オブジェクトを得られなかった場合、下記例外 が発生します。• weblogic.jdbc.extensions.PoolLimitSQLException:
weblogic.common.resourcepool.ResourceLimitException:
• No resources currently available in pool dsA to allocate to applications, please increase the size of the pool and retry..
接続プール
データソース dsA
WebLogic管理対象サーバ
アプリケーション アプリケーション アプリケーション
① getConnection() で予約
②最大容量5で設定し、現在使用数5の場合 アプリは「接続予約のタイムアウト」まで待機。
タイムアウトになると例外発生
アプリケーション
アプリケーション
アプリケーション
<Insert Picture Here>
WebLogic11g の JDBC データソースの監視
[ 参考 ] 実行時の統計情報の項目①
• Rutime Beanによる実行時の統計情報の主要な項目
管理コンソールの監視項目名 JDBCDataSourceRuntimeMBeanの属性名 説明
アクティブな接続の平均数 ActiveConnectionsAverageCount 使用中接続の平均数 現在アクティブな接続の数 ActiveConnectionsCurrentCount 現在使用中の接続数
アクティブな接続の最大数 ActiveConnectionsHighCount 同時に使用された接続の最大数 接続遅延時間（msec) ConnectionDelayTime 物理接続の作成に要した平均時間 接続の総数 ConnectionsTotalCount データ・ソースで作成されたデータ
ベース接続の累計数 現在の容量 CurrCapacity 接続プール中の接続数
予約に失敗した要求の数 FailedReserveRequestCount アプリが接続予約に失敗した数 再接続の失敗数 FailuresToReconnectCount データソースが物理接続のリフレッ
シュに失敗した回数
リークした接続数 LeakedConnectionCount アプリがcloseしなかった接続数 使用可能数 NumAvailable 接続プール中の使用可能な接続数 使用不可数 NumUnavailable 接続プール中の未使用の接続数 予約された要求の数 ReserveRequestCount 接続要求の現在の累積数。
[ 参考 ] 実行時の統計情報の項目②
管理コンソールの監視項目名 JDBCDataSourceRuntimeMBeanの属性名 説明 プリペアド・ステートメント・
キャッシュのアクセス数
PrepStmtCacheAccessCount 文キャッシュにアクセスされた累計数
プリペアド・ステートメント・
キャッシュの追加数
PrepStmtCacheAddCount 文キャッシュに追加された文の現在の
累積数 プリペアド・ステートメント・
キャッシュの現在サイズ
PrepStmtCacheCurrentSize 文キャッシュの現在の数
プリペアド・ステートメント
・キャッシュの削除数
PrepStmtCacheDeleteCount キャッシュから削除された文の数
プリペアド・ステートメント・
キャッシュのヒット数
PrepStmtCacheHitCount 文キャッシュが使用された数
プリペアド・ステートメント・
キャッシュの失敗数
PrepStmtCacheMissCount 文キャッシュが使用されなかった数
最大待機時間(秒） WaitSecondsHighCount 接続待機の最大時間
接続待機の現在数 WaitingForConnectionCurrentCount 接続待機している現在の要求数
接続待機の失敗総数 WaitingForConnectionFailureTotal 接続待機後、接続予約に失敗した総数 接続待機の最大数 WaitingForConnectionHighCount 接続待機した要求の最大数
接続待機の成功総数 WaitingForConnectionSuccessTotal 接続待機後、接続を予約できた総数
管理コンソールによる監視例
•
接続プールの「最大容量」値が適切かどうかを監視する例•
下記例では、「最大容量」を2、「接続予約のタイムアウト」を10秒に設定「接続予約のタイム アウト」まで待機している リクエストがある。
予約失敗が 多数発生 待機の最大数が
18発生。
「最大容量」の 2まで達成する ことがある。
これらを総合すると最大容量が不足しており、最低でも20 (2 + 18)に する必要があると判断できる。
監視ダッシュボードによる監視例
•
接続プールの状況を自動的にリフレッシュさせつつ、時系列に確認したい場合などは管理コンソールの 監視ダッシュボードが便利です。•
監視ダッシュボードのURL: http://(host):(port)/console/dashboard
接続プール中 のConnection数
現在使用 されている
Connection数
WLST のスクリプトによる監視例
• WLSTを活用し、データソースの接続プールの監視項目を定期的にチェックしてファイルに書き込んだ
り標準出力に表示するような処理を行うスクリプトを作成できます。
この例では、
5
秒毎に接続プールの状況を取得し 表示とファイル出力を同時に
行うWLSTのスクリプトを実行しています。
（このスクリプトは
WebLogic11g
独習キットvol.2
に 含まれています。）<Insert Picture Here>
WebLogic11g データソースにおける
推奨・注意事項
1. 接続プールの容量について
•
接続プールの容量における推奨事項。接続プールの「初期容量」や「最大容量」の値は同じにする。
•
これは、下記理由によるもの。•
接続プールの初期容量と最大容量が異なる場合、同時リクエスト数によっては接続プール内で新た にDBへの物理接続処理が発生し得る。また接続プールの縮小処理も発生し得る。このDBへの物 理接続や縮小時の切断処理は決して軽くない。•
そのため運用中に接続プール中の接続が増減しないように「初期容量」や「最大容量」の値は同じ にすることを推奨する。初期容量
5
、最大容量5
の場合、WebLogic起動時に接続プールに 5つのConnectionオブジェクトが
作成され、その後増加も減少もしない。
つまり、その分、物理接続や切断の オーバーヘッドが無い
接続プール
2. 接続プールの容量とスレッド数について
•
接続プールの容量における推奨事項。WebLogicで同時実行される最大スレッド数 <= 接続プールの「最大容量」にする。
•
これは、下記理由によるもの。• WebLogic上のアプリケーションはスレッドにて処理されるが、同時実行スレッド数が多くなると、そ
れに対応できる接続プール中の接続が無ければ接続予約時でスレッドの待機が発生してしまい、
性能に影響を与えてしまう。
•
（ただしリクエストによりスレッドがDB接続を行わないこともあるという場合は、この限りではない）• WebLogic
で同時実行される最大スレッド数はワークマネジャー機能でサーバまたはアプリケーション別に指定できる。その際に、最大スレッド数＝特定の接続プールの最大容量として指定すること も可能。
アプリ アプリ
アプリ アプリ アプリ スレッド
スレッド
スレッド スレッド スレッド
接続プール
3. 接続プールのテストについて
•
接続プールのテストにおける推奨事項接続プールでテスト機能を設定するか否かは、データベース障害時の対応における要件と、デー タベース・サーバ側の負荷状況を鑑みて判断する。
• WebLogicのデータソースにはテスト機能が存在し、アプリケーションが予約時、または指定頻度で
指定したSQLを自動実行し、その結果でDBの死活状況をチェック可能。
•
データベース・サーバ側の負荷（CPU
使用率など）が非常に高い場合、接続プールのテスト機能は 極力使用しない方がよい。•
（シングル構成の）データベースが運用中に、障害等で再起動してしまった場合で、その際にWebLogicサーバまたはデータソースの再起動などの手動操作を行うことが許容されない場合は、
「接続予約時のテスト」を
true
にし、かつ「テスト頻度」も設定し、接続テストを実施させる。接続プール
② SQL実行
SELECT 1 from dual
アプリ
①予約
③SQL 結果OKなら 利用させる