专栏首页皮振伟的专栏[Linux][mm]watermark_scale_factor的调整以及遇到的问题

[Linux][mm]watermark_scale_factor的调整以及遇到的问题

前言

在较高的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。

本文分享自微信公众号 - AlwaysGeek(gh_d0972b1eeb60),作者:AlwaysGeek

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-06-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Linux分区页框分配器之水位

    我们讲页框分配器的时候讲到了快速分配和慢速分配,其中伙伴算法是在快速分配里做的,忘记的小伙伴我们再看下:

    刘盼
  • Android9.0 mm编译遇到的一些问题

    --------------------------------------------------------------------------------...

    小驰笔记
  • linux python 遇到的问题

    CentOS 6.5默认只安装了readline模块而没有安装readline-devel模块,所以只要安装下即可

    py3study
  • [linux][fuse]fuse技术分析以及遇到的问题

    前言: 简单看了一下glusterfs,使用单节点构造glusterfs环境,导出的路径是是本地SSD在分区上。用qemu挂载glusterfs上的卷,用FIO...

    皮振伟
  • mybatis 缓存总结以及遇到的问题

    转载自https://blog.csdn.net/yin767833376/article/details/80537695

    allsmallpig
  • 【iOS】记录iOS14以及xcode12 遇到的问题

    问题描述: 内购完成会,会受到以下回调,一般我们会通过payment的applicationusername用于关联我们的orderId等信息,但是在iOS1...

    MapleYe
  • phpstudy升级mysql5.7以及遇到的问题汇总

    最近学习java的时候建数据库,用到了create_time和update_time,我想设置成current_time,但是在mysql5,7之前貌似不支持...

    听城
  • node.js调用webservice遇到的问题

    Marser
  • 二叉树的遍历以及遇到的一些问题

    这里以二叉树的前序遍历为例。输入前序遍历的数据元素(以空格作为空元素),构造二叉树,然后遍历二叉树输出每个数据元素所在的层。

    卡尔曼和玻尔兹曼谁曼

扫码关注云+社区

领取腾讯云代金券