Linux关于memory cgroup的几个要点

这篇具有很好参考价值的文章主要介绍了Linux关于memory cgroup的几个要点。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

概述

本文讲述memory cgroup比较容易误解的一些逻辑,如果不太经常使用和解决问题的话,对于memory cgroup的认知会比较浅显:cgroup memory用来限制进程的内存使用,但是我们进一步想如下的问题:

  1. 进程的内存可以分很多类型,比如page cache,slab,anon memory等,到底是限制的哪些内存?
  2. 如果进程A已经运行起来占用了一些内存,之后,再将A加入memory cgroup限制,原来占用的内存会统计入新的memory cgroup?
  3. memory cgroup有memory.soft_limit_in_bytes和memory.limit_in_bytes,假设进程使用内存超过这两个限制,内存回收时机和路径是怎么样的?
  4. 我们知道内核回收页面采用lru算法,同时memcg也有per node lru,这两个lru是什么关系?

被误解的cgroup内存限制

结论:Cgroup 内存范围包括进程RSS 及该进程首次触发加载进Page Cache 所占用的内存,但不包括Slab 部分。

我们怎么从源码确认page cache是被cgroup限制的呢?charge逻辑:我们知道新页面产生的时候,内核会charge增加cgroup内存使用的统计,所以最直接的方式我们看下read或者write产生page cache是否存在charge逻辑,如果存在说明进程pagecache也是被cgroup限制的。

Linux关于memory cgroup的几个要点,内存子系统,linux,运维,服务器

上述函数的调用栈:

#0  try_to_free_mem_cgroup_pages (memcg=0xffff8880009ba000, nr_pages=1, gfp_mask=1125578, may_swap=true) at mm/vmscan.c:3326
#1  0xffffffff81422729 in try_charge (memcg=0xffff8880009ba000, gfp_mask=<optimized out>, nr_pages=<optimized out>) at mm/memcontrol.c:2703
#2  0xffffffff81425f56 in mem_cgroup_charge (page=0xffffea0000019240, mm=<optimized out>, gfp_mask=<optimized out>) at mm/memcontrol.c:6718
#3  0xffffffff8132bed0 in __add_to_page_cache_locked (page=0xffffea0000019240, mapping=0xffff888002826330, offset=65, gfp_mask=1125578, shadowp=0xffff888000b27650) at ./arch/x86/include/asm/current.h:15
#4  0xffffffff8132c224 in add_to_page_cache_lru (page=0xffffea0000019240, mapping=0xffff888002826330, offset=65, gfp_mask=1125578) at mm/filemap.c:922
#5  0xffffffff81344d9b in page_cache_readahead_unbounded (mapping=<optimized out>, file=<optimized out>, index=65, nr_to_read=<optimized out>, lookahead_size=<optimized out>) at mm/readahead.c:228
#6  0xffffffff81344eeb in __do_page_cache_readahead (mapping=0xffff888002826330, file=0xffff8880054fca00, index=<optimized out>, nr_to_read=32, lookahead_size=32) at mm/readahead.c:273
#7  0xffffffff8134518f in ra_submit (filp=<optimized out>, mapping=<optimized out>, ra=<optimized out>) at mm/internal.h:64
#8  ondemand_readahead (mapping=0xffff888002826330, ra=0xffff8880054fca98, filp=<optimized out>, hit_readahead_marker=<optimized out>, index=64, req_size=<optimized out>) at mm/readahead.c:551
#9  0xffffffff813454cd in page_cache_async_readahead (page=<optimized out>, req_count=<optimized out>, index=<optimized out>, filp=<optimized out>, ra=<optimized out>, mapping=<optimized out>)
    at mm/readahead.c:631
#10 page_cache_async_readahead (mapping=0xffff888002826330, ra=0xffff8880054fca98, filp=<optimized out>, page=0xffffffff8332f0b0 <cgrp_dfl_root+16>, index=<optimized out>, req_count=<optimized out>)
    at mm/readahead.c:604
#11 0xffffffff8132eba7 in generic_file_buffered_read (iocb=0xffff888000b27ad8, iter=0xffff888000b27a78, written=0) at mm/filemap.c:2220
#12 0xffffffff8132f674 in generic_file_read_iter (iocb=0xffff888000b27ad8, iter=0xffff888000b27a78) at mm/filemap.c:2520

