vm.overcommit_ratioの残りのメモリはどこに行きますか?

vm.overcommit_ratioの残りのメモリはどこに行きますか?

vm.overcommit_memory設定でメモリオーバーコミットを無効にすると、デフォルトではシステムは2以下のようにスワップディメンション+物理メモリの50%までのメモリ割り当てを許可します。ここ

パラメータを変更してスケールを変更できますvm.overcommit_ratio。 80%に設定したと仮定すると、物理メモリの80%を使用できます。

私の質問は次のとおりです

  • 残りの20%でシステムは何をしますか?
  • もともとこのパラメータがなぜ必要ですか?
  • なぜ常に100%に設定しないのですか?

答え1

残りの20%でシステムは何をしますか?

カーネルは、残りの物理メモリを独自の目的(内部構造、テーブル、バッファ、キャッシュなど)として使用します。メモリ再利用設定は、ユーザ空間アプリケーションの仮想メモリ予約を処理します。カーネルは仮想メモリではなく物理メモリを使用します。

もともとこのパラメータがなぜ必要ですか?

このovercommit_ratioパラメータは、アプリケーションが将来的に合理的に使用できるよりも多くの仮想メモリを保持しないようにするために設計された実装の選択です。つまり、実際にメモリにアクセスするとき(または少なくともアクセスを試みるとき)です。

Linuxカーネル開発者は、50%の設定をovercommit_ratio合理的なデフォルトと見なします。カーネルは物理RAMの50%以上を使用する必要はないと仮定します。マイレージは様々であるため調整が可能です。

なぜ常に100%に設定しないのですか?

100%(または「高すぎる」値)に設定しても、カーネルがRAMを0%(または少なすぎる)使用すると想定できないため、超過コミットを確実に無効にすることはできません。

カーネルが必要なすべての物理メモリを占有できるため、アプリケーションがクラッシュするのを防ぐことはできません。

答え2

比率を100%に設定すると、ファイルのバックアップページやカーネル割り当て(カーネルコード、ネットワークバッファなど)用のスペースは予約されません。

それにもかかわらず、カーネル構造が割り当てられ、過度のコミットが発生します。通常は個別に制限されます(たとえば、ネットワークバッファ設定があります)。全体の制限はコンテナホスティングのものですが、全体の制限は50%だとは思いません。

ファイルサポートページは通常ユーザースペースコードを実行する場所なので、スペースも必要です。

関連情報