Linux cgroup memory相关参数

最近在解决container中的内存问题过程中查找了linux memory 相关的一些文章,稍微整理一下:

1. linux memory 相关的几个参数,主要是控制cgroup的资源配置: 

A control group (cgroup) is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network, and so on) of a collection of processes.

path: /sys/fs/cgroup/memory/”

  • memory.limit_in_bytes
    cgroup的最大可用内存
  • memory.usage_in_bytes
    cgroup中所有进程当前使用的内存
  • memory.memsw.limit_in_bytes
    cgroup的最大可用内存和通过swap获得的内存总和
  •  memory.memsw.usage_in_bytes
    cgroup中所有进程当前使用的内存和swap空间总和
  • memory.oom_control
    oom killer机制是否被打开
    oom_kill_disable: enabled (0) or disabled (1).
    cgroup 处于何种oom状态
    under_oom: under oom control (1),进程被停止
                         not under oom control (0).
  • /proc/<pid>/oom_score
    查看oom打分
  • /proc/pid/oom_score_adj
    调整oom打分的权重

2. oom kill 系统日志分析:

以下是oom kill 发生后通过sudo egrep -i -r 'killed process' /var/log获取的系统日志:

Sep 23 08:21:12 ip-000-00-00-000 kernel: test invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
Sep 23 08:21:12 ip-000-00-00-000 kernel: test cpuset=14f5209827883f18be016f8015f7c69000741877199d5802c5326dee0cbb899f mems_allowed=0
Sep 23 08:21:12 ip-000-00-00-000 kernel: CPU: 3 PID: 14239 Comm: test Kdump: loaded Tainted: G 
Sep 23 08:21:12 ip-000-00-00-000 kernel: Hardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017
Sep 23 08:21:12 ip-000-00-00-000 kernel: Call Trace:
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb95b1bec>] dump_stack+0x19/0x1f
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb95acb4f>] dump_header+0x90/0x22d
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb912235b>] ? cred_has_capability+0x6b/0x130
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb8f2ed94>] ? __css_tryget+0x24/0x50
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb904a4a8>] ? try_get_mem_cgroup_from_mm+0x28/0x70
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb8fcd3f5>] oom_kill_process+0x2d5/0x4a0
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb912244e>] ? selinux_capable+0x2e/0x40
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb904e98c>] mem_cgroup_oom_synchronize+0x55c/0x590
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb904dde0>] ? mem_cgroup_charge_common+0xc0/0xc0
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb8fcdcf4>] pagefault_out_of_memory+0x14/0x90
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb95aaf88>] mm_fault_error+0x6a/0x15b
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb95bfa61>] __do_page_fault+0x4a1/0x510
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb95bfbb6>] trace_do_page_fault+0x56/0x150
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb95bf112>] do_async_page_fault+0x22/0x100
Sep 23 08:21:12 ip-000-00-00-000 kernel: [<ffffffffb95bb7e8>] async_page_fault+0x28/0x30
Sep 23 08:21:12 ip-000-00-00-000 kernel: Task in /docker/14f5209827883f18be016f8015f7c69000741877199d5802c5326dee0cbb899f killed as a result of limit of /docker/14f5209827883f18be016f8015f7c69000741877199d5802c5326dee0cbb899f
Sep 23 08:21:12 ip-000-00-00-000 kernel: memory: usage 4193568kB, limit 4194304kB, failcnt 9360087
Sep 23 08:21:12 ip-000-00-00-000 kernel: memory+swap: usage 4193948kB, limit 4194304kB, failcnt 547
Sep 23 08:21:12 ip-000-00-00-000 kernel: kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
Sep 23 08:21:12 ip-000-00-00-000 kernel: Memory cgroup stats for /docker/14f5209827883f18be016f8015f7c69000741877199d5802c5326dee0cbb899f: cache:100KB rss:4194084KB rss_huge:989184KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:4194140KB inactive_file:0KB active_file:0KB unevictable:0KB
Sep 23 08:21:12 ip-000-00-00-000 kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Sep 23 08:21:12 ip-000-00-00-000 kernel: [13494]     0 13494     2922      282      11        0             0 bash
Sep 23 08:21:12 ip-000-00-00-000 kernel: [13558]     0 13558     2957      450      11        0             0 sh
Sep 23 08:21:12 ip-000-00-00-000 kernel: [13589]     0 13589    32884     1094      68        0             0 sudo
Sep 23 08:21:12 ip-000-00-00-000 kernel: [13590]     0 13590     2392      350       9        0             0 app1
Sep 23 08:21:12 ip-000-00-00-000 kernel: [13720]     0 13720    32884     1095      65        0             0 sudo
Sep 23 08:21:12 ip-000-00-00-000 kernel: [13721]     0 13721     2391      346      10        0             0 app2
Sep 23 08:21:12 ip-000-00-00-000 kernel: [ 9090]     0  9090     2957      484      12        0             0 bash
Sep 23 08:21:12 ip-000-00-00-000 kernel: [26182]     0 26182  3878119   518938    2607        0             0 app3
Sep 23 08:21:12 ip-000-00-00-000 kernel: [14211]     0 14211  4120327   521111    2439        0             0 test
Sep 23 08:21:12 ip-000-00-00-000 kernel: [16224]     0 16224     1091       90       8        0             0 sleep
Sep 23 08:21:12 ip-000-00-00-000 kernel: [16232]     0 16232     1091       89       7        0             0 sleep
Sep 23 08:21:12 ip-000-00-00-000 kernel: Memory cgroup out of memory: Kill process 15622 (test) score 484 or sacrifice child
Sep 23 08:21:12 ip-000-00-00-000 kernel: Killed process 14211 (test), UID 0, total-vm:16481308kB, anon-rss:2076604kB, file-rss:7840kB, shmem-rss:0kB
4kB, file-rss:7840kB, shmem-rss:0kB

