Linux でオーバーコミットせずにメモリを割り当てる方法
それはよくある質問か、少なくとも間違った質問です。質問は誤った仮定に基づいているため、記載された質問への回答は、せいぜい無関係であり、最悪の場合誤解を招きます。
メモリのオーバーコミットはシステム全体のポリシーであり、プロセスが使用できる仮想メモリの量を決定するため、プロセスが独自に決定できるものではありません。
メモリがオーバーコミットされているかどうかは、システム管理者が判断します。 Linux では、ポリシーは非常に調整可能です (例:/proc/sys/vm/overcommit_memory を参照)。 男5 procで。 メモリのオーバーコミット ポリシーに影響を与える割り当て中にプロセスが実行できることは何もありません .
OP は、Linux のメモリ不足キラー (OOM キラー) からプロセスを保護することにも関心を持っているようです。 (Linux の OOM キラーは、プロセスを強制終了してリソースをシステムに解放することにより、メモリの負荷を軽減するために使用される手法です。)
OOM キラーはヒューリスティックなプロセスであり、その目的は「動作の悪いプロセスを罰したり強制終了したりする」ことではなく、システムの運用を維持することであるため、これも不適切なアプローチです。この機能は Linux でも非常に調整可能であり、システム管理者は、メモリ負荷が高い状況で各プロセスが強制終了される可能性を調整することもできます。プロセスが使用するメモリの量を除けば、メモリ不足の状況で OOM キラーがプロセスを強制終了するかどうかに影響を与えるのはプロセス次第ではありません;これもシステム管理者が管理するポリシーの問題であり、プロセス自体ではありません。
OPが解決しようとしている実際の問題は、（SIGSEGVまたはOOMキラーによる）ただ死ぬだけでなく、メモリ不足に動的に対応できるLinuxアプリケーションまたはサービスを作成する方法であると想定しました。これに対する答えは、しない です。 -- 代わりに、システム管理者に彼らの作業負荷の中で何が重要かを心配させます -- ただし、アプリケーションまたはサービスが大量のメモリを使用するものであり、メモリの使用量が多いときに不当に強制終了される可能性がある場合は除きます。プレッシャー。 (特に、データセットが十分に大きく、他の方法で有効にするよりもはるかに大量のスワップを有効にする必要がある場合は、スワップ ストームのリスクが高くなり、遅すぎるが強力な OOM キラーが発生します。)
解決策、または少なくとも機能するアプローチは、重要な部分（または、ディスクにスワップされるべきではない機密データで機能する場合はアプリケーション/サービス全体）をメモリロックするか、メモリマップを使用することです専用のバッキング ファイル。 (後者については、私が 2011 年に書いた、テラバイト サイズのデータ セットを操作する例を次に示します。)
すべてのアプリケーションが RAM にロックされていない限り、OOM キラーは引き続きプロセスを強制終了することができ、SIGSEGV は引き続き発生します (たとえば、カーネルが RAM バッキングを提供できないライブラリ関数による内部割り当てのため)。サービス/プロセスはもはや不当ではありません 大量のメモリを使用するという理由だけでターゲットを絞っています。
SIGSEGV シグナル (仮想メモリをバックアップするために使用できるメモリがない場合に発生) をキャッチすることは可能ですが、これまでのところ、コードの複雑さと必要なメンテナンス作業を正当化するユース ケースは見当たりませんでした。
要約すると、上記の質問に対する適切な答えは、いいえ、そうしないでくださいです。 .