0

単一のボックスで 4 つのインスタンスを実行している WebSphere Portal アプリケーションがあり、約 7 日間の実行後、ネイティブ メモリ (PMAP を使用) には 130 ~ 150MB のアドレス空間しか空きません。さらに 7 ~ 10 日のどこかで、数値が 100 MB を大幅に下回ります (これは危険であると判断し、JVM のリサイクルを開始します)。リサイクルを行わないと、JVM は最終的に SIGSEGV シグナルでクラッシュします。

クラス数と JIT コードのサイズについて、いくつかの初期調査を行いました。クラスの数は増えますが、5 万からゆっくりと…1 日あたり約 200 になります。JITC のサイズは 7 日後に約 210 MB になり、その後は 1 日あたり約 1 MB 増加します。これまでの経験では、これらが不吉な値であるとは思いません。

スレッド (すべてのスレッド カウントは正常に表示され、スレッド プールは固定されています)、文字列プール、定数プール、バイトコードなど、ネイティブ ヒープ内にあるものを分解できるようにするために必要なこと。

私たちが現在試みている手掛かりの 1 つは、リフレクションのしきい値を 0 に減らすことです (リフレクションで作成されたクラスのバイトコード アクセサーをシャット オフします)。このアプリは多くのポイントカッティングとリフレクションを使用しているため、これが役立つ可能性が高いことを願っています.

どんなアドバイスでも大歓迎です。

4

2 に答える 2

0

ちょっとしたやり取りかもしれませんが、GC をログに記録して、時間の経過とともに Java ヒープが増加していないことを確認しましたか? あなたのパーマスペースを見ましたか?SIGSEGV は興味深いものですが、Java 内のメモリの問題については、より JVM っぽいクラッシュが予想されます。

于 2010-09-22T23:38:27.967 に答える
0

長い調査の結果、これは WebSphere のバグであることが判明しました: PK72252: CALLS TO CLASSLOADER.GETRESOURCEASSTREAM ARE SLOW6.0.2.33で修正されました。

于 2010-10-26T13:57:26.787 に答える