Linux 内核技术实战课
邵亚方
前蘑菇街技术专家,Linux Kernel 活跃贡献者
23704 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 26 讲
Linux 内核技术实战课
15
15
1.0x
00:00/00:00
登录|注册

03 案例篇 | 如何处理Page Cache难以回收产生的load飙高问题?

调整vm.dirty配置项
观察脏页个数
调整extra_free_kbytes
调整min_free_kbytes
触发后台回收
模拟程序构造直接内存回收场景
观察业务服务质量
调整系统参数/配置
内存回收类比
调整zone_reclaim_mode
观察NUMA信息
推荐配置为0
zone_reclaim_mode
控制脏页数据
脏页回写延迟
解决方案
内存回收过程
系统NUMA策略配置不当
脏页积压
直接内存回收
系统load飙高
应用程序RT变高或抖动
命令响应慢
系统卡顿
课后作业
课堂总结
系统NUMA策略配置不当引起load飙高
系统中脏页过多引起load飙高
直接内存回收引起load飙高或业务时延抖动
原因
问题情形
如何处理Page Cache难以回收产生的load飙高问题

该思维导图由 AI 生成,仅供参考

你好,我是邵亚方。今天这节课,我想跟你聊一聊怎么处理在生产环境中,因为 Page Cache 管理不当引起的系统 load 飙高的问题。
相信你在平时的工作中,应该会或多或少遇到过这些情形:系统很卡顿,敲命令响应非常慢;应用程序的 RT 变得很高,或者抖动得很厉害。在发生这些问题时,很有可能也伴随着系统 load 飙得很高。
那这是什么原因导致的呢?据我观察,大多是有三种情况:
直接内存回收引起的 load 飙高;
系统中脏页积压过多引起的 load 飙高;
系统 NUMA 策略配置不当引起的 load 飙高。
这是应用开发者和运维人员向我咨询最多的几种情况。问题看似很简单,但如果对问题产生的原因理解得不深,解决起来就会很棘手,甚至配置得不好,还会带来负面的影响。
所以这节课,我们一起来分析下这三种情况,可以说,搞清楚了这几种情况,你差不多就能解决掉绝大部分 Page Cache 引起的 load 飙高问题了。如果你对问题的原因排查感兴趣,也不要着急,在第 5 讲,我会带你学习 load 飙高问题的分析方法。
接下来,我们就来逐一分析下这几类情况。

直接内存回收引起 load 飙高或者业务时延抖动

