Slide 1

Transcription

1 <Insert Picture Here> Oracle WebLogic Server パフォーマンス チューニング 日本オラクル株式会社 Fusion Middleware 事業統括本部ソリューション本部 Application Grid ソリューション部

2 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社 関連会社の米国及びその他の国における登録商標です 文中の社名 商品名等は各社の商標または登録商標である場合があります 2

3 Agenda パフォーマンス チューニング概要 Java EE 環境におけるチューニング ポイント Java EEアプリケーションのチューニング Java EEサービスのチューニング WebLogic Serverのチューニング JVMのチューニング 3

4 <Insert Picture Here> パフォーマンス チューニング概要 4

5 前提条件と要件 ( 目標 ) の設定 システムの 性能 を考える場合 前提条件と要件を明確にする 対象アプリケーション 最大ユーザ数 時間当たりの要求数 リクエストのデータ量 レスポンスのデータ量 内部処理 (DBからのデータ取得や書き込み等) のデータ量 性能要件 WebブラウザでSubmitしてから画面表示終了まで3 秒以内 2 時間以内に 5000 万件のデータに対する処理を完了させること 5

6 性能が問題になった場合 原則 ボトルネックを見出すことが解決策 ボトルネックの調査には JRockit Flight Recorder が有用 (WebLogic 以降 ) JVM を JRockit にしてフライト記録を取り続ける運用にする チューニングで対応できるのであればよいが 下記のように想定外の要因の場合は 根本的なシステム構成の見直しが必要になる 想定より多くのユーザがアクセスしている 想定よりも膨大なデータを処理している CPU はほぼ 100% 使い切っている そのリスクを削減するには 性能面で拡張できる構成を検討しておくべき または リクエスト制限を行う仕組みを検討しておくべき H/W や S/W のチューニングで対応できるか否かの 見極めが重要 6

7 チューニングの余地があると思われる事象 DB 扱うデータ量が多いわけでもないのに特定の SQL が遅い Disk I/O に時間がかかっているが CPU 使用率が高いわけではない DB 側で内部処理でロックによる待機イベントが発生している Web アプリケーション サーバ (Java EE) 特定のアプリの特定の処理時間だけが遅い フルガベージ コレクションが頻繁に発生している CPU 使用率が高いわけではないのにレスポンスタイムが悪い 7

8 アプリケーションの変更を要する場合 Java のコーディング一般的によく言われる基本事項 文字列連結では String オブジェクトと + 演算子を使わず StringBuffer オブジェクトの append メソッドを利用せよ Collection オブジェクトのサイズは生成時に指定して動的拡張しないようにせよ 不要になったオブジェクトリファレンスには null を代入せよ しかし性能問題発生時には 上記のような基本事項を修正して問題が解決するケースは稀 プログラムの構造的な見直しを要する場面 JDBC で SQL 実行によりデータを取得するのではなく キャッシュからデータを取得する 8

9 <Insert Picture Here> Java EE 環境におけるチューニング ポイント 9

10 Java EE サーバ環境のチューニング レイヤ WebLogicでは WebLogicでは ApacheやIISなど WebLogic 管理対象サーバ ネットワーク Java EE コンテナ Web コンテナ EJB コンテナ JDBC Web サーバ OS H/W JavaVM OS H/W WebLogic では Web サーバプラグイン WebLogic では JRockit など 10

11 Java EE 環境おけるレイヤ別着眼点 HttpSession に大量のオブジェクトを長時間保持させてい JavaScript 処理に負荷がかかっていないか? リクエストの受け付け窓口の数は適切か? 窓口数を増加させた場合の CPU やメモリ負荷は問題無いか? ないか? オブジェクトの解放漏れはないか? オブジェクト生成ロジックに無駄が無いか? データベースへのコネクション プーリングの数は適切か? Web ブラウザ HTTP Web サーバ アプリ Java EE コンテナ JDBC データベース JVM リクエストの受け付け窓口の数は適切か? 窓口数を増加させた場合の CPU やメモリ負荷は問題無いか? ヒープメモリ設定は適切か? ヒープメモリを増減した場合の CPU メモリの負荷と GC の頻度と時間は? SQL 処理に時間がかかっていないか?( 特に 解析 I/O 系処理に ) 11

