前言
之前系統出現過幾次hung住的情況，沒有oom，也沒有其它內存相關的信息，而linux設計就是去盡量吃滿內存，然后再回收清理的機制
探討
目前這個參數還沒有找到合適的處理這個預留的參數，一般也沒有去調整的
系統是默認根據物理內存進行計算得到一個數值得
sysctl -a|grep min_free_kbytes
vm.min_free_kbytes = 45056
查看內核參數，這個小環境是保留的45M
網上的一些說法
Aerospike 的說法
https://discuss.aerospike.com/t/how-to-tune-the-linux-kernel-for-memory-performance/4195
The standard RedHat recommendation 204 is to keep min_free_kbytes at 1-3% of the total memory on the system, with Aerospike advising to keep at least 1.1GB, even if that is above the official recommended total memory percentage.
On a system with over 37GB of total RAM, you should leave no more than 3% of spare memory to min_free_kbytes in order to avoid the kernel spending too much time unnecessarily reclaiming memory. This would equal anywhere between 1.1GB and 3% of total RAM on such systems.
上面的說法是如果環境內存超過37G的情況下，按3%算就是1.1G，我們一般的環境也超過了40G，那么基本就是建議最少留個1.1G的，100G的可以保留到3G左右
內核參數
vm.min_free_kbytes = 1153434
vm.min_free_kbytes = 3145728
紅帽的說法
Setting min_free_kbytes too low prevents the system from reclaiming memory. This can result in system hangs and OOM-killing multiple processes.
However, setting min_free_kbytes too high (for example, to 5–10% of total system memory) causes the system to enter an out-of-memory state immediately, resulting in the system spending too much time reclaiming memory.
紅帽的說法是需要低於總內存的5%
ltp測試里面的參數控制
https://sourceforge.net/p/ltp/mailman/message/29738250/
Setting min_free_kbytes too high will cause system hangs,
especially in i386 arch, using less than 5% of total memory
can avoid it, so choose %5 of free memory or 2% of total memory.
Thanks Shuang pointed out it.
* Description:
*
* The case is designed to test min_free_kbytes tunable.
*
* The tune is used to control free memory, and system always
* reserve min_free_kbytes memory at least.
*
* Since the tune is not too large or too little, which will
* lead to the system hang, so I choose two cases, and test them
* on all overcommit_memory policy, at the same time, compare
* the current free memory with the tunable value repeatedly.
* a) default min_free_kbytes with all overcommit memory policy
* b) 2x default value with all overcommit memory policy
* c) 5% of MemFree or %2 MemTotal with all overcommit memory policy
測試用例里面測試內存過載情況下的幾種參數，默認，兩倍默認，5%空閑內存，或者總內存的2%，理論上，這幾個都不會導致機器hung死
其它知識
通過slabtop查看內核的緩存空間占用
[root@VM_0_17_centos ~]# slabtop -o|grep Total
Active / Total Objects (% used) : 550057 / 573695 (95.9%)
Active / Total Slabs (% used) : 22507 / 22507 (100.0%)
Active / Total Caches (% used) : 101 / 135 (74.8%)
Active / Total Size (% used) : 102508.62K / 106202.81K (96.5%)
[root@VM_0_17_centos ~]# grep Slab /proc/meminfo
Slab: 108676 kB
[root@VM_0_17_centos ~]# sysctl -a|grep min_free_kbytes
vm.min_free_kbytes = 45056
這個上面是騰訊雲主機的，看到內核自身的占用應該在100M以上了，而我自己的vmware里面的虛擬機這個數值是47MB，這個數值可能跟不同的內核有關
系統還保留了一定的內存防止
Reserving 161MB of memory at 688MB for crashkernel (System RAM: 2047MB)
系統啟動的時候看到的內存占用
[root@lab204 ~]# dmesg |grep Memory:
[ 0.000000] Memory: 1841584k/2097152k available (7784k kernel code, 524k absent, 255044k reserved, 5958k data, 1980k init)
內核文檔關於這個參數的解釋
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
min_free_kbytes:
This is used to force the Linux VM to keep a minimum number
of kilobytes free. The VM uses this number to compute a
watermark[WMARK_MIN] value for each lowmem zone in the system.
Each lowmem zone gets a number of reserved free pages based
proportionally on its size.
Some minimal amount of memory is needed to satisfy PF_MEMALLOC
allocations; if you set this to lower than 1024KB, your system will
become subtly broken, and prone to deadlock under high loads.
Setting this too high will OOM your machine instantly.
基於以上暫時推測
建議能保留1G以上的空間
變更記錄
| Why | Who | When |
|---|---|---|
| 創建 | 武漢-運維-磨渣 | 2020-09-09 |