OutOfMemoryError の対応方法/Heap 分析ツール(MAT)の使い方

Like this? Share it with your network

Share

OutOfMemoryError の対応方法/Heap 分析ツール(MAT)の使い方

  • 2,491 views
Uploaded on

「OutOfMemoryError の対応方法/Heap 分析ツール(MAT)の使い方」 ...

「OutOfMemoryError の対応方法/Heap 分析ツール(MAT)の使い方」

Javaアプリケーションのトラブルシューティング(特にOOME)や性能評価の際にヒープ
サイズを調整したり、プログラムが使用するメモリ量を分析することが有効です。初心者
向けにメモリリークを発見するための「Eclipse Memory Analyzer(MAT)」の使い方を紹介します。

伊藤忠テクノソリューションズ株式会社 ソリューションビジネス部
橋本 和俊氏

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,491
On Slideshare
2,299
From Embeds
192
Number of Embeds
4

Actions

Shares
Downloads
42
Comments
0
Likes
6

Embeds 192

http://pec-local.swe.nec.co.jp 136
https://twitter.com 48
http://www.slideee.com 6
http://www.slidesearchengine.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Copyright (c)2014 ITOCHU Techno-Solutions CorporationCopyright (c)2014 ITOCHU Techno-Solutions Corporation OutOfMemoryError の対応方法 / Heap 解析ツール(MAT)の使い方 ソリューションビジネス部 橋本 和俊 2014/6/24
  • 2. Copyright (c)2014 ITOCHU Techno-Solutions Corporation はじめに • 発表する内容は個人の見解であり、所属する組織の公式 な見解ではありません。 • 資料の内容は正確を期するよう注意しておりますが、妥 当性や正確性について保証するものではありません。 • 資料に関しては以下の環境において作成しております。 – Oracle WebLogic Server 12.1.2 – Windows 7 • 内容として、管理者向け、及び、初心者用に用意してあり ます。 1
  • 3. Copyright (c)2014 ITOCHU Techno-Solutions Corporation 導入 OutOfMemoryError(以降、OOME)に 悩まされておりませんか? 2
  • 4. Copyright (c)2014 ITOCHU Techno-Solutions Corporation 導入 • OOMEはJavaVMのメモリ不足に対するエラーです。 • 下記を知れば、OOMEの解決までが早くなります。 1. JavaVMのメモリに関する内訳 2. OOMEのエラーメッセージの意味 3. Heap Dumpの出し方 • あとできれば、MAT(解析ツール)の簡単な使い方も… 3
  • 5. Copyright (c)2014 ITOCHU Techno-Solutions Corporation Agenda • OOME の理解 – Javaの製品知識/メモリの持ち方 – OOMEとは – GCログの出力設定 – GCログの見方 – OOME調査方法 – Heap Dump の取得方法 • MATの使い方 • 個人的所管 4
  • 6. Copyright (c)2014 ITOCHU Techno-Solutions Corporation Javaの製品知識 • Oracle 社が提供している Java は簡単に分けると… – HotSpot(Sun JDK) • Sun -> Oracle 社 • 今回はJDK5以降を対象に記載しています。JDK1.4でも同様の部分 が多いです。 – JRockit • Appeal Virtual Machines -> BEA Systems -> Oracle 社 • 今回はR28以降を対象に記載しています。 – HotRockit • HotSpotとJRockitとの融合を行ったJavaVM(JDK7 以降)の通称。 • 正式にはOracle JDKやHotSpot。 5
  • 7. Copyright (c)2014 ITOCHU Techno-Solutions Corporation Java におけるメモリの持ち方 • HotSpotとJRockitとではメモリの持ち方が違います。 – HotSpot/HotRockit(JDK7まで) • Heap – JavaVMのオブジェクト(String等)や配列の実体が格納されます。 – 中でYoung領域とOld領域に分かれます。 • Permanent(以降Perm) – JavaVMのクラス情報などのMeta情報が格納されます。 • C Heap(Native) – 最適化されたコード/JNIなどが格納されます。 • JDK8からはPerm -> Metaspace となり、Nativeに配置されるなど仕 様も変わっておりますが、今回は説明を省略。 6 Heap Permanent C Heap (Native)
  • 8. Copyright (c)2014 ITOCHU Techno-Solutions Corporation Java におけるメモリの持ち方 • HotSpotとJRockitとではメモリの持ち方が違います。 – JRockit • Permはありません。C Heapに含まれます。 7 Heap C Heap (Native)
  • 9. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOMEとは • JavaVMは使用済みで参照されないオブジェクトをメモリ を開放する仕組み=GC(Young領域のGC)/FullGC(Heap 全体のGC)があります。 • しかし、GCを行ってもメモリが確保できない場合、 JavaVMはメモリ不足(OOME)を発生させます。 • OOMEはJavaのメモリ不足を示すエラーですが、場所に より種類があります。 8
  • 10. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOMEとは • Heap – java.lang.OutOfMemoryError: Java heap space – java.lang.OutOfMemoryError: GC overhead limit exceeded • JDK6以降で” -XX:-UseGCOverheadLimit”を指定していない場合 – java.lang.OutOfMemoryError: getNewTla • JRockitの場合(※TLAが足りていない可能性もあり。) • Perm – java.lang.OutOfMemoryError: PermGen space • C Heap(Native) – SIGSEGVで落ちることとか、 java.lang.OutOfMemoryError: unable to create new native thread とかrequested XXXX bytes for ChunkPool::allocate. Out of swap space? とか… 9 Heap Permanent C Heap (Native)
  • 11. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOMEとは • OOMEが発生した際にはJavaの動作が不安定になるた め、ありえない動作が起こりえます。 (※FYI) – 再起動しなければ解消されません。 – 再起動したのみでは一時的な解消でしかありません。 – OOME後の動作についてはサポート対象外とされます。 • OOMEはコンソールログにのみに出力される場合があり ます。WebLogicの運用においてはコンソールログの出 力は必須です。 – 下記設定のみでは出力されない情報もあります。(スレッドダン プとか…) • “標準出力のロギングのリダイレクトを有効化” • ”標準エラー出力のロギングのリダイレクトを有効化” 10
  • 12. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOMEとは • 原因を特定させるためにはOOME発生時のスレッドスタッ クだけでは不可能です。 – スレッドで実行した行が原因でメモリを圧迫しているのか、別の スレッドで確保していたオブジェクトがメモリを圧迫しているのか は分かりません。 • 普段からGCの発生状況が分かるGCログを取得し、どの メモリが足りないかを確認できる状態にしましょう。 – vmstatやpsの結果ではJavaVMのメモリ使用量までは分かりま せん。 11
  • 13. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの出力設定(HotSpot) • GCログの設定 12 オプション 説明 -verbose:gc GC情報の出力 -Xloggc:<ファイル名> GCログの出力先設定 再起動時に上書きされないようにファイル 名に日時を入れる等、工夫してください。 -XX:+PrintGCDetails GCログの詳細設定 -XX:+PrintGCDateStamps(6u4以降) / -XX:+PrintGCTimeStamps GCログの時間出力設定
  • 14. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの出力設定(HotSpot) • GCログのローテーション(7u2,6u34以降) 13 オプション 説明 -XX:-UseGCLogFileRotation GCログのローテーション有効化 -XX:NumberOfGClogFiles=1 GCログのローテーションファイル数 -XX:GCLogFileSize=8K GCログのローテーションのファイルサ イズ
  • 15. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの出力設定(JRockit) • HotSpotとほぼ同様の設定です。 – JRockitにおけるGCログのローテーションのオプションはありま せん。 – 代わりとして、jrcmd {PID} verbosity filename={FILE} にて出力ファイル名を変更させることにより代用することが可能 です。 • cron等で定期的に実行する必要があります。 14 オプション 説明 -Xverbose:memory GC情報の出力 -Xverboselog:<ファイル名> GCログの出力先設定 -XverboseTimeStamp GCログの日時出力設定
  • 16. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • GCログの見方を確認する前に基本的なHeapの使用量 の推移を確認してみましょう。 • Heap使用量が下がる時点がGC/FullGCが発生しており ます。 15 4/1/20149:00 4/1/20149:03 4/1/20149:06 4/1/20149:09 4/1/20149:12 4/1/20149:15 4/1/20149:18 4/1/20149:21 4/1/20149:24 4/1/20149:27 4/1/20149:30 4/1/20149:33 4/1/20149:36 4/1/20149:39 4/1/20149:42 4/1/20149:45 4/1/20149:48 4/1/20149:51 4/1/20149:54 4/1/20149:57 4/1/201410:00 4/1/201410:03 4/1/201410:06 4/1/201410:09 4/1/201410:12 4/1/201410:15 4/1/201410:18 4/1/201410:21 4/1/201410:24 4/1/201410:27 4/1/201410:30 4/1/201410:33 4/1/201410:36 4/1/201410:39 Heapの推移
  • 17. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • 赤丸がFullGCが発生した時点です。 • FullGC時の発生後のHeap使用量がほぼ同一ならば使 用量 = 開放量であり、動作に問題ありません。 16 4/1/20149:00 4/1/20149:03 4/1/20149:06 4/1/20149:09 4/1/20149:12 4/1/20149:15 4/1/20149:18 4/1/20149:21 4/1/20149:24 4/1/20149:27 4/1/20149:30 4/1/20149:33 4/1/20149:36 4/1/20149:39 4/1/20149:42 4/1/20149:45 4/1/20149:48 4/1/20149:51 4/1/20149:54 4/1/20149:57 4/1/201410:00 4/1/201410:03 4/1/201410:06 4/1/201410:09 4/1/201410:12 4/1/201410:15 4/1/201410:18 4/1/201410:21 4/1/201410:24 4/1/201410:27 4/1/201410:30 4/1/201410:33 4/1/201410:36 4/1/201410:39 Heapの推移
  • 18. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • メモリリークが疑われる例です。 FullGC発生後のHeap の使用量が少しずつ増えています。 – メモリ使用量が短時間で急激に伸びている場合はメモリリーク よりもアプリの作り的にメモリを大きく消費しているケースが多い です。(※DBのデータを全てHeapメモリに載せたとか…) 17 4/1/20149:00 4/1/20149:02 4/1/20149:04 4/1/20149:06 4/1/20149:08 4/1/20149:10 4/1/20149:12 4/1/20149:14 4/1/20149:16 4/1/20149:18 4/1/20149:20 4/1/20149:22 4/1/20149:24 4/1/20149:26 4/1/20149:28 4/1/20149:30 4/1/20149:32 4/1/20149:34 4/1/20149:36 4/1/20149:38 4/1/20149:40 4/1/20149:42 4/1/20149:44 4/1/20149:46 4/1/20149:48 4/1/20149:50 4/1/20149:52 4/1/20149:54 4/1/20149:56 4/1/20149:58 4/1/201410:00 4/1/201410:02 4/1/201410:04 4/1/201410:06 4/1/201410:08 4/1/201410:10 4/1/201410:12 4/1/201410:14 4/1/201410:16 4/1/201410:18 4/1/201410:20 4/1/201410:22 4/1/201410:24 4/1/201410:26 4/1/201410:28 4/1/201410:30 4/1/201410:32 4/1/201410:34 4/1/201410:36 4/1/201410:38 Heapの推移
  • 19. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • GCログを見てみましょう。(FullGCの場合) – HotSpot • 2014-06-10T15:55:31.907+0900: 39.336: [Full GC – [日付]: [起動してからの秒時間]: [GC/Full GC • PSYoungGen: 43512K->0K(306176K) – Young領域の使用量が 43512K->0K に。 – 現在のYoung領域の最大値:306176K 18 2014-06-10T15:55:31.907+0900: 39.336: [Full GC [PSYoungGen: 43512K->0K(306176K)] [ParOldGen: 74381K->85121K(699392K)] 117894K->85121K(1005568K) [PSPermGen: 103309K- >103237K(262144K)], 0.3625735 secs] [Times: user=1.00 sys=0.02, real=0.36 secs]
  • 20. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • GCログを見てみましょう。(FullGCの場合) – HotSpot • ParOldGen: 74381K->85121K(699392K) – Old領域の使用量が 74381K->85121K に。 – 現在のOld領域の最大値:699392K • 117894K->85121K(1005568K) – Heap全体の使用量が 117894K->85121K に。 – 現在のHeapの最大値:1005568K 19 2014-06-10T15:55:31.907+0900: 39.336: [Full GC [PSYoungGen: 43512K->0K(306176K)] [ParOldGen: 74381K->85121K(699392K)] 117894K->85121K(1005568K) [PSPermGen: 103309K- >103237K(262144K)], 0.3625735 secs] [Times: user=1.00 sys=0.02, real=0.36 secs]
  • 21. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • GCログを見てみましょう。(FullGCの場合) – HotSpot • PSPermGen: 103309K->103237K(262144K)], 0.3625735 secs – Permの使用量が 103309K->103237K に。 – 現在のPermの最大値:262144K – GCにかかった時間: 0.3625735 secs • Times: user=1.00 sys=0.02, real=0.36 secs – user/sys はCPU時間 – real が実際にかかった時間 20 2014-06-10T15:55:31.907+0900: 39.336: [Full GC [PSYoungGen: 43512K->0K(306176K)] [ParOldGen: 74381K->85121K(699392K)] 117894K->85121K(1005568K) [PSPermGen: 103309K- >103237K(262144K)], 0.3625735 secs] [Times: user=1.00 sys=0.02, real=0.36 secs]
  • 22. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • GCログを見てみましょう。(FullGCの場合) – JRockit • [memory ][Tue Jun 10 15:50:20 2014][04992] [OC#1] – [ログの種類][時刻][PID][GC(YC)/FullGC(OC)と回数] • 584.903-584.937 – 起動してからの秒数における、GC起動時間 – GC終了時間 21 [memory ][Tue Jun 10 15:50:20 2014][04992] [OC#1] 584.903- 584.937: OC 1032213KB->239710KB (1048576KB), 0.034 s, sum of pauses 31.643 ms, longest pause 31.643 ms.
  • 23. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • GCログを見てみましょう。(FullGCの場合) – JRockit • OC 1032213KB->239710KB (1048576KB), 0.034 s, – YC(GC)/OC(FullGC) – Heapの使用量が 1032213KB->239710KB に。 – 現在のHeapの最大値: 1048576KB – かかった時間: 0.034 s • sum of pauses 31.643 ms, longest pause 31.643 ms – GCの停止時間総計と最長の停止時間 22 [memory ][Tue Jun 10 15:50:20 2014][04992] [OC#1] 584.903- 584.937: OC 1032213KB->239710KB (1048576KB), 0.034 s, sum of pauses 31.643 ms, longest pause 31.643 ms.
  • 24. Copyright (c)2014 ITOCHU Techno-Solutions Corporation GCログの見方 • GCログの見方 – まずは見るべきは… • FullGC後のHeap使用量 • FullGCの単位時間あたりの回数 • FullGCにかかった時間(特にStop The Worldの時間) – 2014-06-09T16:43:52.404+0900: 62.115: [GC [PSYoungGen: 304340K->43490K(306176K)] 304412K- >55271K(1005568K), 0.0649016 secs] [Times: user=0.20 sys=0.00, real=0.06 secs] – 可能であれば加工してグラフにするとメモリ消費傾向が分かり やすいです。 23
  • 25. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOME調査方法(Perm) • Permが足りない場合は… – まずは増やしてみましょう。 • -XX:PermSize(初期値) と -XX:MaxPermSize(最大値) • 基本的に初期値=最大値に設定してください。 – 増やしても足りない場合は読み込まれているクラス情報を確認 する等の別の視点からの調査が必要です。 • クラス・ローダー分析ツール(CAT)を使うとか… (※WebLogic 10.3.4 以降) 24
  • 26. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOME調査方法(C Heap) • C Heapが足りない場合は… – 64bit JavaVMに変更すればとりあえず制限はほぼありません。 – 32bit JavaVM の場合はHeapやPermを減らしてみるのも一つ の手段です。 • C Heapの最大量は[プロセスの最大メモリ量] – [Heap最大量] – [Perm最大量]のため、Heap/Permを減らせば最大量は増えることに なります。 • ただし、他のOOMEが出ないように注意してください。 – Native Memory Tracking(7u40以降) を使えば解析も 可能ですが… 25
  • 27. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOME調査方法(Heap) • Heapが足りない場合… 1. Heapが少ない場合はHeapを増やしてみましょう。 • 単純に足りない場合もあります。 2. GCログを見て、Heapの使用量の動きをみてみましょう。 • GCログにより、メモリリークが起きているかどうかを確認しましょう。 3. MATを使ってみましょう。 26
  • 28. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOME調査方法(Heap) • Heapが足りない場合… – Heapが1Gぐらいの場合は単純にプログラムに対するHeapが 足りない場合もあるため、まずはHeapを増やして(-Xms/-Xmx) 再現するかどうかの検証をすることが有効です。 – Heapが大きいとHeap Dump等を解析する時に問題が顕在化 し、調査が行いやすくなります。逆に大きすぎると解析しづらい ので、ほどほどに… – Heapを大きくするとOOMEが発生するまで時間が延びます。原 因不明ならばHeapを大きくして毎日再起動等での対処もありと いえばありです。(あまり推奨したくないですが。) – 32bit JavaVMを使用している場合は2G制限を考慮し、Heap は1.5Gまでとりあえず上げてみてください。64bitならばOSの空 き物理メモリ量と相談しましょう。27
  • 29. Copyright (c)2014 ITOCHU Techno-Solutions Corporation OOME調査方法(Heap) • メモリリークが起きている可能性がある場合… – Oracle JRockit Mission Controlを使用している場合は Memory Leak Detectorを使用することで解析可能です。しかも 高機能です。(ただし、ライセンスは有料) – Heap Histogramはコマンドで表示できます(※FYI)が、見るのにコ ツがいります。 – jhatはJavaVMにデフォルトでついているtoolです。しかし、jhat を見てもどこが問題かを特定することは慣れていなければ難し いです。 ↓ – OOME時のHeap Dumpを取得し、自分でMATを使ってちょっと 見るのが無料で簡単にできます!(かもしれません) 28
  • 30. Copyright (c)2014 ITOCHU Techno-Solutions Corporation Heap Dumpの取得方法 • Heap Dumpの取得はいろいろな方法があります。 • OOME発生後に取得してもあまり意味がありません。発 生前に取得するか、オプションを使いましょう。 • 比較するためには通常時とOOME発生時で取得すること も必要です。 – OOME時にHeap Dumpを出力するオプションを使用します。 29 JavaVM オプション HotSpot -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=[HEAP_DUMP_PATH] JRockit -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=[HEAP_DUMP_DIR_PATH]
  • 31. Copyright (c)2014 ITOCHU Techno-Solutions Corporation HeapDumpの取得方法 • Heap Dumpの取得はいろいろな方法があります。 – 動作中のHeap Dumpを取得することも可能です。 – とりあえずは上記を覚えておけば問題ありません。 30 JavaVM コマンド HotSpot jps -mlv でJavaVMのプロセスIDを確認し、 jmap -dump:format=b,file=[FILE_NAME] [JVM_PID] JDK5.0以降にjmapはありますが、Windows版のJDK5.0では jmapは提供されておりません。 JDK6.0以降は全てのプラットフォームで提供されております。 JRockit jps -mlv でJavaVMのプロセスIDを確認し、 jrcmd [JVM_PID] hprofdump filename=[FILE_NAME]
  • 32. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATのインストール 31
  • 33. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATのインストール • Standalone版とEclipseのplugin版がありますが、今回は Standalone版を使います。 32
  • 34. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATのインストール • 後はダウンロード先を選んでDLします。 33
  • 35. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATのインストール • 解凍したMemoryAnalyzer.exeを実行します。 34
  • 36. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの使用 • 起動後、File -> Open Heap Dump… を行います。 35
  • 37. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの使用 • ファイルが表示されない場合は All Files を選択します。 36
  • 38. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの使用 • この画面ではそのまま[Finish]を押下します。 37
  • 39. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの使用 • 読み込みが終わると、Leak Suspects Reportの画面にな ります。 38
  • 40. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Leak Suspects Reportの画面にて Problem Suspect の 詳細を確認します。 39
  • 41. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Detailを確認すると具体的な内容等が分かります。 40
  • 42. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • MemorySessionContextとあるため、セッションにデータ が多く格納されていることが分かります。 41
  • 43. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Heap Histogramを確認することも可能です。 42
  • 44. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 43 • dominator treeを確認することも可能です。
  • 45. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 44 • Heapの量により、分かりやすさが変わります。
  • 46. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Leak Suspectsは必ずしも正解が出てくるとは限りません が、有効なツールです。 • 詳細に確認する場合はHeapの差分比較を行い、どのオ ブジェクトが増え、増えたオブジェクトがどれだけのメモリ を使用しているかを確認します。 45
  • 47. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Heapの差分比較を行う場合 – 事前に通常時とOOME時のHeap Dumpを取得します。 – MATに両方のHeap Dumpを読み込ませます。 46
  • 48. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Heapの差分比較を行う場合 – OOME時のHeap Histogramを表示します。 47
  • 49. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Heapの差分比較を行う場合 – 右端にある[Compare to another Heap Dump]を押下します。 48
  • 50. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Heapの差分比較を行う場合 – どのHeap Dumpと比較するかを選択し、[OK]を押下します。 – 今回の場合は通常時を選択します。 49
  • 51. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATの見方 • Heapの差分比較を行う場合 – 差分でどのオブジェクトが増えて、メモリを消費しているかがわ かります。 50
  • 52. Copyright (c)2014 ITOCHU Techno-Solutions Corporation MATを使うときのポイント • Heapが大きい方が問題が分かりやすくなります。 – 前頁での円グラフでの割合が大きくなるため、見やすい。 – また、Leak Suspectが正常に働く可能性が高い。 – 大きすぎると解析にメモリが必要になり、時間もかかるので、ほ どほどに… • MAT自体がメモリ不足になった場合は、同フォルダにある MemoryAnalyzer.ini にてメモリ設定を可能です。 – -Xmx1024mがデフォルト(Windows_64bit_standalone版) 51
  • 53. Copyright (c)2014 ITOCHU Techno-Solutions Corporation 個人的所感 • WebLogicのJavaVMのメモリに関するデフォルト設定値 よりも小さい値での運用は行わない方が無難です。 – OOMEの頻度があがります… • GCの方式の変更に過度の期待をしないようにしましょう。 – JavaVMのバージョンアップの方が早くなる可能性もあります。 • HeapやPermの容量を変更する場合は初期値と最大値 を同じにしましょう。 52
  • 54. Copyright (c)2014 ITOCHU Techno-Solutions Corporation 個人的所感 • 32bit JavaVMを使用する場合はHeapの容量は最大でも 1.5Gに抑えましょう。 – それより大きく設定したい場合はOracle Coherenceを使用する か、インスタンスを分けましょう。 • 64bit JavaVMを使用する場合はHeapを大きく設定でき ますが、必ず物理メモリ範囲に抑えましょう。 – Heapが大きくなれば、GCにかかる時間も増えます。 – 状況により、 Oracle Coherenceを使用するか、インスタンスを 分けましょう。 53
  • 55. Copyright (c)2014 ITOCHU Techno-Solutions Corporation 結び 御清聴ありがとうございました。 構築中やOOMEが出たときに 御確認いただけますと幸いです。 54
  • 56. Copyright (c)2014 ITOCHU Techno-Solutions Corporation FYI • OOME時に強制的に停止させる場合 – このオプションだけでは停止したままとなります。起動には ノードマネージャ等で再起動の設定が別途必要です。 55 JavaVM オプション HotSpot -XX:OnOutOfMemoryError="kill -9 %p” (UNIX) -XX:OnOutOfMemoryError="taskkill /F /PID %p“ (Windows) JDK1.4.2 update 12以降や6以降で使用が可能です。 5では使用できません。 JRockit -XX:+ExitOnOutOfMemoryError R28.1以降であれば、-XX:+CrashOnOutOfMemoryError を追加 することができます。
  • 57. Copyright (c)2014 ITOCHU Techno-Solutions Corporation FYI • Heap Histogram の取得方法 56 JavaVM コマンド HotSpot jps -mlv でJavaVMのプロセスIDを確認し、 jmap -histo [JVM_PID] JDK5.0以降にjmapはありますが、Windows版のJDK5.0では jmapは提供されておりません。 JDK6.0以降は全てのプラットフォームで提供されております。 JRockit jps -mlv でJavaVMのプロセスIDを確認し、 jrcmd [JVM_PID] print_object_summary [increaseonly=true]
  • 58. Copyright (c)2014 ITOCHU Techno-Solutions Corporation リンク集 • Java HotSpot VM Options – http://www.oracle.com/technetwork/java/javase/tech/vmopti ons-jsp-140102.html • JRockit コマンド ライン リファレンス – http://docs.oracle.com/cd/E15289_01/doc.40/e15062/toc.ht m 57
  • 59. Copyright (c)2014 ITOCHU Techno-Solutions Corporation リンク集 • Memory Analyzer (MAT) – https://www.eclipse.org/mat/ • Oracle JRockit Mission Control – http://www.oracle.com/technetwork/jp/middleware/jrockit/mi ssion-control/index.html?ssSourceSiteId=ocomjp • jhat – http://docs.oracle.com/javase/jp/7/technotes/tools/share/jhat .html 58
  • 60. Copyright (c)2014 ITOCHU Techno-Solutions Corporation リンク集 • jmap – http://docs.oracle.com/javase/7/docs/technotes/tools/share/j map.html • jrcmd – http://otndnld.oracle.co.jp/document/products/jrockit/geninfo /diagnos/ctrlbreakhndlr.html#wp1001718 • hprofdump – http://docs.oracle.com/cd/E22646_01/doc.40/b61441/diagn ostic.htm#BABIACCC 59
  • 61. Copyright (c)2014 ITOCHU Techno-Solutions Corporation60