JVMメモリー消費


9

低メモリシステム(150-256Mb)でTomcatを実行しようとしています。-Xmx64m(いずれにしてもデフォルトであるはずです)でJVMを起動した場合でも、プロセスはすぐに200Mb以上を占有します。

なぜJVM自体がそれほど多くのメモリを必要とするのか、またはこれを調整する方法があるのでしょうか?他のJVMは、メモリ消費量が少ないという点で、SunのJVMより優れていますか?それらはTomcatで動作しますか?

回答:


5

ヒープ(-Xmsおよびで指定-Xmx)に加えて、非ヒープ領域を含める必要があります。これらには

  • PermGen。32ビットシステムでは64 MB、最初は64ビットシステムでは96 MB
  • コードキャッシュ。JVMに応じて20〜40 MBです。
  • NIOバッファー領域(DirectByteBuffersの取得元)、これは最初は64MBです

数十MBになるJVM自体の作業スペースもあります。

サーバークラスマシンを使用する場合は、Sun JVMの自動サイズ設定にも注意する必要があります。時間の経過とともに、サーバークラス(2Gbメモリ、複数のコア)の定義がいくらか下落し、現在ではほとんどのマシンが-server最適化をトリガーできるようになっています。私のアドバイスは、-Xms-Xmx設定を指定し-server、正当な理由が考えられない限り合格することです。


JVMが予約するだけで、まだ使用していない仮想メモリにも注意してください。
スティーブシュネップ2009年

確かに、PermGenやコードキャッシュなど、これらのセグメントのほとんどは起動時に割り当てられますが、ほとんどのカーネルは、必要になるまでこれらのセグメントにページを割り当てることを避けます。
デイブチェイニー、

1
情報をありがとう-これはメモリがどこに行くのかを説明していると思います これらの値を変更する方法はありますか?各セクションのどの程度が使用されているかを確認する方法がさらに良いでしょう-Javaデバッグ/監視ツールのいずれかがこれを行うことができるかどうかわかりませんか?
ドラえもん2009年

1
pmapまたはjmapを使用して、使用中のさまざまなセグメントについてのアイデアを得ることができます。一般的なオプションのほとんど(およびそれらのデフォルト)は、java.sun.com/javase/technologies/hotspot/vmoptions.jspにリストされています。それらは頻繁に変化し、OS(通常はスタックサイズ)とarch(64ビットOSは一般的に大きなJVM領域を意味します)の違いの影響を受けます
Dave Cheney

3

-Xmxオプションを使用すると、JVMが予約するヒープのサイズを制限します... JVMが必要とする追加のリソースがあります...

「メモリをありがとう」*は、JVMがメモリを使用する方法を説明する優れた記事です...

IBMのJVMを試すことができることは別として、Tomcatで動作するはずです。無料のJVM実装の一部が動作するかどうかはわかりません。

それでも、メモリの少ないマシンでうまくいくとは思いません。Javaにはメモリが必要です。

*新しいユーザーはハイパーリンクを送信できないため、その記事を自分で検索する必要があります...これは、「メモリibmに感謝します」というgoogleの最初のヒットです。


3
ibm.com/developerworks/java/library/j-nativememory-linux-記事「Thanks for the memory」へのリンク
StackKrish


0

私が見つけた便利なテクニックの1つは、JMXモニタリングを使用して、ヒープスペースとpermgenスペースで使用されているメモリの量を正確に確認することです。

http://tomcat.apache.org/tomcat-6.0-doc/monitoring.htmlの説明に従って、TomcatでJMXを設定します

次に、JConsole(JDK 5またはJDK 6に付属)を使用します。メモリータグは、時間の経過に伴うメモリー消費を追跡します。

また-webappsのソフト再起動に注意してください。ウェブアプリをリロードすると、permgenスペースはガベージコレクションされず、時間の経過とともに蓄積されます。permgenスペースを再利用するには、Tomcatを完全に停止/開始する必要があります。


JVMの代わりにVisualVMを使用することもでき、JVM内のメモリの問題を探すときにさらに詳細を提供します。問題を見つけるために、これを複数回使用する必要がありました。
Jeremy Bouse、2009
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.