vm.min_free_kbytesのしくみ
システム自体が適切に機能するようにするために、システムでメモリの割り当てが必要になる場合があります。カーネルがすべてのメモリの割り当てを許可している場合、OSをスムーズに実行し続けるために通常の操作のためにメモリが必要になると、問題が発生する可能性があります。これが、カーネルが調整可能なvm.min_free_kbytesを提供する理由です。チューナブルは、カーネルのメモリマネージャに少なくともX個の空きメモリを保持するように強制します。これがからの公式の定義です Linuxカーネルのドキュメント ：これは、LinuxVMに最小キロバイト数を空けておくように強制するために使用されます。 VMはこの数値を使用して、システム内の各lowmemゾーンのウォーターマーク[WMARK_MIN]値を計算します。各lowmemゾーンは、そのサイズに比例して、予約された空きページの数を取得します。 PF_MEMALLOC割り当てを満たすには、最小限のメモリが必要です。これを1024KB未満に設定すると、システムが微妙に壊れ、高負荷でデッドロックが発生しやすくなります。これを高く設定しすぎると、すぐにマシンがOOMになります。
vm.min_free_kbytesの動作の検証
min_free_kbytesの設定が設計どおりに機能していることをテストするために、3.75GBのRAMのみを備えたLinux仮想インスタンスを作成しました。以下のfreeコマンドを使用して、システムを分析します。
＃自由 -NS
上記の空きメモリユーティリティを見て、-mフラグを使用して、値をMB単位で出力します。合計メモリは3.5〜3.75GBのメモリです。 121 MBのメモリが使用され、3.3 GBのメモリが解放され、251MBがバッファキャッシュによって使用されます。また、3.3GBのメモリが利用可能です。
次に、vm.min_free_kbytesの値を変更して、システムメモリにどのような影響があるかを確認します。新しい値をproc仮想ファイルシステムにエコーして、以下のようにカーネルパラメータ値を変更します。
＃echo 1500000> / proc / sys / vm / min_free_kbytes＃sysctl vm.min_free_kbytes
パラメータが約1.5GBに変更され、有効になっていることがわかります。それでは、 自由 もう一度コマンドを実行して、システムによって認識された変更を確認します。
＃自由 -NS 
空きメモリとバッファキャッシュはコマンドによって変更されませんが、メモリの量は次のように表示されます 利用可能 3327MBから1222MBに削減されました。これは、パラメータの変更を1.5GBの最小空きメモリにおよそ削減したものです。
次に、2 GBのデータファイルを作成し、そのファイルをバッファキャッシュに読み込むと値がどうなるかを見てみましょう。以下の2行のbashスクリプトで2GBのデータファイルを作成する方法を次に示します。スクリプトは、ddコマンドを使用して35MBのランダムファイルを生成し、それを70回新しいファイルにコピーします。 データファイル 出力：
＃dd if = / dev / random of = / root / d1.txt count = 1000000＃ `seq 170`のiの場合; $ iをエコーします。 cat /root/d1.txt >> / root / data_file;終わり
以下のようにファイルを読み取って/ dev / nullにリダイレクトすることにより、ファイルを読み取り、内容を無視しましょう。
＃猫データファイル>> /開発者/ヌルさて、この一連の操作でシステムメモリに何が起こったのか、今すぐ確認しましょう。
＃自由 -NS 
上記の結果を分析します。まだ1.8GBの空きメモリがあるため、min_free_kbytes設定により、カーネルはメモリの大部分を予約済みとして保護しています。バッファキャッシュは1691MBを使用しました。これは、データファイルの合計サイズである2.3GBよりも小さい値です。どうやら全体 データファイル バッファキャッシュに使用できるメモリが不足しているため、キャッシュに保存できませんでした。ファイル全体がキャッシュに保存されていないことを検証できますが、ファイルの読み取りを繰り返し試行するタイミングを計ることができます。キャッシュされている場合、ファイルの読み取りには数分の1秒かかります。試してみよう。
＃time cat data_file> / dev / null＃time cat data_file> / dev / null
ファイルの読み取りには約20秒かかりました。これは、ほぼ確実にすべてがキャッシュされているわけではないことを意味します。
最後の検証の1つとして、vm.min_free_kbytesを減らして、ページキャッシュが動作する余地を増やし、キャッシュが機能し、ファイルの読み取りがはるかに高速になることを期待できます。
＃echo 67584> / proc / sys / vm / min_free_kbytes＃time cat data_file> / dev / null
＃time cat data_file> / dev / null
キャッシュに使用できる追加のメモリを使用すると、ファイルの読み取り時間が前の20秒から.364秒に短縮され、すべてがキャッシュに保存されます。
別の実験をしたいと思っています。この非常に高いvm.min_free_kbytes設定に直面して、Cプログラムからメモリを割り当てるmalloc呼び出しで何が起こるか。それはmallocに失敗しますか？システムは死にますか？まず、vm.min_free_kbytes設定を非常に高い値にリセットして、実験を再開します。
＃捨てた 1500000 >> /パーセント/sys/vm/min_free_kbytes空きメモリをもう一度見てみましょう。
理論的には、1.9 GBが無料で、515MBが利用可能です。メモリを使用してどこで失敗するかを確認するために、stress-ngと呼ばれるストレステストプログラムを使用してみましょう。 vmテスターを使用して、1GBのメモリを割り当てようとします。 3.75GBシステムでは1.5GBしか予約していないので、これでうまくいくと思います。
＃stress-ng --vm 1 --vm-bytes 1G --timeout 60sストレス：情報：[17537]豚の派遣：1vm
ストレス：情報：[17537]キャッシュ割り当て：デフォルトのキャッシュサイズ：46080K
ストレス：情報：[17537]正常に実行が完了しましたの60.09秒（（1分、0.09ドライ）。
＃stress-ng --vm 2 --vm-bytes 1G --timeout 60s
＃stress-ng --vm 3 --vm-bytes 1G --timeout 60s
より多くのワーカーでもう一度試してみましょう。1、2、3、4のワーカーを試すことができますが、ある時点で失敗するはずです。私のテストでは、1人と2人の労働者で合格しましたが、3人の労働者で失敗しました。
vm.min_free_kbytesを低い数値にリセットして、3.75GBシステムでそれぞれ1GBの3つのメモリストレッサーを実行するのに役立つかどうかを確認しましょう。
＃echo 67584> / proc / sys / vm / min_free_kbytes＃stress-ng --vm 3 --vm-bytes 1G --timeout 60s
今回はエラーなしで正常に実行されましたが、問題なく2回試しました。したがって、vm.min_free_kbytes値がより低い値に設定されている場合、mallocで使用可能なメモリを増やすことには動作上の違いがあると結論付けることができます。
vm.min_free_kbytesのデフォルト設定
私のシステムの設定のデフォルト値は67584で、これはシステムのRAMの約1.8％または64MBです。ひどくスラッシングされたシステムの安全上の理由から、予約済みの空きメモリを増やすために、おそらく128MBに少し増やす傾向がありますが、平均的な使用量では、デフォルト値で十分です。公式ドキュメントは、値を高くしすぎることについて警告しています。システムRAMの5％または10％に設定することは、おそらく設定の意図された使用法ではなく、高すぎます。
再起動後も存続するようにvm.min_free_kbytesを設定する
設定が再起動後も存続し、再起動時にデフォルト値に復元されないようにするには、/ etc / sysctl.confファイルに目的の新しい値を入力して、sysctl設定を永続的にするようにしてください。
結論
vm.min_free_kbytes linuxカーネルチューナブルを変更して、システムのメモリを予約して、特に大量の使用や大量のメモリ割り当て時にシステムをより安定させることができることを確認しました。特にメモリの多いシステムでは、デフォルト設定が少し低すぎる可能性があるため、慎重に増やすことを検討する必要があります。このチューナブルによって予約されたメモリは、OSキャッシュがすべてのメモリを使用するのを防ぎ、一部のmalloc操作もすべてのメモリを使用するのを防ぎます。