12 Java EE における性能面での留意事項 1 AP サーバが使用する JDK は許容される限り最新のものを使用する 例 :JDK1.5.0_06 よりは JDK1.5.0_16 を JDK は 提供ベンダーやバージョンにより GC の動作やヒープ構造 オプション指定が異なる HttpSession オブジェクトのサイズやライフサイクルに注意する HttpSession オブジェクトに格納する Object は最低限にする ログアウト処理などで不要になるオブジェクトは明示的に破棄する タイムアウトを無制限にしない Servlet では SingleThreadModel インターフェースを実装しない ( 基本的に ) リクエスト毎に Servlet インスタンスを生成してしまう AP サーバにより実装が異なる場合がある Servlet 2.4 API 仕様では非推奨 12

13 Java EE における性能面での留意事項 2 DB 接続では AP サーバが提供するデータソース (javax.sql.datasource) を利用し 接続プールを利用する 接続プールより取得した java.sql.connection オブジェクトは JDBC 処理が終了後必ず close( ) メソッドで解放する 正常終了 / 異常終了にかかわらず必ず finally 句で close () を実行する 接続プールで保持する接続数の初期容量と最大容量を同じにしておく SQL は同一で条件値のみ変化する処理を繰り返す場合は java.sql.preparedstatement を使用する 13

14 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) {} } 14

