JVMに十分なメモリが、周波数フルGC

Question

JVMオプション： -Xms512M -Xmx512M -XX：PermSizeを= 70M -XX：MaxPermSizeを= 70M

JSTAT -gc 8260 5000

S0C：512.0 S1C： 512.0 S0U：0.0 S1U：0.0 EC：174080.0 EU：0.0 OC：349696.0 OU：45191.1 PC：71680.0 PU：34882.2 YGC：2216225 YGCT：6754.909 FGC：2216144 FGCT：160651.466 GCT：167406.375

S0C：512.0 S1C：512.0 S0U：0.0 S1U：64.0 EC：174080.0 EU：0.0 OC：349696.0 OU：45187.3 PC：71680.0 PU：34882.2 YGC：2216253 YGCT：6755.047 FGC：2216172 FGCT：160653.488 GCT：16740 8.535

S0C：512.0 S1C：512.0 S0U：0.0 S1U：128.0 EC：174080.0 EU：0.0 OC：349696.0 OU：45189.6 PC：71680.0 PU：34882.2 YGC：2216281 YGCT：6755.180 FGC：2216200 FGCT：160655.542 GCT：167410.721

S0C：512.0 S1C：512.0 S0U：0.0 S1U：0.0 EC：174080.0 EU：1775.6 OC：349696.0 OU：45187.3 PC：71680.0 PU：34882.2 YGC：2216308 YGCT：6755.309 FGC：2216227 FGCT：160657.627 GCT：167412.936

S0C：512.0 S1C：512.0 S0U：128.0 S1U：0.0 EC：174080.0 EU：0.0 OC：349696.0 OU：45187.3 PC：71680.0 PU：34882.2 YGC：2216336 YGCT：6755.444 FGC：2216255 FGCT：160659.701 GCT：167415.146

なぜJVMの周波数が満杯になったのですか？

Answer 1

ヒープとスタックのメモリがよく見える場合は、「ダイレクトメモリ」に関するメモリリークを見つけてみてください。私の場合、Netty5-ByteBufの一部はリリースされませんでした。

Answer 2

大したことはありませんが、非常に大きな配列を繰り返し割り当てたり破棄したりする可能性があります。

統計情報を正しく解釈する場合、Edenの領域は174MB、Survivorの領域は0.5MB、Old領域の領域は349MBです。大きすぎてEden空間に入れることができない配列を割り当てると、それはまっすぐにOld空間に割り当てられます。オールドスペースがいっぱいになると、完全なGCがトリガーされる可能性があります。

「大きな」大きさはどれくらいですか？ TLABの問題とそのサイズ、-XX:PretenureSizeThresholdオプションと異なる種類のGCの違いがあるため、複雑です。問題を開始するには、Martin Thompsonの"Java Garbage Collection Distilled"を読んでください。

---

これが問題でない場合は、ヒープで何が起こっているのかを深く調査する必要があります。オブジェクトのミックスが何であるか、その割り振り/処理の割合やパターンなどを把握して、なぜ多くのものがオールドスペースに終わっているのかを把握してください。

3-5日後には、これは何かが、操作のものを3〜5日間にわたり、アプリケーションのインメモリデータ構造に構築されていることを示唆する傾向

起こる、正常に動作します。そのシナリオを調査します。

Answer 3

あなたの生存スペースは非常に小さいです。ちょうど512KB。サバイバースペースがエデンスペースのクリーンアップでいっぱいになると、Full GCがトリガーされます。

あなたのエデンのスペースは〜300 x大きいので、私は彼らがいっぱいになっていない場合は驚かれるでしょう。

JVMがほとんど何も生き残っていないと思う理由で、非常に短い存続オブジェクトをたくさん作成していないことを確認します。

たとえば、オブジェクトを作成せずにUDPパケットを解析/処理できるかどうかを確認してください。