可以看到read文件产生pagecache,最终要在add_to_page_cache_lru加入到address_space radix_tree和相对应的lru链表中,进而调用到mem_cgroup_charge逻辑,所以确认了我们的结论。

进程已运行后,加入Cgroup A中,已经使用的内存是否迁移统计入A 

当一个进程从一个cgroup移动到另一个cgroup时,默认情况下,该进程已经占用的内存还是统计在原来的cgroup里面,不会占用新cgroup的配额,但新分配的内存会统计到新的cgroup中(包括swap out到交换空间后再swap in到物理内存中的部分)。

我们可以通过设置memory.move_charge_at_immigrate让进程所占用的内存随着进程的迁移一起迁移到新的cgroup中。

enable: echo 1 > memory.move_charge_at_immigrate
disable:echo 0 > memory.move_charge_at_immigrate

注意: 就算设置为1,但如果不是thread group的leader,这个task占用的内存也不能被迁移过去。换句话说,如果以线程为单位进行迁移,必须是进程的第一个线程,如果以进程为单位进行迁移,就没有这个问题。

当memory.move_charge_at_immigrate被设置成1之后,进程占用的内存将会被统计到目的cgroup中,如果目的cgroup没有足够的内存,系统将尝试回收目的cgroup的部分内存(和系统内存紧张时的机制一样,删除不常用的file backed的内存或者swap out到交换空间上,如果回收不成功,那么进程迁移将失败。

memory.soft_limit_in_bytes和memory.limit_in_bytes内存回收时机

有了hard limit(memory.limit_in_bytes),为什么还要soft limit呢?hard limit是一个硬性标准,绝对不能超过这个值,而soft limit可以被超越,既然能被超越,要这个配置还有啥用?先看看它的特点

  1. 当系统内存充裕时,soft limit不起任何作用

  2. 当系统内存吃紧时,系统会尽量的将cgroup的内存限制在soft limit值之下(内核会尽量,但不100%保证)

从它的特点可以看出,它的作用主要发生在系统内存吃紧时,如果没有soft limit,那么所有的cgroup一起竞争内存资源,占用内存多的cgroup不会让着内存占用少的cgroup,这样就会出现某些cgroup内存饥饿的情况。如果配置了soft limit,那么当系统内存吃紧时,系统会让超过soft limit的cgroup释放出超过soft limit的那部分内存(有可能更多),这样其它cgroup就有了更多的机会分配到内存。

从上面的分析看出,这其实是系统内存不足时的一种妥协机制,给次等重要的进程设置soft limit,当系统内存吃紧时,把机会让给其它重要的进程。

注意: 当系统内存吃紧且cgroup达到soft limit时,系统为了把当前cgroup的内存使用量控制在soft limit下,在收到当前cgroup新的内存分配请求时,就会触发回收内存操作,所以一旦到达这个状态,就会频繁的触发对当前cgroup的内存回收操作,会严重影响当前cgroup的性能。

结论: 

soft_limit_in_bytes只有触发kswapd或者direct reclaim时候才会进行顺道的回收

limit_in_bytes:新页面产生时候,charge增加使用计数,如果超过limit_in_bytes就会回收。

全局LRU和memcg LRU的关系

结论:我们经常讨论的全局LRU其实对应root_mem_cgroup的per node LRU。

假设目前系统没有设置任何的cgroup,那么只有root_mem_cgroup这个memcg,只要配置CONFIG_CGROUP,内核初始化的时候就会初始化root cgroup。那么我们read/write产生pagecache情况下,新产生page加入lru的代码,看看到底加入的哪个LRU?

lru_cache_add
    --->__pagevec_lru_add
        --->pagevec_lru_move_fn

static void pagevec_lru_move_fn(struct pagevec *pvec,
    void (*move_fn)(struct page *page, struct lruvec *lruvec, void *arg),
    void *arg)
{
    int i;
    struct pglist_data *pgdat = NULL;
    struct lruvec *lruvec;
    unsigned long flags = 0;

    for (i = 0; i < pagevec_count(pvec); i++) {
        struct page *page = pvec->pages[i];
        struct pglist_data *pagepgdat = page_pgdat(page);

        if (pagepgdat != pgdat) {
            if (pgdat)
                spin_unlock_irqrestore(&pgdat->lru_lock, flags);
            pgdat = pagepgdat;
            spin_lock_irqsave(&pgdat->lru_lock, flags);
        }
        //内核通过mem_cgroup_page_lruvec获取加入的LRU,由于我们没有配置任何cgroup,
        //那么此时产生的page对应的lru就是root_mem_cgroup的pgdat这个node的 lru
        lruvec = mem_cgroup_page_lruvec(page, pgdat);
        (*move_fn)(page, lruvec, arg);
    }
    if (pgdat)
        spin_unlock_irqrestore(&pgdat->lru_lock, flags);
    release_pages(pvec->pages, pvec->nr);
    pagevec_reinit(pvec);
}

如上面代码注释,最终mem_cgroup_page_lruvec获取到page->memcg的pgdat node对应的lruvec,而这里page->memcg又是指向哪里的,由于目前系统没有配置任何的cgroup,这个page->memcg就指向root_mem_cgroup,那么page->memcg赋值的地方在哪里的,针对我们目前read pagecache这种场景,最终是在mm/memcontrol.c :commit_charge里面,调用栈:

remote Thread 1 In: mem_cgroup_charge                                                                                                                                            Line: 6723 PC: 0xffffffff8142f6cd 
#0  commit_charge (page=<optimized out>, memcg=<optimized out>)	at mm/memcontrol.c:6723
#1  mem_cgroup_charge (page=0xffffea00000c7600,	mm=<optimized out>, gfp_mask=<optimized out>) at mm/memcontrol.c:6723
#2  0xffffffff81330f80 in __add_to_page_cache_locked (page=0xffffea00000c7600, mapping=0xffff888006245e80, offset=4, gfp_mask=1125578, shadowp=0xffff888006557650) at ./arch/x86/include/asm/current.h:15
#3  0xffffffff813312d4 in add_to_page_cache_lru (page=0xffffea00000c7600, mapping=0xffff888006245e80, offset=4,	gfp_mask=1125578) at mm/filemap.c:922
#4  0xffffffff8134a0eb in page_cache_readahead_unbounded (mapping=<optimized out>, file=<optimized out>, index=4, nr_to_read=<optimized out>, lookahead_size=<optimized out>) at mm/readahead.c:228
#5  0xffffffff8134a25b in __do_page_cache_readahead (mapping=0xffff888006245e80, file=0xffff88800548b640, index=<optimized out>, nr_to_read=32,	lookahead_size=16) at mm/readahead.c:273
#6  0xffffffff8134a4ff in ra_submit (filp=<optimized out>, mapping=<optimized out>, ra=<optimized out>)	at mm/internal.h:64
#7  ondemand_readahead (mapping=0xffff888006245e80, ra=0xffff88800548b6d8, filp=<optimized out>, hit_readahead_marker=<optimized out>, index=0,	req_size=<optimized out>) at mm/readahead.c:551
#8  0xffffffff8134aac8 in page_cache_sync_readahead (req_count=<optimized out>,	index=<optimized out>, filp=<optimized out>, ra=<optimized out>, mapping=<optimized out>) at mm/readahead.c:585
#9  page_cache_sync_readahead (mapping=<optimized out>,	ra=0xffff88800548b6d8, filp=0xffff88800548b640,	index=<optimized out>, req_count=<optimized out>) at mm/readahead.c:567
#10 0xffffffff81333bf1 in generic_file_buffered_read (iocb=0xffff888006557ad8, iter=0xffff888006557a78,	written=0) at mm/filemap.c:2208
#11 0xffffffff81334776 in generic_file_read_iter (iocb=0xffff888006557ad8, iter=0xffff888006557a78) at mm/filemap.c:2520

commit_charge如下:

Linux关于memory cgroup的几个要点,内存子系统,linux,运维,服务器

参考:

Linux内核mem_cgroup浅析-wzzushx-ChinaUnix博客 文章来源地址https://www.toymoban.com/news/detail-732563.html

到了这里,关于Linux关于memory cgroup的几个要点的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 西门子PLC硬件编程需要注意的几个要点

    往往一个好的编程程序习惯可以让事情事半功倍。用正确的逻辑思维和方法去写程序,一方面可以减少出错,另一方面就是方便检查程序里出现的bug。下面就为大家盘点一下,西门子PLC的一些硬件编程的好习惯。 1、关于选型 项目开始需要统计出IO点表,一般在设计初期需要

    2024年02月15日
    浏览(43)
  • “深入理解SpringBoot:从入门到精通的几个关键要点“

    标题:深入理解Spring Boot:从入门到精通 摘要:本文将深入探讨Spring Boot的关键要点,帮助读者从入门到精通。我们将从Spring Boot的基本概念开始,介绍自动配置、起步依赖、注解驱动开发等特性,并通过示例代码演示如何使用Spring Boot构建一个简单的Web应用程序。 正文: S

    2024年02月14日
    浏览(36)
  • (六)关于Linux中服务器磁盘爆满问题的几个解决方案

    在监控服务器性能的时候,发现服务器的磁盘占用很大,几乎快要爆满,具体的表现可能如下: 1、应用服务访问卡顿甚至失败; 2、数据库访问失败; 3、文件上传失败 等等 通过命令 df -h 查看磁盘占用情况,发现如下: 这里的占用是清除过的,所以并不算特别高。 这种现

    2024年02月10日
    浏览(52)
  • Linux Cgroups进程资源限制管理 之 资源子系统限制/控制、Docker资源隔离与限制原理解读

    Linux cgroups(控制组)最初由Google工程师Paul Menage在2006年提出,并在Linux内核的2.6.24版本中首次引入。自那时以来,cgroups一直是Linux内核的一部分,并在容器化技术等领域中发挥着至关重要的作用。随着时间的推移,cgroups功能不断得到改进和扩展,以满足对资源管理和隔离性能

    2024年02月21日
    浏览(43)
  • 关于中断的几个小问题

    1. intel 8259芯片中的IRQ2和int2的区别是什么? 答曰:IRQ2是芯片上的引脚,而int2是中断向量表的第2项,两者有很大区别。 Intel8259A芯片的中断引脚分别为: 主片: 0:8254时钟 1:键盘 2: 从片 3: com2 4:com1 5:声卡 6:软盘 7: lpt打印机 从片: 0:cmos时钟 1:到主片IRQ2的引脚 2:网

    2024年02月07日
    浏览(38)
  • verilog|关于异步复位,同步释放的几个思考

    异步复位,同步释放是一种常见的设计思路,那么 什么情况下,复位信号需要做“异步复位,同步释放”处理? 一般来说,同步系统,都使用异步复位。这是因为同步复位的电路实现,比异步复位的电路实现,要浪费更多电路资源。 未在本模块时钟域做过“异步复位,同步

    2023年04月15日
    浏览(37)
  • TECHnalysis Research:关于生成式AI的几个意外发现

    TECHnalysis Research是一家美国的独立市场调查公司,该调查公司于2023年5月份对于全美10个行业的1000家企业IT决策负责人进行了调研,调研围绕生成式AI及其对于企业业务的影响。就在全球持续升温的生成式AI热度中,TECHnalysis Research的调研结果却显示了几个令人惊讶的意外发现,

    2024年02月12日
    浏览(44)
  • 如何在Linux上通过cgroup限制一个进程使用CPU和内存

    Cgroup(Control Group)是 Linux 内核的一个功能,可以通过它来限制进程的 CPU 和内存占用。Cgroup 实现了对系统资源的细粒度控制和管理,可以将一组进程放入同一个 Cgroup 中,并对该 Control Group 中的所有进程共享相应的资源配额。 下面举个实际的例子,演示如何使用 Cgroup 限制一

    2024年02月15日
    浏览(36)
  • 关于VM一启动虚拟机电脑就重启或蓝屏的几个解决方法

    最近在刚开始学习Linux在使用VMware创建新的虚拟机时只要一点启动虚拟机电脑就直接重启了,最开始以为是vm版本或者是Linux镜像的原因来来回回换了好几个vm和Linux,电脑重启了二三十次都没成功启动虚拟机。 最后来来回回换了几个方法终于把这个问题给解决了,现在就把这

    2024年01月21日
    浏览(47)
  • 关于EMC Unity 存储系统DIMM内存的几个问题

    下面是客户咨询最多的几个关于EMC Unity的DIMM内存的问题,供大家参考。 1.  Unity存储能否自己扩容内存 有客户觉得Unity存储的内容太小,想自己扩容内存,很朴实的想法,原来是每个控制器3条16gb,能不能升级到3条32gb或者4条64gb,直接到顶配。 这个回答是肯定不可以,其实对

    2024年02月10日
    浏览(53)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包