バックグラウンド：
やや大きな Java ヒープを持つベンダー提供の Java アプリケーションがあります。あまり詳しく説明しなくても、このアプリは私たちにとってブラック ボックスですが、パフォーマンスの調整と問題の修正を自分たちで行う必要があると感じています。
64 ビットの SunOS 10 マシンには 16GB の RAM があり、実行されている唯一の非システム アプリはこのアプリの JVM です。64 ビット JVM は JBoss で実行されますが、これはこの議論には無関係だと思います。また、最大ヒープ サイズは 8GB であり、これは関連していると思います。
最近の問題は、さまざまなメモリ不足エラーが発生していることです。これらのエラーが発生した場合、ヒープがいっぱいではなく、「Out of Swap Space?」というエラーが表示されます。ベンダーは、スワップを 2GB から 4GB に増やすことを望んでいます。これは 16GB のシステム上にあり、アプリは 8GB しかありません。これはパフォーマンスにとって悪い考えだと思います。
私の質問：
そのため、パフォーマンスを向上させるために、ファイル キャッシュが残りの空きメモリをすべて使い果たすことがわかりました。通常は問題ありませんが、明らかにメモリが断片化されています。Hotspot JVM は連続したメモリ空間を必要とするため、このメモリの断片化により、断片化されていないスワップ領域が使用されることがわかっています。
ただし、断片化と連続したメモリの要件との関係を理解しているかどうかはわかりません。確かに、断片化は物理RAMの断片化を指しているだけです。仮想メモリを使用すると、連続した RAM のチャンクに支えられていなくても、連続した RAM のチャンクを割り当てることが完全に可能です。つまり、連続していない物理メモリのチャンクは、実行中のプロセスからは連続した仮想メモリのチャンクとして認識されます。
ですから、そこには一文の質問はなかったと思いますが、この件についてもっと知っていて、参加できる人はいますか? 64 ビット システムでのこの連続したメモリの問題を参照するリンクはありますか?
これまでに見つけたもの：
これまでのところ、「連続メモリ」の問題について私が見つけたすべての参考文献は、仮想アドレス空間が 32 ビット アドレス システムでどのように配置されるかに関連していました。64 ビット システム (おそらく 48 ビット アドレッシング) を実行しているため、大きな連続したチャンクを割り当てるための十分な仮想アドレス空間があります。
この情報を求めてインターネット全体を探しましたが、これまでのところ、探している情報を見つけることができませんでした。
アップデート:
- 明確にするために、私はなぜ OOM エラーが発生したのかについて答えを得ようとしたのではなく、断片化された可能性のあるシステム RAM と、Java が必要とする仮想メモリの連続したチャンクとの関係を理解しようとしていました。
- prstat -Z
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
0 75 4270M 3855M 24% 92:24:03 0.3% global
- echo "::memstat" | mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 326177 2548 16%
ZFS File Data 980558 7660 48%
Anon 561287 4385 27%
Exec and libs 12196 95 1%
Page cache 17849 139 1%
Free (cachelist) 4023 31 0%
Free (freelist) 156064 1219 8%
Total 2058154 16079
Physical 2042090 15953
以前は、ZFS ファイル データは自由に利用できるメモリであると考えていましたが、そうではなく、エラーの原因である可能性が高いことを後で知りました。
vmstat 5 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr vc vc vc -- in sy cs us sy id
0 0 0 2161320 2831768 12 55 0 0 0 0 0 3 4 -0 0 1089 1320 1048 1 1 98
0 0 0 819720 1505856 0 14 0 0 0 0 0 4 0 0 0 1189 748 1307 1 0 99
0 0 0 819456 1505648 0 1 0 0 0 0 0 0 0 0 0 1024 729 1108 0 0 99
0 0 0 819456 1505648 0 1 0 0 0 0 0 0 0 0 0 879 648 899 0 0 99
0 0 0 819416 1505608 0 1 0 0 0 0 0 0 3 0 0 1000 688 1055 0 0 99
これらのコマンド出力は、アプリケーションが正常な状態で実行されていたときに取得されました。上記のすべてを監視し、スワップ領域エラーが再び発生した場合に備えてログに記録しています。
以下は、JVM が 8GB に成長してから再起動した後のものです。この結果、ZFS ARC は (RAM の 26% に) 縮小し、再び大きくなります。物事は今どのように見えますか？
vmstat 5 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr vc vc -- -- in sy cs us sy id
0 0 0 1372568 2749528 11 41 0 0 0 0 0 2 3 0 0 713 418 539 0 0 99
0 0 0 3836576 4648888 140 228 0 0 0 0 0 0 0 0 0 1178 5344 1117 3 2 95
0 0 0 3840448 4653744 16 45 0 0 0 0 0 0 0 0 0 1070 1013 952 1 3 96
0 0 0 3839168 4652720 6 53 0 0 0 0 0 0 0 0 0 564 575 313 0 6 93
0 0 0 3840208 4653752 7 68 0 0 0 0 0 3 0 0 0 1284 1014 1264 1 1 98
- スワップ -s
合計: 4341344k バイト割り当て済み + 675384k 予約済み = 5016728k 使用済み、3840880k 使用可能