在较高的Linux版本上，支持了watermark_scale_factor参数（完整路径/proc/sys/vm/watermark_scale_factor）调整，这个数值可以比较有效的控制内存回收。

在这里，描述一下使用的过程中，作者遇到过几个问题。

min_free_kbytes过小的问题

在分析watermark_scale_factor之前，我们先来看一下vm调整的另外一个参数min_free_kbytes。

从代码的注释以及计算的过程我们可以知道，这个数值最小128，最大65536。在PC上也许还可用，但是在动辄256G甚至1T的服务器，最大64M这个数值显然是太小了，四舍五入约等于没有了。在大规格的服务器上，如果想要维持较高的可用内存，靠min_free_kbytes显然是不靠谱的。

watermark_scale_factor的调整效果

在内核的文档中，我们看下这个参数的描述：

This factor controls the aggressiveness of kswapd. It defines theamount of memory left in a node/system before kswapd is woken up andhow much memory needs to be free before kswapd goes back to sleep.

The unit is in fractions of 10,000. The default value of 10 means the

distances between watermarks are 0.1% of the available memory in the

node/system. The maximum value is 1000, or 10% of memory.

A high rate of threads entering direct reclaim (allocstall) or kswapd

going to sleep prematurely (kswapd_low_wmark_hit_quickly) can indicatethat the number of free pages kswapd maintains for latency reasons istoo small for the allocation bursts occurring in the system. This knobcan then be used to tune kswapd aggressiveness accordingly.

我们在继续看一下具体的计算过程：

在服务器总内存比较大的情况下，忽略min watermark的数值。那么，zone的low watermark是zone的总内存的万分之watermark_scale_factor，而zone的high watermark是zone的min watermark的两倍。

所以，watermark_scale_factor的效果就是按照比例来计算water matermark的数值，而非是按照大小来计算。在总内存比较大的情况下，依然可以计算出来比较有效的内存watermark数值。

MemFree和MemAvailable之间的关系

cat /proc/meminfo的输出结果中，会有MemFree和MemAvailable。

其中MemFree就是真正的free memory，没有被内核/进程使用过的内存页面。

MemAvailable计算相对复杂，它的主要思路是：free memory – reserved memory + 部分page cache + 部分slab。

而reserved memory的数量几乎就是上文提到的high watermark。所以，如果high watermark比较大的情况下会出现一种场景：free memory比较多，但是available memory不是很多而导致了进程的OOM。

场景一，存储类型服务使用page cache使用较多带来的延迟问题

在对象存储或者其他的存储场景下，会使用大量的page cache。而Linux使用内存的策略比较贪婪，尽量分配，不够了再回收。而默认的回收的阈值比较低，总内存较大的场景下，buddy system中进程缺少较大块的连续内存。而在特定的场景下，例如TCP发送数据的过程中，会有特定的逻辑需要使用大块连续内存，那么就需要先回收内存做compaction，再继续发送数据，从而造成了延迟抖动。

那么，我们可以调整watermark_scale_factor到较大的数值，内核因此会回收内存较为激进，维持较高的free memory，业务的延迟会相应的变好。同时，思考另外一个问题，就是较高的watermark_scale_factor值会导致available memory较少，更加容易发生OOM。

场景二，在线/离线混合部署场景下的干扰问题

通常情况下，在线业务会处理网络请求进行应答，磁盘IO基本就是少量的log，产生不多的page cache。

而离线业务会从远端获取数据进行计算，保存临时结果，再把最终结果返回给中心节点。那么就会产生很多的page cache。

大量的page cache会消耗掉free memory，会让在线业务的内存申请陷入到慢路径中而影响了在线业务的延迟。为此，也需要适当的调整watermark_scale_factor，思路还是让内核保持较高的内存水线，但是也需要避免OOM。