Linux内核技术实战课
邵亚方
前蘑菇街技术专家,Linux Kernel活跃贡献者
新⼈⾸单¥9.9
2711 人已学习
课程目录
已更新 7 讲 / 共 23 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 如何让Linux内核更好地服务应用程序?
免费
Page Cache管理问题 (5讲)
01 基础篇 | 如何用数据观测Page Cache?
02 基础篇 | Page Cache是怎样产生和释放的?
03 案例篇 | 如何处理Page Cache难以回收产生的load飙高问题?
04 案例篇 | 如何处理Page Cache容易回收引起的业务性能问题?
免费
05 分析篇 | 如何判断问题是否由Page Cache产生的?
内存泄漏问题 (1讲)
06 基础篇 | 进程的哪些内存类型容易引起内存泄漏?
Linux内核技术实战课
15
15
1.0x
00:00/00:00
登录|注册

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

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

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

直接内存回收是指在进程上下文同步进行内存回收,那么它具体是怎么引起 load 飙高的呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux内核技术实战课》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥9.9
立即订阅
登录 后留言

精选留言(9)

  • 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
    1
    2
  • jssfy
    请问在虚机或者容器场景,vm.min_free_kbytes这一部分的空间建议预留还是也作为可分配空间呢?

    作者回复: 这个要看具体的业务类型,其实和虚拟机或者容器关系不大,如果虚拟机或者容器中的业务对延迟比较敏感,那你需要适当的调大这个值。

    2020-08-29
    1
  • 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
    1
  • 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
  • Jeff.Smile
    老师可以再解释下为什么调大min_free_kbytes会减少回收频率而降低延迟吗?而调小该值就会减少内存浪费呢?我的理解是增加min_free_kbytes之后,free剩余内存更大的时候就触发了回收,这不是增加回收频率了吗?

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

    2020-08-27
    1
  • 好说
    本文主要都是从写的角度来讲的,老师是否可以出一篇从读的角度讲的

    作者回复: 读的部分主要是page cache miss,在下一篇案例篇里会介绍几个读场景下的情况。

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

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

    2020-08-26
  • Geek1560
    老师,课程里可以拓展一下内存申请实现吗,比如内存不足,导致回收和swap等逻辑。或者有交流群吗?

    作者回复: 后面的案例篇会重点讲内存回收这部分。

    2020-08-25
  • yuwenvss
    docker容器里面的内存回收也会参考 vm.min_free_kbytes 等几个参数么?

    作者回复: docker中没有这个参数,但是有其他的类似机制:per memcg watermark。也有low,high,min这几个水位,单含义略有些不同,我们案例篇里也会提到。

    2020-08-25
收起评论
9
返回
顶部