直接内存回收是指在进程上下文同步进行内存回收,那么它具体是怎么引起 load 飙高的呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了生产环境中由Page Cache管理不当引起的系统load飙高问题,并提出了针对直接内存回收、脏页积压、系统NUMA策略配置不当等情况的解决方案。针对直接内存回收引起的load飙高和业务时延抖动问题,建议调整内存水位,增大min_free_kbytes配置选项或将extra_free_kbytes配置为4G。对于系统中脏页过多引起的load飙高,建议通过控制系统中积压的脏页数据,调整vm.dirty_background_bytes等配置项,并观察业务的服务质量。此外,文章还提到了系统NUMA策略配置不当引起的load飙高问题,建议将zone_reclaim_mode配置为0以避免内存回收引发的业务延迟。通过深入分析和解决方案的探讨,为读者提供了解决Page Cache引起的load飙高问题的实用建议。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Linux 内核技术实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(26)

  • 最新
  • 精选
  • test
    系统load飙高: 1.直接内存回收: 观察:sar -B中pgscank/s、pgscand/s表示扫描的页面数量,前者表示kswapd扫描结果,后者表示直接扫描。需要让直接扫描越小越好。 解决:设置vm.min_free_kbytes,尽早开始后台回收。 2.脏页积压: 观察:sar -r中kbdirty即是脏页大小。 解决:设置vm/dirtyxxx控制脏页个数在合理范围内。 3.NUMA设置不合理: 观察:numactl --hardware查看是否还有一半内存空闲,但是还是频频发生direct reclaim。 解决:vm.zone_reclaim_mode = 0

    作者回复: 赞!

    2020-08-30
    26
  • lookzy
    老师您好!我们都说剩余内存达到low水位时,就会进行内存回收。但每个zone都有水位,剩余内存是指某个zone里的剩余内存,还是node,还是整个系统的剩余内存?还有内存回收只针对当前zone,还是node,还是整个系统?谢谢!

    作者回复: 这是三个不同的维度:系统 -> node -> zone。我们调整的水位最终是提现在zone上,回收也是针对zone的。进程在申请内存时其实是会指定zone的,只是应用程序并不感知这个细节,对应用程序而言,它申请的内存一般都是normal zone,那么当normal zone中的剩余内存不足时就会触发回收;这里面又会涉及到node概念,假设有2个node,node 0的normal zone里剩余内存不足了就会唤醒kswapd0来回收node 0里normal zone的内存,但是此时应用是可以去继续申请node 1的normal zone的内存的(如果没有配置numa策略),如果node 1的normal zone剩余内存也不足了,那会唤醒kswapd1来回收node 1的normal zone。

    2020-08-27
    2
    13
  • xzy
    你好请教个问题:我们线上出现 kswapd0 占用 cpu 较高,free -h 看了available 的内存不到 1g,应该是可用内存太少触发了 kswapd0 回收内存。我们关闭了 swap,vmstat -s 没发现 page 换入换出,但是用 iotop 却发现大量进程 io 很高(这些业务进程并没有 io 的逻辑),请问这种情况如何定位,是否是 kswapd0 导致的

    作者回复: kswapd占用cpu高就意味着回收很困难,也就是系统中存在大量不可回收的内存,或者pagecache的回收较困难,比如脏页太多。kswapd本身回进行脏页的回写,但是iotop可以看到是kswapd在进行io;如果是业务进程io高,那有可能是因为它的page cache被回收掉,导致它不得不再次从磁盘来读数据,这个时候应该有很多pagein才会。你也可以观察下workingset refault,看看这个指标是否也高。

    2020-08-27
    10
  • piboye
    老师有个dirty page的问题想请教一下。 1创建文件;2写入日志数据,3 移除文件;4 关闭文件。我想知道这种情况情况下dirty page还会去刷盘不?

    作者回复: 这是个好问题。 首先我们假设这个文件只有这一个进程打开。 如果是先关闭文件,再移除文件,那么移除文件时就会把这些dirty page释放掉,无需刷盘。 如果是先移除文件,那么在移除文件时由于该文件还有引用(还没有close),那么这些dirty pages还是会保留在内存中,接下来如果系统内存紧张了,就会触发回收内存,回收的过程中就可能会回写这些dirty pages,也就是说删除文件只是path不在了但是inode还在;如果没有回收行为发生,那么就不会去回写这些dirty pages,等close的时候就会把这些dirty pages释放掉。 另外 ,你说的这个使用文件的方式是进程创建临时文件的方法,也就是进程意外退出后不留下文件痕迹的方法。

    2020-09-23
    4
    8
  • J.Smile
    老师可以再解释下为什么调大min_free_kbytes会减少回收频率而降低延迟吗?而调小该值就会减少内存浪费呢?我的理解是增加min_free_kbytes之后,free剩余内存更大的时候就触发了回收,这不是增加回收频率了吗?

    作者回复: 调大min_free_kbytes其实是为了更早唤醒kswapd,从而避免直接回收,它降低的是直接回收的频率,会增加了kswapd后台回收的频率。对应用而言,直接回收会导致它的延迟,这个危害较大;如果后台回收太频繁,那后台回收线程kswapd可能会跟应用抢cpu,这也会间接影响应用,只是没那么明显,但也尽量要避免kswapd太消耗cpu,也就是不能把min_free_kbytes设置太大,合适就好。

    2020-08-27
    2
    6
  • Cooper
    您好,请教一下,我以前单位部署多个小场景服务器, node写的,每个服务有最大服务(内存)上限,当时服务部署是将进程绑定指定cpu,1个内核2进程,请问这个设计是否是为了muna 策略,把zone_reclaim_mode设置1,如果是,这样对性能提升有帮助吗?

    作者回复: 进程绑定主要是减少调度开销以及cpu争抢,另外也可以提升cache命中率,将进程绑定后也可以更好的使用numa。理论上设置为1是会提升性能的,还要看node的kswapd是否能够及时回收内存,如果不能,那么设置为1反而会降低性能。

    2020-10-06
    3
  • 咸鱼
    老师,请教下改变内存水位为什么会影响内存可使用量

    作者回复: 比如说min水位,这部分内存只有在部分场景下才能申请,是为了应对紧急内存申请,比如说atomic这种申请方式。那么min水位之下的内存,对于应用程序而言,就是无法申请的。

    2020-08-26
    3
  • 金时
    老师您好,文中说的第一种情况“直接内存回收引起 load 飙高或者业务时延抖动“, 和第二种情况“系统中脏页过多引起 load 飙高“, 不太理解这两种情况的区别。 第一种情况回收的“内存“,这里的“内存”不是指第二种情况的“脏页”吗

    作者回复: 包括脏页,可以理解为第二种情况是第一种情况的子集。 在直接内存回收时,可能系统中脏页很少,但是其他情况也会引起延迟,比如说内存规整(即系统内存碎片很严重时)。

    2021-06-18
    2
  • jaxzhai
    kernel: INFO: task kswapd0:224 blocked for more than 120 seconds. 这段时间大数据系统,进程出现这种情况,之后kswapd0进程变成僵尸进程了

    作者回复: 这是什么内核版本?这个现象可以复现吗?如果可以的话。你可以使用sysrq把线程栈打印出来看看,根据线程栈就可以大概做出判断。 另外内核线程是不会变成僵尸进程的,你指的应该是kswapd变成了D状态?

    2021-02-02
    2
  • 蛋卷儿
    请教老师,kswapd和direct reclaim如果都是把内存回收到zone里high的水位,那么如果某一次内存申请数量大于zone的high值,是否就会导致os kill?我们线上机器的zone normal high是46M,那某次申请内存超过46Mb是不是就挂了?

    作者回复: memory watermark主要是用来内存回收用的。在申请内存时,主要是看空闲内存(free list)是否足够,如果足够就可分配,如果不够的话,会先触发回收/规整,然后如果还不能分配到足够内存的话,就可能会产生oom。 所以zone normal high和触发os kill并没有直接关系。

    2020-11-24
    2
收起评论
显示
设置
留言
26
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部