15 PreparedStatement の利用 PreparedStatement 使用時は DB 側の解析処理が減るため性能向上が期待できます Statement 使用時 PreparedStatement 使用時 Statement stmt = conn.createstatement(); for ( int id = 0 ; id < ; 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 < ; id++ ) { ps.setint(1,id); ResultSet rs = ps.executequery(); while ( rs.next() ) { // 表示などの処理 } } 15

16 WebLogic チューニング WebLogic のチューニングについて 以降の章では下記の観点で説明します Java EE アプリケーションのチューニング Java EE サービスのチューニング WebLogic Server のチューニング JVM のチューニング Java EE アプリケーション Web ブラウザ HTTP Web サーバ Web Logic JDBC データベース JVM 16

17 <Insert Picture Here> Java EE アプリケーションのチューニング - JSP, Servlet - EJB 17

18 JSP1 JSP の再変換と再コンパイルのチェック間隔の指定 Web アプリケーションの weblogic.xml で下記を指定 <jsp-descriptor> の page-check-seconds で秒指定 WebLogic の動作モードが 開発 の場合はデフォルトで 1 秒単位でチェック WebLogic の動作モードが プロダクション の場合はデフォルトではチェック無し (-1 を指定 ) プロダクション モードで運用中に JSP の変更がない場合はチェック無し (-1) でよい プロダクション モードで運用中に JSP の変更頻度が高くない場合は 60 以上に設定 管理コンソールでは Web アプリケーション管理画面の コンフィグレーション タブ画面で設定 クライアント JSP 変更のチェック Java WebLogic 2 回目以降 ファイル 変換 ソース コンパイル Servlet ロード Java クラス 18

19 JSP2 JSP のプリコンパイルの指定 Web アプリケーションの weblogic.xml で下記を指定 <jsp-descriptor> の precompile と precompile-continue に true を設定する デフォルトは false クライアントからアクセス時の変換 コンパイルのオーバーヘッドは排除できるが WebLogic の起動時間やアプリのデプロイ時間は長くなる可能性がある 管理コンソールでは Web アプリケーション管理画面の コンフィグレーション タブ画面で設定 クライアント WebLogic 起動時やアプリの 再デプロイに変更分をコンパイル JSP ファイル 変換 Java ソース コンパイル WebLogic Servlet ロード Java クラス 19

20 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> 20

21 Fast Swap クラスのリロードチェック間隔の指定 ヒープにロードされているインスタンスが常時最新になるようにクラスファイルをチェックする間隔 Web アプリケーションの weblogic.xml で下記を指定 <fast-swap> に秒指定する WebLogic の動作モードが 開発 の場合のみ クライアント Servlet クラス ロード 変更のチェック WebLogic Servlet 21

22 リロード間隔の指定例 チェック間隔を 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> 22

23 EJB1 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> 要素 クライアント Web App Stateless Session Bean Stateless Session Bean Stateless WebLogic Session Bean 23

24 EJB2 Stateful Session Bean のメモリキャッシュの指定 Stateful Session Bean のインスタンスをメモリに保持させる 1 つの Stateful Session Bean への同時アクセス数を指定するのがのぞましい EJB アプリケーションの weblogic-ejb-jar.xml で下記を指定 <stateful-session-descriptor><stateful-session-cache> に maxbeans-in-cache デフォルト値は 1000 クライアント Web App Stateful Session Bean Stateful Session Bean Stateful Session Bean WebLogic Passivate Stateful Session Bean Disk 24

25 EJB3 引数の値渡し 参照渡しの指定 WebLogic8.1 以降のバージョンはデフォルトは値渡し EJB クライアントと EJB が同一アプリケーションの場合は Local インターフェースの EJB を使用するか または明示的に参照渡しにすることでパフォーマンス向上が期待できる ただし 使用するアプリケーションが値渡しを前提としたセマンティクスになっていないことが要件となる weblogic-ejb-jar.xml の <weblogic-enterprise-bean> で enable-call-by-reference で true 指定すると参照渡しになる 値渡し (call by value) EJB の引数に Object のコピーを生成して渡す 参照渡し (call by reference) EJB の引数に Object の Reference を渡す EJB EJB Client EJB EJB Client Object Object Object 25

26 <Insert Picture Here> Java EE サービスのチューニング - JDBC - JTA - JMS 26

27 接続プールの最適化 アプリケーションの実行中に新しい接続の生成が発生しないように調整しておくことが望ましい 初期容量 = 最大容量 通常は実行スレッド数よりも多くの接続を使わないように設定する 27

28 Statement キャッシュの利用 JDBC データソースの Statement キャッシュサイズで指定した個数に到達するまで WLS はアプリケーション EJB で使われる PreparedStatement オブジェクト CallableStatement オブジェクトをキャッシュし 次回から同じステートメントの実行時に再利用する キャッシュを再利用することでデータベースサーバ側の CPU 使用率が下がるため CPU サイクルを他のタスクに割り当てることが可能となる 28

29 Pinned-To-Thread プロパティの利用 データソースで [ スレッドに固定 ] を有効化すると アプリケーションがデータベース接続の予約に要する時間を最小化できる アプリケーションが接続をクローズしても 実行スレッドが接続オブジェクトを保持し続ける ( データソースには返却しない ) 接続予約を試行する複数のスレッド間での競合を削減できる 29

30 トランザクションとパフォーマンス トランザクションのタイムアウト値はデフォルトでは 30 秒 通常のトランザクションは数秒の間にコミットかロールバックをする トランザクションの使用に対するアドバイス 性能を向上するためには トランザクションの時間を短く保つこと 必要な場合のみトランザクションを使用するようにする 2フェーズコミットはできる限り発生しないようにするにする 30

31 JMS 送り先のパフォーマンスオプション メッセージをバッチでコンシューマに送信することで パフォーマンスを調整することが出来る JMS 送り先にはメッセージのバッチが作成されるまで送信を待機し コンシューマにまとめてメッセージを送信する機能が備わっている JMS 送り先の メッセージングパフォーマンスのチューニング オプションを使用する 複数まとめて送信するため 待ち時間が長くなるが 送出回数が少なくなるため サーバ全体のスループットが向上する 31

32 <Insert Picture Here> WebLogic Server のチューニング - ワークマネージャ - 過負荷管理 - パフォーマンスパック 32

33 WLS9.x より前のスレッド管理 手動でスレッドプールサイズを調整する必要があった スレッド数 キューの長さ しきい値 最大スレッド数 スレッドの優先順位 負荷の高い作業に対して複数の実行キューを使用 33

34 WLS9.x より前のスレッド管理 リクエスト 複数の実行キューと実行スレッドプール スレッドチューニングは手動 リッスンポート Default キュー マルチ プレクサ キュー 実行キュー カスタムキュー 実行スレッドプール 実行スレッド バックログ 実行キュー 実行スレッドプール リッスンスレッドにより運ばれる何らかの理由でリクエストが処理できない場合のバッファ ソケットリーダ スレッドにより 運ばれる 実行スレッド 内部管理キューにもスレッドプールが存在 34

35 ワークマネージャの利用 WebLogic Server 9.x ではワークマネージャを使ってスレッドの管理を行う 自動的にスレッド数が必要に応じて調整される アプリケーションの実行優先順位をコンフィグレーションする 管理者によるパラメタの定義 実行時メトリクス リクエストを実行するためにかかった実際の時間 デフォルトワークマネージャ アプリケーションがユーザ定義のワークマネージャに割り当てられていないときに使用される 全てのアプリケーションが同等の優先順位を持つ それぞれのアプリケーションのスレッド割り当てが均等に行われる "default" という名前のワークマネージャを定義することでデフォルトワークマネージャの値をカスタマイズすることが出来る 35

36 WebLogic 9.x 以降のスレッド管理イメージ 単一の実行スレッドプール スレッドプール数は自動チューニング ワークマネージャー ( スレッド制御ポリシーをもったキュー ) により アプリケーションの実行優先制御が可能に リクエスト リッスンポートワークマネージャーサブシステム実行スレッドプールマルチ プレクサ 実行スレッド ワークマネージャー アプリケーション A バックログ リッスンスレッドにより運ばれる何らかの理由でリクエストが処理できない場合のバッファ ソケットリーダ スレッドにより 運ばれる ワークマネージャー アプリケーション B アプリケーション C 36

37 ワークマネージャのスコープ デフォルトのワークマネージャ 多くの場合 ほとんどのアプリケーションの要求を満たす デフォルトの割り当てが不十分な場合 または応答時間の目標値が必要 デッドロックの防止 最小スレッド数の保証が必要な場合 ワークマネージャを作成し コンフィグレーションする グローバルレベルまたはアプリケーションレベルでワークマネージャをコンフィグレーションすることが出来る グローバルレベル ドメイン内のアプリケーションまたはアプリケーションコンポーネントで使用可能 管理コンソールで定義することが可能 アプリケーションレベル 指定されたアプリケーションで使用可能 weblogic-application.xml, weblogic-ejb-jar.xml, weblogic.xml で定義 37

38 グローバルレベルのワークマネージャの例 優先度を高く設定 優先度を低く設定 default その他全ての ワークマネージャ 優先度の低い 優先度の高い アプリケーション アプリケーション A アプリケーション B 38

39 ワークマネージャコンポーネント 独自のワークマネージャを作成し 実行優先順位をコンフィグレーションするために次のワークマネージャコンポーネントを使用する 種類要求事項概要 Default ワークマネージャー 制約最大スレッド数制約同時実行可能なスレッドの最大数を指定 -1( 無制限 ) 最小スレッド数制約実行用に最低限保証されるスレッド数を指定 0 容量制約 ワークマネージャーのキューに受け付けることができるリクエストの最大数 ( 超えた場合は HTTP 503 を返す ) -1( 無制限 ) 要求クラス 応答時間要求クラス 必要な応答時間 (msec) の指定からスレッド使用時間の割合 ( 他の設定値との相対となる ) を指定 設定なし フェアシェア要求クラス平均スレッド使用時間 ( 他の設定値との相対となる ) を指定設定なし コンテキスト要求クラス ユーザやグループと 応答時間要求クラスやフェアシェア要求クラスとを関連付ける 設定なし 39

40 要求クラス 要求クラスはリクエストのスレッドの割り当てに使用するスケジュールガイドラインを表現する 応答時間要求クラス 応答時間の目標値 ( ミリ秒単位 ) フェアシェア要求クラス 要求の処理に必要な平均スレッド使用時間の相対値 コンテキスト要求クラス 現在のユーザやグループなどのコンテキスト情報 指定されたコンテキスト情報に基づいて 要求クラスを選択 40

41 制約 制約 要求を実行するために割り当てられるスレッドの最小数と最大数 WebLogic Server が要求を拒否するまでにキューに入る要求の総数 最大スレッド数制約 要求を実行する同時スレッド数の制限 デフォルト値は -1 ( 無制限 ) データソースを指定して データソースのサイズを制約に使用することも出来る 要求クラスによって設定されたフェアシェアや応答時間の達成を妨げる可能性がある 41

42 制約 最小スレッド数制約 要求に割り当てられるスレッド数の保証 デフォルト値は0 容量制約 リクエスト数が指定した容量に達した場合に要求を拒否 デフォルト値は -1 ( 無制限 ) 42

43 要求クラス設定例 フェアシェア要求クラス アプリケーション A でフェアシェア要求クラス 10 を指定 アプリケーション B でフェアシェア要求クラス 20 を指定 アプリケーション C でフェアシェア要求クラス 50 を指定 上記の設定で 高負荷でリクエスト投入時 スレッドの割当比率が下記のようになる アプリケーション A のスレッドの割当比率は 12.5% (10/80) アプリケーション B のスレッドの割当比率は 25% (20/80) アプリケーション C のスレッドの割当比率は 62.5% (50/80) 43

44 要求クラス設定例 応答時間要求クラス アプリケーション A で応答時間要求クラス 2000msec を指定 アプリケーション B で応答時間要求クラス 5000msec を指定 設定した時間の相対比率をベースにするため 応答時間が必ず設定通りにはならない 上記の設定で 高負荷でリクエスト投入時 アプリケーション実行時間が一定の場合 アプリケーション A は B に対して 2 対 5 になるようにスレッドを割当 アプリケーション B は A に対して 5 対 2 になるようにスレッドを割当 44

45 ワークマネージャーの設定イメージ 制約や要求クラスを個別に定義する ワークマネージャーを定義し 定義した制約や要求クラスを割当てる ワークマネージャーを WebLogic サーバまたはアプリケーションに割当てる それぞれ 設定可能 ワークマネージャー最大スレッド数制約最小スレッド数制約容量制約 WebLogic サーバ 応答時間 フェアシェア コンテキストのいずれかを設定 要求クラス アプリケーション 45

46 ワークマネージャの使用方法 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> 46

47 実行キューの有効化 ワークマネージャには WebLogic Server 8.1 との下位互換性を有効にするために実行キューを使用することが出来る 全てのワークマネージャのコンフィグレーションとスレッドの自動チューニングは無効となる WebLogic Server 8.1 の実行キューと全く同じように動作する 有効化されたワークマネージャが実行キューに変換されて動作する 最小スレッド数制約または最大スレッド数制約が実装されている場合 実行キューはワークマネージャと同名で作成され スレッド数も同じになる ワークマネージャで制約が適用されていない場合 デフォルト実行キューが使用される 起動時のコマンドラインオプションの指定 -Dweblogic.Use81StyleExecuteQueues=true 47

48 過負荷保護機能 スレッドプール内の要求の制限 HTTPセッションの制限 メモリ不足例外のハンドリング スタックスレッドのハンドリング 48

49 スレッドプール内の要求の制限 キューの要求が最大数に達すると以下の要求が拒否される Web アプリケーション要求 フェアシェアが低い処理 キューの長さはデフォルトで

50 HTTP セッションの制限 アクティブな HTTP セッションの制限を行うことが出来る 指定されたしきい値に達すると新たなセッションの作成要求が拒否される クラスタの場合 SessionCreationException( 実行時例外 ) が発生する この例外を捕捉し HTTP コード 503 による応答を行う デプロイメント記述子 (weblogic.xml) で制限を記述する <session-descriptor> <max-in-memory-sessions>100</max-in-memory-sessions> </session-descriptor> 50

51 メモリ不足例外 スタックスレッドの制御 メモリ不足例外が発生した場合 サーバを自動的に停止するように設定可能 アプリケーションスレッドのスタック 全てのアプリケーションスレッドがスタックしたときにサーバを自動的に停止することが可能 設定したしきい値以上のスレッド数がスタックした場合にも保護機能が実行される 51

52 メモリ不足の検出 一定の時間間隔ごとに利用可能なメモリの残量をサンプリングすることで WLS はメモリ不足を検出することができる サーバ - コンフィグレーション - オーバーロード サーバ - コンフィグレーション - チューニング 52

53 パフォーマンスパックの使用 サーバのパフォーマンスはソケットリーダスレッドに依存する WebLogic Server には 2 種類のソケットリーダがある ネイティブ 最高のパフォーマンスを提供する デフォルトで有効化されている ピュア Java 非効率的なソケットポーリングを利用せざるを得ない 十分な数のソケットリーダースレッドを割り当てるように実行スレッド数を大きくする 53

54 パフォーマンスパックの設定 サーバ - コンフィグレーション チューニング 54

55 接続バックログバッファの調整 [ バックログの受け入れ ] 属性を使って TCP 接続を待ちキューにバッファリング可能な個数を指定する サーバ - コンフィグレーション チューニング 55

56 <Insert Picture Here> JVM のチューニング - ヒープサイズの決定 - HotSpot のガベージ コレクション - JRockit のガベージ コレクション 56

57 Java バーチャルマシンとヒープ Java バーチャルマシン (JVM) のヒープは以下のものを含む 現在使用されているオブジェクト 参照されていないオブジェクト 利用可能なフリーメモリ JVM はヒープ中のメモリが不足すると ガベージコレクタによるメモリ解放処理 ( ガベージ コレクション ) が行なわれる その間 JVM の動作が停止 JVM 起動時に指定するヒープサイズに関するパラメータ設定を適切に実施する必要がある 57

58 Java ヒープ / ネイティブ領域のサイジング Java ヒープ Java オブジェクトの割り当てられている領域 最大ヒープサイズは サーバの起動時に java コマンドの -Xmx オプションで定義 -Xmx -Xms で指定 ヒープの拡張によるオーバーヘッドをなくすため同じ値を設定 Xms と Xmx をオプションでヒープ容量の上限と下限を指定する java Xms1024m Xmx1024m weblogic.server ネイティブメモリ JVM で自身の内部操作に使用 JNI コードやサードパーティ製のネイティブモジュール (TYPE2 JDBC ドライバなど ) でも使用 最大ネイティブメモリサイズは 次の要素で決定 OS の仮想プロセスサイズの制限 すでに Java ヒープに割り当てられているメモリの量 58

59 WebLogic 管理コンソールによるモニタリング 59

60 ガベージ コレクション 必要な空きメモリを確保するために ガベージ コレクションが行われる Java は 明示的にオブジェクトを解放することが不可能である ガベージ コレクション実行中は CPU を長時間占有する場合がある アプリケーションスレッドは待機される 最新の Java 仮想マシンは 多数のガベージ コレクション方式を実装している 60

61 HotSpot HotSpot とは Sun の Java 仮想マシンである HotSpot は WebLogic Server を動作させるすべてのプラットフォームで利用可能である HotSpot には 2 つの JVM が存在する ClientVM: クライアントアプリケーション用に最適化されている ( 短命 軽量スレッドの利用 ) ServerVM : サーバアプリケーション用に最適化されている ( 長命 高度なマルチスレッドの利用 ) HotSpot は様々なガベージ コレクションのアルゴリズムをサポートする 61

62 世代別ガベージ コレクション 世代別 GC は ヒープを世代もしくはゾーンに分類する 新しいオブジェクトは 頻繁にガベージ コレクションされる領域に作成される オブジェクトが ガベージコレクタサイクルによってメモリから解放されなかった場合 オブジェクトはより永続的な領域に移動される Eden Survivor Young Tenured Permanent 62

63 ガベージ コレクション HotSpot では 4 つの世代別ガベージコレクタを指定できる デフォルトコレクタ スループットコレクタ ( XX:+UseParalleleGC) 並行短停止時間コレクタ (-XX:+UseConcMarkSweepGC ) インクリメンタル短停止時間コレクタ (-Xincgc) 63

64 ガベージ コレクション方式の選択 ガベージ コレクションの方式は求める要件にあわせて決定する レスポンス重視 スループット重視 レスポンス重視 スループット重視 Young インクリメンタル短停止コレクタ スループットコレクタ Tenured 並行短停止コレクタデフォルトコレクタ 64

65 ガベージ コレクションのモニタリング ガベージ コレクションの状況を出力するには JVMオプションとして -verbose:gc を指定する 65

66 jconsole を使った JVM の監視 jconsole は J2SE 付属のJMX に準拠した監視ツール jconsole は提供されている主な機能 概要タブ : JVM および監視される値の概要情報の表示 メモリタブ : メモリ使用率に関する情報の表示 スレッドタブ : スレッド使用率に関する情報の表示 クラスタブ : クラスのロードに関する情報の表示 MBeanタブ : MBean に関する情報の表示 VMタブ : JVMに関する情報の表示 66

67 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 パスワードを指定する 67

68 JRockit チューニングのポイント GC は常に行うという前提で GC による処理停止の影響を抑えるよう設計されている チューニングのポイント GC モードの選択 ヒープのサイジング 68

69 GC モードの選択 動的 GC 動作状況の変化に柔軟に対応 静的 GC 動作が固定なのでチューニングが簡単 判定切り替えコストが掛からない シングルスペース GC 世代別 GC オブジェクトの移動コストが低い オブジェクト寿命の変化に強い 毎回プロモーションが発生 短寿命オブジェクトが多い場合に高速 コンカレント GC パラレル GC 停止時間が理論上最小になる 理論上最も効率的に GC を実行する 69

70 ヒープのサイジング 最大 / 最小ヒープ値 (-Xmx<size> -Xms<size>) ヒープの拡張によるオーバーヘッドをなくすため同じ値を設定 大きなサイズを指定がBetter しかしGCに取られる時間は増加 Long Lived Objectsのサイズの3 倍程度がベストプラクティス Heap Size New GC Old GC Long Lived Objects Size 70

71 OTN セミナーオンデマンドコンテンツダイセミで実施された技術コンテンツを動画で配信中!! ダイセミのライブ感はそのままに お好きな時間で受講頂けます 最新情報つぶやき中 OracleMiddle_jp セミナ情報 お勧め情報 公開予告 など OTN オンデマンド 掲載のコンテンツ内容は予告なく変更になる可能性があります 期間限定での配信コンテンツも含まれております お早めにダウンロード頂くことをお勧めいたします 72

72 Oracle エンジニアのための技術情報サイトオラクルエンジニア通信 最新情報つぶやき中 oracletechnetjp 技術資料 ダイセミの過去資料や製品ホワイトペーパー スキルアップ資料などを多様な方法で検索できます キーワード検索 レベル別 カテゴリ別 製品 機能別 コラム オラクル製品に関する技術コラムを毎週お届けします 決してニッチではなく 誰もが明日から使える技術の あ そうだったんだ! をお届けします オラクルエンジニア通信 こんな資料が人気です 6か月ぶりに資料ダウンロードランキングの首位が交代! 新王者はOracle Database 構築資料でした データベースの性能管理手法について Statspack 派も Enterprise Manager 派も目からウロコの技術特集公開中 73

73 OTN ダイセミでスキルアップ!! 一般的な技術問題解決方法などを知りたい! セミナ資料など技術コンテンツがほしい! Oracle Technology Network(OTN) を御活用下さい 一般的技術問題解決にはOTN 掲示版の ミドルウェア をご活用ください OTN 掲示版は 基本的に Oracle ユーザー有志からの回答となるため 100% 回答があるとは限りません ただ 過去の履歴を見ると 質問の大多数に関してなんらかの回答が書き込まれております 過去のセミナ資料 動画コンテンツは OTN の OTN セミナーオンデマンドコンテンツ へ ダイセミ事務局にダイセミ資料を請求頂いても お受けできない可能性がございますので予めご了承ください ダイセミ資料はOTNコンテンツオンデマンドか セミナ実施時間内にダウンロード頂くようお願い致します 74

74 IT プロジェクト全般に渡る無償支援サービス パフォーマンス診断サービス Web システムボトルネック診断サービス データベースパフォーマンス診断サービス 移行支援サービス SQL Server からの移行支援サービス DB2 からの移行支援サービス Sybase からの移行支援サービス MySQL からの移行支援サービス Postgre SQL からの移行支援サービス Access からの移行支援サービス Oracle Application ServerからWeblogicへ移行支援サービス NEW Oracle Direct Concierge サービス NEW システム構成診断サービス Oracle Database 構成相談サービス サーバー統合支援サービス 仮想化アセスメントサービス メインフレーム資産活用相談サービス BI EE アセスメントサービス 簡易業務診断サービス バージョンアップ支援サービス Oracle Database バージョンアップ支援サービス Weblogic Server バージョンアップ支援サービス Oracle Developer/2000(Froms/Reports) Web アップグレード相談サービス NEW オラクル社のエンジニアが直接ご支援しますお気軽にご活用ください! オラクル無償支援 検索 75

75 1 日 5 組限定! 製品無償評価サービス 提供シナリオ一例 データベースチューニング 無停止アップグレード アプリケーション性能 負荷検証 Webシステム障害解析 インストールすることなく すぐに体験いただけます サービスご提供までの流れ 1. お問合せフォームより 製品評価サービス希望 と必要事項を明記し送信下さい 2. 弊社より接続方法手順書およびハンズオン手順書を送付致します 3. 当日は 弊社サーバー環境でインターネット越しに製品を体感頂けます Web 問い合わせフォーム サービスご提供には事前予約が必要です ダイデモ をキーワードに検索することで申し込みホームページにアクセスできます 76

76 あなたにいちばん近いオラクル Oracle Direct まずはお問合せください Oracle Direct 検索 システムの検討 構築から運用まで ITプロジェクト全般の相談窓口としてご支援いたします システム構成やライセンス / 購入方法などお気軽にお問い合わせ下さい Web 問い合わせフォームフリーダイヤル 専用お問い合わせフォームにてご相談内容を承ります こちらから詳細確認のお電話を差し上げる場合がありますので ご登録されている連絡先が最新のものになっているか ご確認下さい 月曜 ~ 金曜 9:00~12:00 13:00~18:00 ( 祝日および年末年始除く )

77

78 79