jetty 8.1.7 で本番環境で実行されているサーブレット アプリケーションでメモリ リークが発生する可能性があると思います。
- -Xmxで割り当てられた最大メモリではなく、実際に使用されているメモリの量である、ある時点で実際に使用されているヒープメモリの量を確認する方法はありますか?
- jetty 内で実行されているアプリケーションに対して強制的にガベージ コレクションを実行することはできますか?
jetty 8.1.7 で本番環境で実行されているサーブレット アプリケーションでメモリ リークが発生する可能性があると思います。
はい、どちらも以下を使用して簡単に実現できます: VisualVM
(参照: http://docs.oracle.com/javase/6/docs/technotes/guides/visualvm/monitor_tab.html ) これはデフォルトで Oracle JDK に同梱されています (=> no追加のインストールが必要です)
ただし、メモリ リークの検出については、メモリ ダンプを実行し、後でeclipse MAT
( http://www.eclipse.org/mat/ ) で分析することをお勧めします。これは、Java メモリ ダンプを視覚化する非常に優れた UI を備えているためです。
編集:
ssh のみのアクセスの場合、上記の 2 つのツールを使用できます。ただし、ウィンドウマネージャーを実行しているマシンでそれらを実行し、ssh経由で他のマシンにリモート接続する必要があります(これらのマシンの両方にJavaが必要です):
visualVM
必要があります。次を参照してください: VisualVM over sshVisualVM
jmap
(使用例については、http: //kadirsert.blogspot.de/2012/01/を参照) その後、ダンプ ファイルをダウンロードし、ローカルにロードする場合はeclipse MAT
jmxを有効にし、jconsoleを使用してそれに接続します
%JAVA_HOME%\bin フォルダーの下にある jvisualvm.exe を使用できます。このアプリケーションを使用すると、メモリ使用量を監視したり、gc を強制したりできます。
を呼び出すことができますSystem.gc()
。これは通常、完全な GC を実行します ... しかし、この機能は無効にすることができます。(HotSpot JVM でこれを行うための JVM オプションがあります。)
ただし、問題がメモリ リークである場合は、GC を実行しても役に立ちません。実際、サーバーが現在よりもさらに遅くなる可能性があります。
メモリ使用量を監視することもできますが (さまざまな方法で - 他の回答を参照してください)、メモリ リークが発生している可能性があるという証拠しか得られません。
本当に必要なのは、メモリ リークの原因を見つけて修正することです。
参照: