メモリの問題を監視するためのガベージコレクター (GC) のログファイルの分析
本番環境で GC ログを有効にすることをお勧めします。GC ログを有効にする方法については、
ThingWorx サーバーのメモリ使用量の監視のセクションを参照してください。GC ログを有効にすると、サーバー上のすべての GC アクティビティがログに記録されます。JVM が長時間にわたって応答していない場合、PSM や VisualVM などの外部ツールがメモリデータを収集できないことがあります。ただし、JVM は GC アクティビティを出力できるので、ここからメモリの問題の原因を特定できます。
GC ログの読み取り
GCEasy.io や Chewiebug GC Viewer などのツールを使用して GC ログを分析できます。一般的な問題についてテキストエディタで GC ログを手動で分析することもできます。
各メモリクリーンアップオペレーションは一般的に、次の例に示すように出力されます。
1. JVM 起動からの経過時間
2. GC のタイプ
3. GC の理由
4. 第一世代を 549 M から 4M までクリーンアップ
5. 第一世代の合計サイズ
6. GC が完了するまでの総時間
7. 割り当てられているヒープ
8. Java がクリーンアップしているアプリケーションの合計メモリ
GC オペレーションの詳細については、Oracle のドキュメンテーションを参照してください。
GC 解析ツールは、クリーンアップのテキスト表示を、さらに読みやすいグラフに変換します。
GC ログのデータを分析することで、ThingWorx アプリケーションにメモリの問題があることを示す次のシナリオを把握できます。
• フル GC オペレーションにかかる時間が非常に長い (45 秒以上) - これらは非常に望ましくないストップザワールドオペレーションです。たとえば、次のフル GC は 46 秒かかっています。この間、その他すべてのユーザーアクティビティが停止しています。
272646.952: [Full GC: 7683158K->4864182K(8482304K) 46.204661 secs]
• フル GC がループで発生している - フル GC が立て続けに発生しています。
たとえば、次の 4 つの連続するガベージコレクションは解決にほぼ 2 分かかっています。
16121.092: [Full GC: 7341688K->4367406K(8482304K), 38.774491 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
• 次のグラフで、グラフスパイクの赤色の三角形は、フル GC がループしている箇所を示しています。
• メモリリーク - メモリ内のオブジェクトの数が増え続けていて、メモリをクリーンアップできない場合に発生します。
次の例では、ガベージコレクターが動作しているにもかかわらず、メモリ量が増え続けています。
推奨事項 - メモリ使用量の経時変化を監視および記録する PSM などの自動ツールがない場合、メモリの問題がないか GC ログファイルを毎日確認してください。メモリの問題が発生した場合、JVM スレッドダンプまたはヒープダンプを収集して、長時間実行し続けているオペレーションを特定します。これらのオペレーションが、ThingWorx アプリケーションにおけるメモリの問題の原因となっている可能性があります。