CentOS 5.4を実行しているサーバーが複数あり、JavaVMで実行されているアプリケーションは1つだけです。 Java VMを次の引数で構成しました。
Java -Xmx4500M -server -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:NewSize=1024m -Djava.net.preferIPv4Stack=true -Dcom.Sun.management.jmxremote=true
VMを実行しているマシンには6GB RAMがあり、他のアプリケーションは実行されていません。しばらくすると、Javaプロセスがスワップスペースに非常に激しくぶつかり始めます。この情報は、top
コマンドから取得します。
7658 root 25 0 11.7g 3.9g 4796 S 39.4 67.3 543:54.17 Java
一方、JConsole経由で接続すると、Java VMで2.6GBが使用され、4.6 GBがコミットされ、最大4.6Gbであると報告されます。
Javaバージョンは以下を返します:
Java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)
Java VMが、割り当てられたヒープサイズをはるかに超えて拡張しているのはなぜですか?そして、JConsoleで報告されていない場合、そのメモリはどこに行きますか?
一部の商用Javaベースのアプリケーションでバグに気づきました。アプリケーションは32ビットJavaで正常に動作しますが、追加の(ほとんど不要な)1.25GBが必要です) 64ビットJavaを使い始めるためだけに、32ビットで256MBを必要とするものJavaは64ビットランタイムで1.5GBを必要とします。
Javaは、アプリケーションが使用していると思われるものを報告していると思いますが、特にこのバグが呼び出された場合は、独自のランタイムオーバーヘッドは報告していません。
32ビットランタイムでアプリを実行するか、ベンダーのテクニカルサポートに戻って($$の費用がかかる場合があります)、何が起きているのかを尋ねることができます。
最終的に、合計メモリフットプリントを制限することに成功した場合、アプリをより早くクラッシュさせるだけで、問題が残ります。
-Xmxは、VMによって使用されているヒープスペースの最大量です。ロードされたクラスのメモリ、VM自体、スレッドのスタック、またはJITに使用されるメモリなどは含まれません。最初の数字には他のプログラムでも使用されている共有メモリが含まれているため、上からの行も誤解を招く可能性があります。 2番目の数値3.9gは、居住者のサイズであり、現実に近いものです。
私の推奨事項:本当に多くのヒープ(オブジェクトの数とサイズ)が必要かどうかを確認し、可能であれば-Xmxの数を減らしてください。