5

4 CPU と 32 GB メモリの 64 ビット マシン (OS は CentOS 6.3) で Tomcat を実行しています。Tomcatを起動するJavaオプションは-server -Xms1024m -Xmx1024m -XX:PermSize=512m -XX:MaxPermSize=512m

RES は最初、top を使用してわずか 810MB であり、増加し続けています。この間jmap -J-d64 -histo pID、Java メモリ ヒープを確認するために実行しましたが、ヒープ ピークが 510MB で、gc 後は約 200MB であるため、gc は正常に機能していると思います。しかし、トップ ヒットの RES が 1.1g になると、CPU 使用率が 100% を超え、Tomcat がハングします。

CPU 使用率が 100% のときにダンプを表示するために使用jstack pidすると、「vm スレッド」という名前のスレッドがほぼ 100% の CPU を消費します。私はググった、それはJVM gcスレッドです。だから私の質問は: gc が正常に動作しているのに、なぜ res が増え続けるのですか? この問題を解決するにはどうすればよいですか? ありがとう。

4

2 に答える 2

2

パーマ液漏れかもしれません。ヒープが ~500Mb にとどまり、-XX:MaxPermSize が 512Mb に設定されている場合、permgen をフルにすると、約 1GB のメモリ使用量が得られます。

これは、プログラムのライフサイクルの後半でロードされる jsps が大量にある場合、または大量に使用した場合に発生する可能性がありますString.intern()。

さらに調査するには、このスレッドに従ってください: Permgen をダンプするには?

そして、gc を調整して permgen をスイープするためのこのスレッドJVM フラグ CMSClassUnloadingEnabled は実際に何をしますか?

于 2012-12-05T04:41:02.020 に答える
1

ガベージコレクションスレッドが100％で回転している場合は、ガベージコレクションを実行しようとしている可能性がありますが、どのオブジェクトも収集できないため、ガベージコレクションの死のスパイラルに陥り、実行を試み続けますが、解放できません。任意のメモリ。

これは、プログラムにメモリリークがあるか、通常の使用中にロードするオブジェクトの数を処理するのに十分なメモリをvmに与えていないために発生する可能性があります。ヒープサイズを増やすための十分な余裕があるようです。これは、あなたが死のスパイラルにぶつかるまでの時間を延長するだけかもしれません、あるいはそれはあなたを走っている状態にするかもしれません。避けられないことを遅らせているだけではないことを確認するために、かなりの時間テストを実行することをお勧めします。

于 2012-12-05T03:52:26.537 に答える