メモリのパフォーマンス
ThingWorx アプリケーションの合計メモリ使用量でパフォーマンスの問題が確認されることがよくあります。アプリケーションが Java メモリヒープを大量に使用し、常に大きなメモリオブジェクトを作成して破棄している場合、このシステムのメモリ判定基準でパフォーマンス低下のいくつかの兆候が現れます。システムの総合的な応答性においては、Java ガベージコレクションの頻度および時間が重要な役割を果たします。ガベージコレクションが連続してループしている場合、アプリケーションに必要なメモリが不足し、ThingWorx プラットフォームが完全に応答しなくなる可能性があります。
Java メモリ使用量およびガベージコレクションを経時的に監視するには、GC ログを有効にすることをお勧めします。PSM や VisualVM などのツールでもメモリ使用量の情報が表示されます。ただし、フル GC ループが原因で JVM が応答不能になっている場合、これらの外部アプリケーションはメモリの問題を示すデータを取得できないことがあります。
オペレーティングシステムレベルでメモリを監視している場合、ThingWorx アプリケーションで割り当てられているメモリがどのように使用されているかについての情報は提供されません。監視ツールでは、オペレーティングシステムに対して Java がリクエストしたメモリ量についての情報は取得されますが、java がメモリをどのように使用しているかは示されません。パフォーマンスの問題の多くは、オペレーティングシステムのメモリ割当ではなく、Java ヒープ領域における内部メモリの使用量によって生じます。
Java に割り当てられている総メモリは、ランタイムでロードされる -Xms (最小) および -Xmx (最大) パラメータによって決まります。Tomcat が tomcat8w コンフィギュレーションパネルを使用して設定されている場合、-Xms および -Xmx パラメータは初期および最大メモリプールサイズを指定します。
起動時に最小値または最大値が指定されていない場合、起動時の Java プロセスはヒューリスティック手法を使用してこれらの量を事前に割り当てます。デフォルトでは、Java はオペレーティングシステムで使用可能な総 RAM の 4 分の 1 の割り当てを試みます。
メモリの問題の原因となるオペレーション
メモリの問題の原因となりうる次のオペレーションを監視しなければなりません。
• 45 秒以上かかる、非常に長く頻度が多いフル GC オペレーション - フル GC はストップザワールドオペレーションなので望ましくありません。JVM が一時停止する時間が長いほど、より多くのメモリの問題が発生します。
◦ JVM が使用可能なメモリを増やそうとしている間、その他のアクティブなスレッドはすべて停止します。
◦ フル GC にはかなりの時間が (場合によっては数分) かかり、その間アプリケーションは応答不能になることがあります。
• フル GC がループで発生している - 立て続けに発生しているフル GC をフル GC ループと呼びます。これによって次のような問題が発生することがあります。
◦ JVM がさらなるメモリをクリーンアップできない場合、ループが無限に実行される可能性があります。
◦ ループが続いている間、ユーザーは ThingWorx アプリケーションを使用できません。
• メモリリーク - メモリリークはアプリケーションでメモリ内のオブジェクトの数が増え続けている場合に発生します。JVM が実行しているガベージコレクションのタイプに関係なく、これらのオブジェクトはクリーンアップできません。
◦ メモリ消費量の経時変化をチェックしている場合、メモリリークは、回収されることなく増え続けているメモリ使用量として表示されます。
◦ 設定されている上限に関係なく、サーバーは最終的にメモリ不足になります。