Download - WebLogic Server 11g - パフォーマンス・チューニング
<Insert Picture Here>
Oracle WebLogic Server パフォーマンス・チューニング
日本オラクル株式会社 Fusion Middleware事業統括本部 ソリューション本部Application Gridソリューション部
Copyright© 2011, Oracle. All rights reserved. 2
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
Copyright© 2011, Oracle. All rights reserved.【PR】
Copyright© 2011, Oracle. All rights reserved.
Agenda
• パフォーマンス・チューニング概要
• Java EE環境におけるチューニング・ポイント
• Java EEアプリケーションのチューニング
• Java EEサービスのチューニング
• WebLogic Serverのチューニング
• JVMのチューニング
4
Copyright© 2011, Oracle. All rights reserved. 5
<Insert Picture Here>
パフォーマンス・チューニング概要
Copyright© 2011, Oracle. All rights reserved.6
前提条件と要件(目標)の設定
• システムの「性能」を考える場合、前提条件と要件を明確にする
• 対象アプリケーション
• 最大ユーザ数
• 時間当たりの要求数
• リクエストのデータ量
• レスポンスのデータ量
• 内部処理(DBからのデータ取得や書き込み等)のデータ量
• 性能要件
• WebブラウザでSubmitしてから画面表示終了まで3秒以内
• 2時間以内に 5000万件のデータに対する処理を完了させること
Copyright© 2011, Oracle. All rights reserved.7
性能が問題になった場合
• 原則、ボトルネックを見出すことが解決策• ボトルネックの調査にはJRockit Flight Recorderが有用(WebLogic10.3.3以降)
• JVMをJRockitにしてフライト記録を取り続ける運用にする。
• チューニングで対応できるのであればよいが、下記のように想定外の要因の場合は、根本的なシステム構成の見直しが必要になる。
• 想定より多くのユーザがアクセスしている
• 想定よりも膨大なデータを処理している
• CPUはほぼ100%使い切っている
• そのリスクを削減するには、性能面で拡張できる構成を検討しておくべき
• または、リクエスト制限を行う仕組みを検討しておくべき
H/WやS/Wのチューニングで対応できるか否かの
見極めが重要
Copyright© 2011, Oracle. All rights reserved.8
チューニングの余地があると思われる事象
• DB
• 扱うデータ量が多いわけでもないのに特定のSQLが遅い
• Disk I/Oに時間がかかっているがCPU使用率が高いわけではない
• DB側で内部処理でロックによる待機イベントが発生している
• Webアプリケーション・サーバ(Java EE)
• 特定のアプリの特定の処理時間だけが遅い
• フルガベージ・コレクションが頻繁に発生している
• CPU使用率が高いわけではないのにレスポンスタイムが悪い
Copyright© 2011, Oracle. All rights reserved.9
アプリケーションの変更を要する場合
• Javaのコーディング一般的によく言われる基本事項• 文字列連結ではStringオブジェクトと+演算子を使わず、StringBufferオブジェクトのappendメソッドを利用せよ
• Collectionオブジェクトのサイズは生成時に指定して動的拡張しないようにせよ
• 不要になったオブジェクトリファレンスにはnullを代入せよ
• しかし性能問題発生時には、上記のような基本事項を修正して問題が解決するケースは稀。
• プログラムの構造的な見直しを要する場面• JDBCでSQL実行によりデータを取得するのではなく、キャッシュからデータを取得する。
Copyright© 2011, Oracle. All rights reserved. 10
<Insert Picture Here>
Java EE環境におけるチューニング・ポイント
Copyright© 2011, Oracle. All rights reserved. 11
Java EEサーバ環境のチューニング・レイヤWebLogicでは
ApacheやIISなど
WebLogicでは
WebLogic管理対象サーバ
WebLogicではWebサーバプラグインWebLogicでは
JRockitなど
H/W
OS
Webサーバ
H/W
OS
JavaVM
Webコンテナ EJBコンテナ
JDBC
Java EEコンテナネットワーク
Copyright© 2011, Oracle. All rights reserved.12
Java EE環境おけるレイヤ別着眼点
Web
サーバ
HTTP Java EE
コンテナ
Web
ブラウザデータベース
JDBC
JVM
JavaScript処理に負荷がかかっていないか?
リクエストの受け付け窓口の数は適切か?
窓口数を増加させた場合のCPUやメモリ負荷は問題無いか?
HttpSessionに大量のオブジェクトを長時間保持させてい
ないか?
オブジェクトの解放漏れはないか?
オブジェクト生成ロジックに無駄が無いか?
ヒープメモリ設定は適切か?
ヒープメモリを増減した場合のCPU、メモリの負荷とGCの頻度と時間は?
データベースへのコネクション・プーリングの数は適切か?
アプリ
SQL処理に時間がかかっていないか?(特に、解析、I/O系処理に)
リクエストの受け付け窓口の数は適切か?
窓口数を増加させた場合のCPUやメモリ負荷は問題無いか?
Copyright© 2011, Oracle. All rights reserved.13
Java EEにおける性能面での留意事項①
• APサーバが使用するJDKは許容される限り最新のものを使用する• 例:JDK1.5.0_06よりは、JDK1.5.0_16を
• JDKは、提供ベンダーやバージョンによりGCの動作やヒープ構造、オプション指定が異なる。
• HttpSessionオブジェクトのサイズやライフサイクルに注意する• HttpSessionオブジェクトに格納するObjectは最低限にする。
• ログアウト処理などで不要になるオブジェクトは明示的に破棄する
• タイムアウトを無制限にしない。
• ServletではSingleThreadModelインターフェースを実装しない• (基本的に)リクエスト毎にServletインスタンスを生成してしまう
• APサーバにより実装が異なる場合がある
• Servlet 2.4 API仕様では非推奨
Copyright© 2011, Oracle. All rights reserved.14
Java EEにおける性能面での留意事項②
• DB接続ではAPサーバが提供するデータソース(javax.sql.DataSource)を利用し、接続プールを利用する
• 接続プールより取得した java.sql.Connectionオブジェクトは、JDBC処理が終了後必ず close( )メソッドで解放する• 正常終了/異常終了にかかわらず必ずfinally句でclose ()を実行する。
• 接続プールで保持する接続数の初期容量と最大容量を同じにしておく
• SQLは同一で条件値のみ変化する処理を繰り返す場合は、java.sql.PreparedStatementを使用する
Copyright© 2011, Oracle. All rights reserved. 15
JDBC処理をfinallyブロックでcloseする例Connection conn = null;
Statement stmt = null;
ResultSet rset = null;
try {
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/OracleDS");
conn = ds.getConnection();
stmt = conn.createStatement();
rset = stmt.executeQuery("SELECT EMPNO, ENAME FROM EMP");
while (rset.next() ) {
// rset.getString(―ENAME‖); などでデータ取り出し
}
}
catch (SQLException sqlex) {
// 例外時の処理
}
finally {
try {
if (rset != null ) { rset.close(); }
if (stmt != null) { stmt.close();}
if (conn != null) {conn.close();}
}
catch (Exception ex) {}
}
Copyright© 2011, Oracle. All rights reserved.
• PreparedStatement使用時はDB側の解析処理が減るため性能向上が期待できます。
16
PreparedStatementの利用
Statement stmt = conn.createStatement();
for ( int id = 0 ; id < 10000 ; id++ ) {
String sql = "SELECT ENAME FROM EMP WHERE EMPNO = " + id;
ResultSet rs = stmt.executeQuery(sql);
while ( rs.next() ) {
// 表示などの処理
}
}
String sql = "SELECT ENAME FROM EMP WHERE EMPNO = ?";
PreparedStatement ps = conn.prepareStatement(sql);
for ( int id = 0 ; id < 10000 ; id++ ) {
ps.setInt(1,id);
ResultSet rs = ps.executeQuery();
while ( rs.next() ) {
// 表示などの処理
}
}
Statement使用時
PreparedStatement使用時
Copyright© 2011, Oracle. All rights reserved.17
WebLogicチューニング
• WebLogicのチューニングについて、以降の章では下記の観点で説明します。• Java EEアプリケーションのチューニング
• Java EEサービスのチューニング
• WebLogic Serverのチューニング
• JVMのチューニング
Web
サーバ
HTTP Web
Logic
Web
ブラウザデータベース
JDBC
JVM
Java EEアプリケーション
Copyright© 2011, Oracle. All rights reserved. 18
<Insert Picture Here>
Java EEアプリケーションのチューニング- JSP, Servlet
- EJB
Copyright© 2011, Oracle. All rights reserved.19
JSP①• JSPの再変換と再コンパイルのチェック間隔の指定
• Webアプリケーションのweblogic.xmlで下記を指定
• <jsp-descriptor> のpage-check-seconds で秒指定。
• WebLogicの動作モードが「開発」の場合はデフォルトで1秒単位でチェック
• WebLogicの動作モードが「プロダクション」の場合はデフォルトではチェック無し(-1を指定)
• 「プロダクション」モードで運用中にJSPの変更がない場合はチェック無し(-1)でよい。
• 「プロダクション」モードで運用中にJSPの変更頻度が高くない場合は60以上に設定
• 管理コンソールでは、Webアプリケーション管理画面の「コンフィグレーション」タブ画面で設定
Servlet
JSP
ファイル
Java
ソース
Java
クラス
コンパイル2回目以降
変換
変更のチェック
WebLogic
クライアント
ロード
Copyright© 2011, Oracle. All rights reserved.20
JSP②• JSPのプリコンパイルの指定
• Webアプリケーションのweblogic.xmlで下記を指定
• <jsp-descriptor> のprecompile とprecompile-continueにtrueを設定する
• デフォルトはfalse
• クライアントからアクセス時の変換、コンパイルのオーバーヘッドは排除できるがWebLogicの起動時間やアプリのデプロイ時間は長くなる可能性がある
• 管理コンソールでは、Webアプリケーション管理画面の「コンフィグレーション」タブ画面で設定
Servlet
JSP
ファイル
Java
ソース
Java
クラス
コンパイル
変換
WebLogic
クライアントWebLogic起動時やアプリの
再デプロイに変更分をコンパイル
ロード
Copyright© 2011, Oracle. All rights reserved.21
JSPの再変換と再コンパイルのチェック間隔とプリコンパイルの指定例
• JSPの再変換と再コンパイルのチェック間隔を70秒に指定
• JSPのプリコンパイルを行うようにtrueに指定
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app xmlns:wls=“省略">
<wls:weblogic-version>10.3.3</wls:weblogic-version>
<wls:context-root>Test</wls:context-root>
<wls:jsp-descriptor>
<wls:page-check-seconds>3</wls:page-check-seconds>
<wls:precompile>true</wls:precompile>
</wls:jsp-descriptor>
</wls:weblogic-web-app>
weblogic.xml
Copyright© 2011, Oracle. All rights reserved.22
Fast Swap
Servlet
Servlet
クラスWebLogic
クライアント
変更のチェックロード
• クラスのリロードチェック間隔の指定
• ヒープにロードされているインスタンスが常時最新になるようにクラスファイルをチェックする間隔
• Webアプリケーションのweblogic.xmlで下記を指定
• <fast-swap> に秒指定する
• WebLogicの動作モードが「開発」の場合のみ
Copyright© 2011, Oracle. All rights reserved.23
リロード間隔の指定例
• チェック間隔を5秒に指定
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app xmlns:wls=“省略">
<wls:weblogic-version>10.3.3</wls:weblogic-version>
<wls:context-root>Test</wls:context-root>
<wls:fast-swap>
<wls:enabled>true</wls:enabled>
<wls:refresh-interval>5</wls:refresh-interval>
</wls:fast-swap>
</wls:weblogic-web-app>
weblogic.xml
Copyright© 2011, Oracle. All rights reserved.24
EJB①
• Stateless Session Beanのプールの指定
• Stateless Session Beanのインスタンスをプールに保持させる
• 1つのStateless Session Beanへの同時アクセス数を指定するのがのぞましい
• EJBアプリケーションのweblogic-ejb-jar.xmlで下記を指定
• <stateless-session-descriptor><pool>のmax-beans-in-free-pool に最大保持可能数を、initial-beans-in-free-poolに初期保持可能数を指定(同じにしておくのがよい)
• デフォルト値は1000
• Message Driven Beanも同様のパラメータでインスタンスをプールに保持指定可能
• 指定要素は、<message-driven-descriptor>内の<pool>要素
Stateless
Session Bean
WebLogicクライアント
Stateless
Session BeanStateless
Session Bean
Web App
Copyright© 2011, Oracle. All rights reserved.25
EJB②
• Stateful Session Beanのメモリキャッシュの指定
• Stateful Session Beanのインスタンスをメモリに保持させる
• 1つのStateful Session Beanへの同時アクセス数を指定するのがのぞましい
• EJBアプリケーションのweblogic-ejb-jar.xmlで下記を指定
• <stateful-session-descriptor><stateful-session-cache>にmax-
beans-in-cache
• デフォルト値は1000
Stateful
Session Bean
WebLogicクライアント
Stateful
Session BeanStateful
Session Bean
Web AppStateful
Session Bean
Passivate
Disk
Copyright© 2011, Oracle. All rights reserved.26
EJB③
• 引数の値渡し、参照渡しの指定
• WebLogic8.1以降のバージョンはデフォルトは値渡し
• EJBクライアントとEJBが同一アプリケーションの場合は、LocalインターフェースのEJBを使用するか、または明示的に参照渡しにすることでパフォーマンス向上が期待できる
• ただし、使用するアプリケーションが値渡しを前提としたセマンティクスになっていないことが要件となる。
• weblogic-ejb-jar.xmlの<weblogic-enterprise-bean> でenable-call-by-reference
でtrue指定すると参照渡しになる
EJB
ObjectObject
EJB
Object
EJBの引数に
ObjectのReferenceを渡すEJBの引数に
Objectのコピーを生成して渡す
値渡し
(call by value)
参照渡し
(call by reference)
EJB Client EJB Client
Copyright© 2011, Oracle. All rights reserved. 27
<Insert Picture Here>
Java EEサービスのチューニング- JDBC
- JTA
- JMS
Copyright© 2011, Oracle. All rights reserved.28
接続プールの最適化
• アプリケーションの実行中に新しい接続の生成が発生しないように調整しておくことが望ましい• 初期容量=最大容量
• 通常は実行スレッド数よりも多くの接続を使わないように設定する
Copyright© 2011, Oracle. All rights reserved.29
Statementキャッシュの利用
• JDBCデータソースの Statement キャッシュサイズで指定した個数に到達するまで、WLSはアプリケーション・EJBで使われるPreparedStatementオブジェクト、CallableStatementオブジェクトをキャッシュし、次回から同じステートメントの実行時に再利用する
• キャッシュを再利用することでデータベースサーバ側のCPU使用率が下がるため、CPUサイクルを他のタスクに割り当てることが可能となる
Copyright© 2011, Oracle. All rights reserved.30
Pinned-To-Threadプロパティの利用
• データソースで [スレッドに固定] を有効化すると、アプリケーションがデータベース接続の予約に要する時間を最小化できる
• アプリケーションが接続をクローズしても、実行スレッドが接続オブジェクトを保持し続ける(データソースには返却しない)
• 接続予約を試行する複数のスレッド間での競合を削減できる
Copyright© 2011, Oracle. All rights reserved.31
トランザクションとパフォーマンス
• トランザクションのタイムアウト値はデフォルトでは30秒• 通常のトランザクションは数秒の間にコミットかロールバックをする
• トランザクションの使用に対するアドバイス• 性能を向上するためには、トランザクションの時間を短く保つこと
• 必要な場合のみトランザクションを使用するようにする
• 2フェーズコミットはできる限り発生しないようにするにする
Copyright© 2011, Oracle. All rights reserved.32
JMS送り先のパフォーマンスオプション
• メッセージをバッチでコンシューマに送信することで、パフォーマンスを調整することが出来る• JMS送り先にはメッセージのバッチが作成されるまで送信を待機し、コンシューマにまとめてメッセージを送信する機能が備わっている
• JMS送り先の【メッセージングパフォーマンスのチューニング】オプションを使用する
• 複数まとめて送信するため、待ち時間が長くなるが、送出回数が少なくなるため、サーバ全体のスループットが向上する
Copyright© 2011, Oracle. All rights reserved. 33
<Insert Picture Here>
WebLogic Serverのチューニング- ワークマネージャ
-過負荷管理-パフォーマンスパック
Copyright© 2011, Oracle. All rights reserved.34
WLS9.xより前のスレッド管理
• 手動でスレッドプールサイズを調整する必要があった• スレッド数
• キューの長さ
• しきい値
• 最大スレッド数
• スレッドの優先順位
• 負荷の高い作業に対して複数の実行キューを使用
Copyright© 2011, Oracle. All rights reserved. 35
• 複数の実行キューと実行スレッドプール
• スレッドチューニングは手動
実行キュー 実行スレッドプール
バックログ
リッスンポート
マルチ
プレクサ
キュー
Defaultキュー
実行スレッド
リクエスト
実行キュー 実行スレッドプール
カスタムキュー
実行スレッド
内部管理キューにもスレッドプールが存在
リッスンスレッドにより
運ばれるソケットリーダ
スレッドにより
運ばれる何らかの理由でリクエストが
処理できない場合のバッファ
WLS9.xより前のスレッド管理
Copyright© 2011, Oracle. All rights reserved.36
ワークマネージャの利用
• WebLogic Server 9.x ではワークマネージャを使ってスレッドの管理を行う• 自動的にスレッド数が必要に応じて調整される
• アプリケーションの実行優先順位をコンフィグレーションする
• 管理者によるパラメタの定義
• 実行時メトリクス
• リクエストを実行するためにかかった実際の時間
• デフォルトワークマネージャ• アプリケーションがユーザ定義のワークマネージャに割り当てられていないときに使用される
• 全てのアプリケーションが同等の優先順位を持つ
• それぞれのアプリケーションのスレッド割り当てが均等に行われる
• "default" という名前のワークマネージャを定義することでデフォルトワークマネージャの値をカスタマイズすることが出来る
Copyright© 2011, Oracle. All rights reserved. 37
WebLogic 9.x以降のスレッド管理イメージ• 単一の実行スレッドプール。スレッドプール数は自動チューニング。
• ワークマネージャー(スレッド制御ポリシーをもったキュー)により、アプリケーションの実行優先制御が可能に
実行スレッドプール
バックログ
リッスンポート
マルチ
プレクサ
リッスンスレッドにより
運ばれるソケットリーダ
スレッドにより
運ばれる
ワークマネージャーサブシステム
実行スレッド
リクエスト
ワークマネージャー
ワークマネージャー
アプリケーションA
アプリケーションB
何らかの理由でリクエストが
処理できない場合のバッファアプリケーションC
Copyright© 2011, Oracle. All rights reserved.38
ワークマネージャのスコープ
• デフォルトのワークマネージャ• 多くの場合、ほとんどのアプリケーションの要求を満たす
• デフォルトの割り当てが不十分な場合、または応答時間の目標値が必要、デッドロックの防止、最小スレッド数の保証が必要な場合、ワークマネージャを作成し、コンフィグレーションする
• グローバルレベルまたはアプリケーションレベルでワークマネージャをコンフィグレーションすることが出来る
• グローバルレベル• ドメイン内のアプリケーションまたはアプリケーションコンポーネントで使用可能
• 管理コンソールで定義することが可能
• アプリケーションレベル• 指定されたアプリケーションで使用可能
• weblogic-application.xml, weblogic-ejb-jar.xml, weblogic.xmlで定義
Copyright© 2011, Oracle. All rights reserved.39
グローバルレベルのワークマネージャの例
優先度の高い
アプリケーションB
優先度の低い
アプリケーションA
優先度を高く設定
優先度を低く設定
その他全ての
アプリケーション
default
ワークマネージャ
Copyright© 2011, Oracle. All rights reserved. 40
種類 要求事項 概要 Defaultワークマネージャー
制約 最大スレッド数制約 同時実行可能なスレッドの最大数を指定 -1(無制限)
最小スレッド数制約 実行用に最低限保証されるスレッド数を指定 0
容量制約 ワークマネージャーのキューに受け付けることができるリクエストの最大数(超えた場合はHTTP 503を返す)
-1(無制限)
要求クラス 応答時間要求クラス 必要な応答時間(msec)の指定からスレッド使用時間の割合(他の設定値との相対となる)を指定
設定なし
フェアシェア要求クラス 平均スレッド使用時間(他の設定値との相対となる)を指定 設定なし
コンテキスト要求クラス ユーザやグループと、応答時間要求クラスやフェアシェア要求クラスとを関連付ける
設定なし
• 独自のワークマネージャを作成し、実行優先順位をコンフィグレーションするために次のワークマネージャコンポーネントを使用する
ワークマネージャコンポーネント
Copyright© 2011, Oracle. All rights reserved.41
要求クラス
• 要求クラスはリクエストのスレッドの割り当てに使用するスケジュールガイドラインを表現する
• 応答時間要求クラス• 応答時間の目標値(ミリ秒単位)
• フェアシェア要求クラス• 要求の処理に必要な平均スレッド使用時間の相対値
• コンテキスト要求クラス• 現在のユーザやグループなどのコンテキスト情報
• 指定されたコンテキスト情報に基づいて、要求クラスを選択
Copyright© 2011, Oracle. All rights reserved.42
制約
• 制約• 要求を実行するために割り当てられるスレッドの最小数と最大数
• WebLogic Server が要求を拒否するまでにキューに入る要求の総数
• 最大スレッド数制約• 要求を実行する同時スレッド数の制限
• デフォルト値は -1 (無制限)
• データソースを指定して、データソースのサイズを制約に使用することも出来る
• 要求クラスによって設定されたフェアシェアや応答時間の達成を妨げる可能性がある
Copyright© 2011, Oracle. All rights reserved.43
制約
• 最小スレッド数制約• 要求に割り当てられるスレッド数の保証
• デフォルト値は0
• 容量制約• リクエスト数が指定した容量に達した場合に要求を拒否
• デフォルト値は -1 (無制限)
Copyright© 2011, Oracle. All rights reserved. 44
要求クラス設定例
• フェアシェア要求クラス
• アプリケーションAでフェアシェア要求クラス10を指定
• アプリケーションBでフェアシェア要求クラス20を指定
• アプリケーションCでフェアシェア要求クラス50を指定
• 上記の設定で、高負荷でリクエスト投入時、スレッドの割当比率が下記のようになる。• アプリケーションAのスレッドの割当比率は12.5% (10/80)
• アプリケーションBのスレッドの割当比率は25% (20/80)
• アプリケーションCのスレッドの割当比率は62.5% (50/80)
Copyright© 2011, Oracle. All rights reserved. 45
要求クラス設定例
• 応答時間要求クラス• アプリケーションAで応答時間要求クラス2000msecを指定
• アプリケーションBで応答時間要求クラス5000msecを指定
• 設定した時間の相対比率をベースにするため、応答時間が必ず設定通りにはならない
• 上記の設定で、高負荷でリクエスト投入時、アプリケーション実行時間が一定の場合
• アプリケーションAは、Bに対して2対5になるようにスレッドを割当
• アプリケーションBは、Aに対して5対2になるようにスレッドを割当
Copyright© 2011, Oracle. All rights reserved. 46
• 制約や要求クラスを個別に定義する。
• ワークマネージャーを定義し、定義した制約や要求クラスを割当てる。
• ワークマネージャーをWebLogicサーバまたはアプリケーションに割当てる。
ワークマネージャー
最大スレッド数制約
最小スレッド数制約
容量制約
要求クラス
WebLogic
サーバ
アプリケーション
それぞれ
設定可能
応答時間、
フェアシェア、
コンテキストの
いずれかを設定
ワークマネージャーの設定イメージ
Copyright© 2011, Oracle. All rights reserved.47
ワークマネージャの使用方法
• WebアプリケーションまたはEJBモジュールから定義済みのワークマネージャを使用するためにはデプロイメント記述子を使用する
• Webアプリケーションの場合
• weblogic.xml の wl-dispatch-policy タグを使用する
• EJBモジュールの場合
• weblogic-ejb-jar.xml の dispatch-policy タグを使用する
<weblogic-web-app>
<wl-dispatch-policy>ワークマネージャ名</wl-dispatch-policy>
</weblogic-web-app>
<weblogic-enterprise-bean>
<dispatch-policy>ワークマネージャ名</dispatch-policy>
</weblogic-enterprise-bean>
Copyright© 2011, Oracle. All rights reserved.48
実行キューの有効化
• ワークマネージャにはWebLogic Server 8.1 との下位互換性を有効にするために実行キューを使用することが出来る
• 全てのワークマネージャのコンフィグレーションとスレッドの自動チューニングは無効となる
• WebLogic Server 8.1 の実行キューと全く同じように動作する
• 有効化されたワークマネージャが実行キューに変換されて動作する
• 最小スレッド数制約または最大スレッド数制約が実装されている場合、実行キューはワークマネージャと同名で作成され、スレッド数も同じになる
• ワークマネージャで制約が適用されていない場合、デフォルト実行キューが使用される
・起動時のコマンドラインオプションの指定
-Dweblogic.Use81StyleExecuteQueues=true
Copyright© 2011, Oracle. All rights reserved.49
過負荷保護機能
• スレッドプール内の要求の制限
• HTTPセッションの制限
• メモリ不足例外のハンドリング
• スタックスレッドのハンドリング
Copyright© 2011, Oracle. All rights reserved.50
スレッドプール内の要求の制限
• キューの要求が最大数に達すると以下の要求が拒否される• Webアプリケーション要求
• フェアシェアが低い処理
• キューの長さはデフォルトで65536
Copyright© 2011, Oracle. All rights reserved.51
HTTPセッションの制限
• アクティブなHTTPセッションの制限を行うことが出来る
• 指定されたしきい値に達すると新たなセッションの作成要求が拒否される• クラスタの場合、SessionCreationException(実行時例外)が発生する
• この例外を捕捉し、HTTPコード503による応答を行う
• デプロイメント記述子(weblogic.xml)で制限を記述する
<session-descriptor>
<max-in-memory-sessions>100</max-in-memory-sessions>
</session-descriptor>
Copyright© 2011, Oracle. All rights reserved.52
メモリ不足例外、スタックスレッドの制御
• メモリ不足例外が発生した場合、サーバを自動的に停止するように設定可能
• アプリケーションスレッドのスタック
• 全てのアプリケーションスレッドがスタックしたときにサーバを自動的に停止することが可能
• 設定したしきい値以上のスレッド数がスタックした場合にも保護機能が実行される
Copyright© 2011, Oracle. All rights reserved.53
メモリ不足の検出
• 一定の時間間隔ごとに利用可能なメモリの残量をサンプリングすることで、WLSはメモリ不足を検出することができる
サーバ-コンフィグレーション-オーバーロード
サーバ-コンフィグレーション-チューニング
Copyright© 2011, Oracle. All rights reserved.54
パフォーマンスパックの使用
• サーバのパフォーマンスはソケットリーダスレッドに依存する
• WebLogic Serverには2種類のソケットリーダがある• ネイティブ—最高のパフォーマンスを提供する
• デフォルトで有効化されている
• ピュアJava—非効率的なソケットポーリングを利用せざるを得ない
• 十分な数のソケットリーダースレッドを割り当てるように実行スレッド数を大きくする
Copyright© 2011, Oracle. All rights reserved.55
パフォーマンスパックの設定
•「サーバ-コンフィグレーション」→「チューニング」
Copyright© 2011, Oracle. All rights reserved.56
接続バックログバッファの調整
• [バックログの受け入れ]属性を使って、TCP接続を待ちキューにバッファリング可能な個数を指定する
•「サーバ-コンフィグレーション」→「チューニング」
Copyright© 2011, Oracle. All rights reserved. 57
<Insert Picture Here>
JVMのチューニング- ヒープサイズの決定
- HotSpotのガベージ・コレクション- JRockitのガベージ・コレクション
Copyright© 2011, Oracle. All rights reserved.58
Java バーチャルマシンとヒープ
• Javaバーチャルマシン(JVM)のヒープは以下のものを含む• 現在使用されているオブジェクト
• 参照されていないオブジェクト
• 利用可能なフリーメモリ
• JVMはヒープ中のメモリが不足すると、ガベージコレクタによるメモリ解放処理(ガベージ・コレクション)が行なわれる• その間、JVMの動作が停止
• JVM起動時に指定するヒープサイズに関するパラメータ設定を適切に実施する必要がある
Copyright© 2011, Oracle. All rights reserved.59
Javaヒープ/ネイティブ領域のサイジング
• Java ヒープ• Java オブジェクトの割り当てられている領域
• 最大ヒープサイズは、サーバの起動時に java コマンドの -Xmx オプションで定義
• -Xmx -Xmsで指定、ヒープの拡張によるオーバーヘッドをなくすため 同じ値を設定
• ネイティブ メモリ• JVM で自身の内部操作に使用
• JNI コードやサードパーティ製のネイティブ モジュール (TYPE2 JDBC ドライバなど) でも使用
• 最大ネイティブ メモリ サイズは、次の要素で決定
• OSの仮想プロセスサイズの制限
• すでに Java ヒープに割り当てられているメモリの量
–Xms と –Xmxをオプションでヒープ容量の上限と下限を指定する
java –Xms1024m –Xmx1024m weblogic.Server
Copyright© 2011, Oracle. All rights reserved.60
WebLogic管理コンソールによるモニタリング
Copyright© 2011, Oracle. All rights reserved.61
ガベージ・コレクション
• 必要な空きメモリを確保するために、ガベージ・コレクションが行われる• Java は、明示的にオブジェクトを解放することが不可能である
• ガベージ・コレクション実行中は、CPUを長時間占有する場合がある• アプリケーションスレッドは待機される
• 最新の Java 仮想マシンは、多数のガベージ・コレクション方式を実装している
Copyright© 2011, Oracle. All rights reserved.62
HotSpot
• HotSpot とは、Sun の Java 仮想マシンである• HotSpot はWebLogic Serverを動作させるすべてのプラットフォームで利用可能である
• HotSpotには、2つのJVMが存在する• ClientVM:クライアント アプリケーション用に最適化されている(短命、軽量スレッドの利用)
• ServerVM : サーバアプリケーション用に最適化されている(長命、高度なマルチスレッドの利用)
• HotSpot は様々なガベージ・コレクションのアルゴリズムをサポートする
Copyright© 2011, Oracle. All rights reserved.63
世代別ガベージ・コレクション
• 世代別 GC は、ヒープを世代 もしくは ゾーンに分類する
• 新しいオブジェクトは、頻繁にガベージ・コレクションされる領域に作成される
• オブジェクトが、ガベージコレクタ サイクルによってメモリから解放されなかった場合、オブジェクトはより永続的な領域に移動されるEden Survivor
Young Tenured Permanent
Copyright© 2011, Oracle. All rights reserved.64
ガベージ・コレクション
• HotSpot では、4つの世代別ガベージ コレクタを指定できる• デフォルト コレクタ
• スループット コレクタ (–XX:+UseParalleleGC)
• 並行短停止時間コレクタ (-XX:+UseConcMarkSweepGC )
• インクリメンタル短停止時間コレクタ (-Xincgc)
Copyright© 2011, Oracle. All rights reserved.65
ガベージ・コレクション方式の選択
• ガベージ・コレクションの方式は求める要件にあわせて決定する• レスポンス重視
• スループット重視
レスポンス重視 スループット重視
Youngインクリメンタル短停止
コレクタスループットコレクタ
Tenured 並行短停止コレクタ デフォルトコレクタ
Copyright© 2011, Oracle. All rights reserved.66
ガベージ・コレクションのモニタリング
• ガベージ・コレクションの状況を出力するには、JVMオプションとして 「-verbose:gc」を指定する
Copyright© 2011, Oracle. All rights reserved.67
jconsoleを使ったJVMの監視
• jconsoleは J2SE付属のJMX に準拠した監視ツール
• jconsoleは提供されている主な機能• 概要タブ : JVM および監視される値の概要情報の表示
• メモリタブ : メモリ使用率に関する情報の表示
• スレッドタブ : スレッド使用率に関する情報の表示
• クラスタブ : クラスのロードに関する情報の表示
• MBeanタブ : MBeanに関する情報の表示
• VMタブ : JVMに関する情報の表示
Copyright© 2011, Oracle. All rights reserved.68
jconsoleの起動方法
• ローカルでの監視の実行• 起動時のパラメタに –Dcom.sun.management.jmxremoteを追加して、
WebLogic Server を起動する
• %JAVA_HOME%/bin/jconsole.exe を起動する
• jconsoleの接続ダイアログ-ローカルから監視するプロセスを選択
• リモートでの監視の実行• 起動時のパラメタに –Dcom.sun.management.jmxremote.port を追加して、ポート番号を指定して、WebLogic Server を起動する
• %JAVA_HOME%/bin/jconsole.exe を起動する
• jconsoleの接続ダイアログ-リモートから監視するホスト名、サーバ名、ユーザID、パスワードを指定する
Copyright© 2011, Oracle. All rights reserved.69
JRockitチューニングのポイント
• GCは常に行うという前提で、GCによる処理停止の影響を抑えるよう設計されている。
• チューニングのポイント
• GCモードの選択
• ヒープのサイジング
Copyright© 2011, Oracle. All rights reserved.70
動作状況の変化に柔軟に対応
動的GC 静的GC
動作が固定なのでチューニングが簡単
判定切り替えコストが掛からない
オブジェクトの移動コストが低い
オブジェクト寿命の変化に強い
シングルスペースGC 世代別GC
毎回プロモーションが発生
短寿命オブジェクトが多い場合に高速
停止時間が理論上最小になる
コンカレントGC パラレルGC
理論上最も効率的にGCを実行する
GCモードの選択
Copyright© 2011, Oracle. All rights reserved.71
ヒープのサイジング
• 最大/最小ヒープ値(-Xmx<size> -Xms<size>)
• ヒープの拡張によるオーバーヘッドをなくすため同じ値を設定
• 大きなサイズを指定がBetter、しかしGCに取られる時間は増加
• Long Lived Objectsのサイズの3倍程度がベストプラクティス
New GC Old GCHeap Size
Long Lived Objects Size
Copyright© 2011, Oracle. All rights reserved. 73
OTNセミナー オンデマンド コンテンツダイセミで実施された技術コンテンツを動画で配信中!!
ダイセミのライブ感はそのままに、お好きな時間で受講頂けます。
※掲載のコンテンツ内容は予告なく変更になる可能性があります。
期間限定での配信コンテンツも含まれております。お早めにダウンロード頂くことをお勧めいたします。
OTN オンデマンド
最新情報つぶやき中
OracleMiddle_jp・セミナ情報
・お勧め情報
・公開予告 など
Copyright© 2011, Oracle. All rights reserved. 74
Oracle エンジニアのための技術情報サイト
オラクルエンジニア通信http://blogs.oracle.com/oracle4engineer/
• 技術資料
• ダイセミの過去資料や製品ホワイトペーパー、スキルアップ資料などを多様な方法で検索できます
• キーワード検索、レベル別、カテゴリ別、製品・機能別
• コラム
• オラクル製品に関する技術コラムを毎週お届けします
• 決してニッチではなく、誰もが明日から使える技術の「あ、そうだったんだ!」をお届けします
こんな資料が人気です
6か月ぶりに資料ダウンロードランキングの首位が交代!新王者はOracle Database構築資料でした。
データベースの性能管理手法について、Statspack派もEnterprise Manager派も目からウロコの技術特集公開中
オラクルエンジニア通信
最新情報つぶやき中
oracletechnetjp
Copyright© 2011, Oracle. All rights reserved. 75
OTN×ダイセミ でスキルアップ!!
※OTN掲示版は、基本的にOracleユーザー有志からの回答となるため100%回答があるとは限りません。
ただ、過去の履歴を見ると、質問の大多数に関してなんらかの回答が書き込まれております。
Oracle Technology Network(OTN)を御活用下さい。
・一般的な技術問題解決方法などを知りたい!
・セミナ資料など技術コンテンツがほしい!
一般的技術問題解決にはOTN掲示版の
「ミドルウェア」をご活用ください
http://forums.oracle.com/forums/main.jspa?categoryID=484
過去のセミナ資料、動画コンテンツはOTNの
「OTNセミナー オンデマンド コンテンツ」へ
http://www.oracle.com/technetwork/jp/testcontent/index-086873-ja.html
※ダイセミ事務局にダイセミ資料を請求頂いても、お受けできない可能性がございますので予めご了承ください。
ダイセミ資料はOTNコンテンツ オン デマンドか、セミナ実施時間内にダウンロード頂くようお願い致します。
Copyright© 2011, Oracle. All rights reserved. 76
■パフォーマンス診断サービス
•Webシステム ボトルネック診断サービス
•データベースパフォーマンス診断サービス
オラクル社のエンジニアが 直接ご支援しますお気軽にご活用ください!
オラクル 無償支援 検索
NEW
■システム構成診断サービス
•Oracle Database構成相談サービス
•サーバー統合支援サービス
•仮想化アセスメントサービス
•メインフレーム資産活用相談サービス
•BI EEアセスメントサービス
•簡易業務診断サービス
■バージョンアップ支援サービス
•Oracle Databaseバージョンアップ支援サービス
•Weblogic Serverバージョンアップ支援サービス
•Oracle Developer/2000(Froms/Reports)
Webアップグレード相談サービス
■移行支援サービス
•SQL Serverからの移行支援サービス
•DB2からの移行支援サービス
•Sybaseからの移行支援サービス
•MySQLからの移行支援サービス
•Postgre SQLからの移行支援サービス
•Accessからの移行支援サービス
•Oracle Application ServerからWeblogicへ移行支援サービス
ITプロジェクト全般に渡る無償支援サービス
Oracle Direct Conciergeサービス
NEW
NEW
Copyright© 2011, Oracle. All rights reserved. 77
インストールすることなく、すぐに体験いただけます
製品無償評価サービス
http://www.oracle.com/jp/direct/services/didemo-195748-ja.html
Web問い合わせフォーム「ダイデモ」をキーワードに検索することで申し込みホームページにアクセスできます
提供シナリオ一例
・データベースチューニング
・アプリケーション性能・負荷検証
・無停止アップグレード
・Webシステム障害解析
1日5組限定!
※サービスご提供には事前予約が必要です
• サービスご提供までの流れ
1. お問合せフォームより「製品評価サービス希望」と必要事項を明記し送信下さい
2. 弊社より接続方法手順書およびハンズオン手順書を送付致します
3. 当日は、弊社サーバー環境でインターネット越しに製品を体感頂けます
Copyright© 2011, Oracle. All rights reserved.
http://www.oracle.com/jp/direct/inquiry-form-182185-ja.html
Oracle Direct 検索
あなたにいちばん近いオラクル
Oracle Directまずはお問合せください
Web問い合わせフォーム フリーダイヤル
専用お問い合わせフォームにてご相談内容を承ります。
※こちらから詳細確認のお電話を差し上げる場合がありますので、ご登録されている連絡先が最新のものになっているか、ご確認下さい。
0120-155-096
※月曜~金曜 9:00~12:00、13:00~18:00
(祝日および年末年始除く)
システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。
システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。
Copyright© 2011, Oracle. All rights reserved.
Copyright© 2011, Oracle. All rights reserved. 80