WebLogic Server 11g - パフォーマンス・チューニング

6,609 views

Published on

Java EE環境/Java EEアプリケーション/Java EEサービス/WebLogic Server/JVM
におけるチューニング・ポイント

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,609
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
99
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

WebLogic Server 11g - パフォーマンス・チューニング

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

×