ElasticSearchJVMの大きな仮想メモリサイズ
ElasticSearchをサポートするためにJVMを実行しています。私はまだサイジングとチューニングに取り組んでいるので、JVMの最大ヒープサイズをElasticSearchのデフォルトの1GBのままにしました。データベースにデータを配置した後、JVMのプロセスがtop出力で50GBのサイズを示していることがわかりました。これが実際にシステムのパフォーマンスの問題を引き起こしているようです。他のプロセスでメモリの割り当てに問題があります。
ElasticSearchコミュニティに尋ねたところ、彼らはそれが「単なる」ファイルシステムキャッシングであると提案しました。私の経験では、ファイルシステムのキャッシュは特定のプロセスで使用されるメモリとして表示されません。もちろん、彼らはOSのファイルシステムキャッシュ以外のこと、おそらくJVMまたはElasticSearch自体がOS上で行っていることについて話していたのかもしれません。しかし、彼らはまた、それが必要に応じてリリースされるだろうと言いました、そしてそれは起こっていないようでした。
したがって、RAMをあまり使用しないように、JVM、またはElasticSearch自体を調整する方法を誰かが理解するのを手伝ってくれる人はいますか？.
システムは、72GBのRAMを搭載したSolaris 10x86です。 JVMは「Java（TM）SEランタイム環境（ビルド1.7.0_45-b18）」です。
ElasticSearchコミュニティから得た答えは、ZFS ARC（Adaptive Replace Cache）に関連していると確信しています。もちろん、これはファイルシステムがZFSであることを前提としていますか？
ZFSでは、ARCはホストで使用可能なすべてのRAMを1Gb未満で占有する可能性があります。そのため、ZFSホストツールでは、topのように、物理的なRAMが制限に近いと表示されることがあります。これは仕様によるものです。 ARCは、メモリを必要とするプロセスにメモリを自動的に解放します。 ARCが使用するメモリはカーネルメモリとしてカウントされるため、プロセス出力で実際に確認することはできません。
私が毎日見ているほとんどのSolarisシステムでは、物理的なRAM消費量は約90％です。これは、それらが非常に利用されているためではなく、未使用のRAMを独自の目的で取得するのはZFSです。これに驚かないでください。 ARCはカーネルの一部であるため、いわば光速でそれを必要とするプロセスにメモリを解放できます。したがって、可能ではありますが、通常、ZFSARCのサイズを制限する意味はありません。 ZFSにその仕事を任せたほうがいいです。
したがって、ZFSについて話している場合は、そうです。ファイルシステムのキャッシュは、個々のプロセスのメモリ消費量として表示されません。次のようなものを実行する必要があります。
echo "::memstat" | mdb -k
あなたの記憶が実際にどのように使われているかを明らかにするために。 「Anon」の行は、たとえば、に表示されるすべてのユーザーランドプロセスをカバーしています。 prstat出力。
もう1つ知っておくべきことは、メモリの割り当てとメモリの解放に関してJVMがどのように機能するかです。 JVMは、JVM -Xmxコマンドラインパラメータによってのみ制限される必要があるため、OSからメモリを取得します。未解決の質問は、JVMがメモリを必要としなくなった場合にOSにメモリを解放する方法です。このテーマに関する情報を見つけるのは非常に難しいことがわかります。どのガベージコレクターを使用するかによるようです。この主題に関する正確な情報を取得することは難しいので（本当に理由はわかりません）、JVMが非常に消極的であると想定するのが最善の選択肢です。メモリをOSに戻します。言い換えると、JVMプロセスがたとえば50 GBのメモリを取得できるようにする場合は、想定するよりも、これを永続的に余裕のある位置に置く方がよいでしょう。これは単なるバーストです。
したがって、ElasticSearchプロセスが消費できるメモリの量を制限したい場合は、 JVMコマンドラインパラメータ 、特に-Xmxオプションを調べる必要があります。