pid14211被kill, log显示rss为521111(以4kB page作为单位), 521111*4kB = 2084444kB = 2076604kB + 7840kB = anon-rss+ file-rss
 

Reference:
3.7. memory | Red Hat Product Documentation
https://docs.oracle.com/en/operating-systems/oracle-linux/6/adminsg/ol_memory_cgroups.html
memory - Understanding the Linux oom-killer's logs - Stack Overflow
proc_pid_oom_score_adj(5) - Linux manual page
linux - How does the OOM killer decide which process to kill first? - Unix & Linux Stack Exchange
Cirata Community
What Are Namespaces and cgroups, and How Do They Work?

 

<think>好的,我现在需要回答用户关于Linux内核中的memory.use_hierarchy参数的问题。首先,我得回忆一下这个参数的作用和相关背景。 memory.use_hierarchy是cgroups v1内存控制器中的一个配置选项。用户可能是在使用cgroups管理进程的内存资源时遇到了这个参数,或者在学习cgroup的内存控制机制。我需要解释清楚这个参数的功能,以及启用或禁用它带来的影响。 我记得memory.use_hierarchy主要用于控制内存资源在层级结构中的统计和回收方式。当启用时,子cgroup的内存使用情况会汇总到父cgroup中,这样父节点可以更有效地管理整个子树的内存。同时,内存回收机制也会考虑到整个层次结构,这可能影响系统在内存压力下的行为。 接下来,我需要确认这个参数的默认值。在较新的内核版本中,默认应该是启用的,比如从3.13版本开始。但用户可能使用的环境不同,可能需要提及版本差异。 然后,启用和禁用这个参数的具体影响是什么。启用时,父cgroup能够限制整个子树的内存使用,这对于防止某个子cgroup耗尽父级资源很重要。而禁用的话,每个cgroup独立统计,可能导致父级无法有效控制子级的总内存使用。 还需要考虑应用场景。例如,在需要严格分层控制的环境中,比如容器化部署,启用这个参数会更合适。而在某些特定优化场景下,可能需要禁用,但要注意潜在的风险,比如内存泄漏或资源竞争。 同时,用户可能关心如何配置这个参数。需要说明如何通过写入1或0到对应的cgroup文件来启用或禁用。例如,使用echo 1 > memory.use_hierarchy的命令。 另外,要注意到cgroups v2的不同。在v2中,层级控制是强制启用的,所以这个参数在v2中可能不存在。需要提醒用户注意他们使用的cgroup版本,这可能影响他们的配置方式。 最后,确保回答结构清晰,分点说明功能、默认值、启用与禁用的影响以及应用场景。同时,保持语言简洁,避免技术术语过多,但又要准确。</think>Linux内核中的`memory.use_hierarchy`是cgroups(控制组)内存子系统中的一个参数,主要用于控制内存资源在层级结构中的统计和回收行为。以下是逐步解析: --- ### **1. 功能与背景** - **所属模块**:属于cgroups v1的**内存子系统**(`memory`子系统),用于管理进程组的内存资源限制。 - **核心作用**:决定是否启用**层级化的内存统计与回收**。 - 启用时(`1`):子cgroup的内存使用会逐级向上汇总到父cgroup,内存回收会考虑整个层级结构。 - 禁用时(`0`):每个cgroup独立统计内存使用,父cgroup不跟踪子cgroup的内存。 --- ### **2. 默认值** - 内核版本 ≥3.13:默认启用(`1`)。 - 内核版本 <3.13:默认禁用(`0`)。 --- ### **3. 启用(`1`)的影响** - **层级化统计**: - 父cgroup的`memory.usage_in_bytes`包含所有子cgroup的内存使用。 - 父cgroup可以通过`memory.limit_in_bytes`限制整棵子树的总内存。 - **层级化回收**: - 当系统内存不足时,内核会从**整个层级结构**中选择最合适的cgroup进行内存回收。 - 优先回收叶子节点(无子cgroup的节点)的内存。 - **适用场景**: - 需要严格限制某一组进程及其子进程的总内存使用(例如容器嵌套部署)。 --- ### **4. 禁用(`0`)的影响** - **独立统计**: - 父cgroup的`memory.usage_in_bytes`仅包含直接分配给它的内存,不包含子cgroup的内存。 - 父cgroup无法限制子树的总内存(仅能限制自身直接分配的内存)。 - **独立回收**: - 内存回收仅针对单个cgroup,不跨层级。 - **潜在风险**: - 子cgroup可能耗尽父cgroup的内存,导致资源竞争或OOM(Out-Of-Memory)问题。 --- ### **5. 配置方法** - 通过写入`0`或`1`到cgroup的`memory.use_hierarchy`文件: ```bash # 启用层级化 echo 1 > /sys/fs/cgroup/memory/<cgroup-name>/memory.use_hierarchy # 禁用层级化 echo 0 > /sys/fs/cgroup/memory/<cgroup-name>/memory.use_hierarchy ``` - **注意事项**: - 修改此参数需在cgroup无子节点时进行。 - 启用后不可禁用,除非删除所有子cgroup。 --- ### **6. 与cgroups v2的区别** - 在cgroups v2中,层级化内存管理是**强制启用**的,因此不再提供`memory.use_hierarchy`参数。 --- ### **总结** - **启用场景**:需要精细控制内存层级(如容器编排系统)。 - **禁用场景**:简单内存隔离(需谨慎评估风险)。 - **关键影响**:层级统计与回收的粒度决定了内存管理的灵活性和安全性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值