問題タブ [memory-overcommitment]

以前に使用されていたが現在は必要ないメモリ用に、プロセスで予約された仮想アドレス空間を維持したいと考えています。ホスト カーネルが Linux であり、オーバーコミットを防ぐように構成されている状況に興味があります (これは、コミットされたすべてのメモリの詳細なアカウンティングによって行われます)。

アプリケーションが使用しなくなったデータが物理メモリを占有したり、ディスクにスワップされたりするのを防ぎたい場合 (いずれにしてもリソースを浪費する)、madvise不要なカーネルを削除するか、そのmmap上に新しいゼロ ページを重ねることができます。しかし、これらのアプローチのどちらも、コミット済みとしてカウントされるメモリの量を必ずしも削減するわけではなく、他のプロセスが使用できなくなります。

ページを読み取り専用としてマークされた新しいゼロ ページに置き換えるとどうなりますか? 私の意図は、それらがコミットされたメモリにカウントされず、後でmprotectそれらを書き込み可能にするために使用できること、およびそれらを書き込み可能にするとコミットされたメモリの制限を超えると失敗することです。私の理解は正しいですか？これは機能しますか？

これは、G++4.1.2を使用するCentOS64ビット上のC++にあります。

システムのメモリ使用量をnギガバイトでロードするテストアプリケーションを作成しています。システム全体の負荷はSNMPなどで監視されるという考え方です。したがって、これは監視を実行する方法にすぎません。

しかし、私たちが見たのは、単に次のことをしているということです。

topまたはfree-mに示されているように、使用されるメモリには影響しません。

メモリ割り当ては、メモリが次の場所に書き込まれると「実際」になるように見えます。

ただし、すべてのメモリに書き込む必要があります。最初の要素に書き込むだけでは、使用されるメモリの増加は示されません。

これは正常ですか、メモリは実際に完全に割り当てられていますか？使用しているツール（topおよびfree -m）が誤った値を表示しているのか、コンパイラー、ランタイム、カーネルで何か巧妙なことが起こっているのかはわかりません。

この動作は、最適化がオフになっているデバッグビルドでも見られます。

new[]がすぐにメモリを割り当てたのは私の理解でした。C ++ランタイムは、後でアクセスされるまで、この実際の割り当てを遅らせますか？その場合、メモリが実際に割り当てられてからメモリにアクセスするまで、メモリ不足の例外を延期できますか？

それは私たちにとって問題ではありませんが、なぜこれがこのように起こっているのかを知ることは素晴らしいことです！

乾杯！

編集：

ベクターをどのように使用すべきか知りたくありません。これはOO/C ++ /現在のやり方などではありません。提案をするのではなく、なぜこれが現在のように行われているのかを知りたいだけです。それを試す別の方法について。

sysctl を介してシステム全体でメモリ オーバーコミット ポリシーを調整できますが、プロセス自体からプロセスごとにこのポリシーを調整することは可能ですか? システムの残りの部分はオーバーコミットできますが、特定のリアルタイムプロセスでオーバーコミットを使用しないようにしたいと考えています。

メモリチャンクを割り当てようとして、メモリがすぐに利用できない場合にエラーが発生する方法はありますか？

calloc（）は、割り当てられたメモリ全体にすぐにアクセスするため、適切な候補のように見えますが、NULLを返すのではなく、プロセスを強制終了すると思います。

他のオプションはありますか？

親プロセスが子プロセスを fork しようとすると、errno=12 (メモリ不足) で失敗します。親プロセスは Linux 3.0 カーネル - SLES 11 で実行されます。子プロセスをフォークする時点で、親プロセスはすでに RAM の約 70% (180GB/256GB) を使用しています。この問題の回避策はありますか?

アプリケーションは C++ で作成され、g++ 4.6.3 でコンパイルされています。

malloc が失敗するかどうかを判断する悲観的な方法はありますか。私はこれについて少し心配しています：

デフォルトでは、Linux は楽観的なメモリ割り当て戦略に従います。これは、malloc() が非 NULL を返す場合、メモリが実際に使用可能であるという保証がないことを意味します。システムのメモリが不足していることが判明した場合、1 つまたは複数のプロセスが OOM キラーによって強制終了されます。詳細については、proc(5) の /proc/sys/vm/overcommit_memory および /proc/sys/vm/oom_adj の説明、および Linux カーネル ソース ファイル Documentation/vm/overcommit-accounting を参照してください。

この免責事項を知らなかった場合は、malloc が成功するかどうかだけを確認します。

私の場合、アプリケーションは大きなデータ ブロック (ギガバイト) を割り当てる必要があるため、メモリが制約になります。Gimp は、構成ダイアログを介してユーザーにすべての責任を移します。ソフト上限を推測するものが欲しいです。

KVM セットアップ (ホストとゲストの両方) に対する CPU オーバーコミットの影響を測定しようとしています。vCPU の数が増えるとパフォーマンスが低下することを検出できますが、理想的には、より客観的なメトリック (esxtop の CPU Ready など) を調べたいと考えています。同様のメトリックを提供する KVM の esxtop に相当するものはありますか。