oom机制分析及对应优化策略

转载自https://blog.51cto.com/12814931/2343623

近日接了一些oom案子，此类问题通常是客户自身业务导致的问题。但现在客户的提问越来越复杂，通常情况下我们需要站在客户一侧提供“协助”的技术服务。oom类案例通过一年多的学习和探讨，我将其分为3类：

1、内存真的不足

2、文件数到达上限

3、lowmem内存不足

内存真的不足的情况针对于64位系统，这时可能导致的原因有：进程hung住占用大量内存、进程申请连续大页导致溢出、本身内存负载接近临界值。这时可尝试升级内存配置、优化业务进程来解决。

单个进程最多允许打开的文件句柄数（包括socket连接数）是有限制的，当大于这个系统限制时，程序会抛出大量的无法打开文件的报错。这种情况设涉及到几个内核参数：

/proc/sys/fs/nr_open——系统文件系统支持文件句柄总数上限，默认值1048576（1M），Linux2.6.25开始增加该内核参数，用于替换内核宏NR_OPEN（1048576），该值上限受限于系统内存。

/proc/sys/fs/file-max——系统文件系统支持文件句柄总数最大值，必须小于/proc/sys/fs/nr_open或NR_OPEN，增加该值时，必须同步修改/proc/sys/fs/inode-max = 4*/proc/sys/fs/file-max。

因此当出现messages中存在相关句柄数达上限之类的提示时就可以适当调高上述内核参数

对于32位机器会出现一些内存使用率不高却仍然发生oom的情况，这是因为对于32位机器内核采用lowmem来管理highmem。LowMem 区 (也叫 NORMAL ZONE ) 一共 880 MB，而且不能改变(除非用 hugemem 内核)。对于高负载的系统，就可能因为 LowMem 利用不好而引发 OOM Killer 。一个可能原因是 LowFree 太少了，另外一个原因是 LowMem 里都是碎片，请求不到连续的内存区域。

检查当前 LowFree 的值：

# cat /proc/meminfo |grep LowFree

检查LowMem内存碎片：

# cat /proc/buddyinfo

这时可以通过升级到64位系统、使用hugemem内核（安装hugemem kernel RPM）、适当调高/proc/sys/vm/lower_zone_protection（lower_zone_protection越高，系统越倾向于保护lowmem）来解决。

oom的kill机制

如果oom_kill_allcating_task设置为非零值，则oom根据score_adj来选择杀掉的进程。 /proc/[pid]/oom_adj ，该pid进程被oom killer杀掉的权重，介于 [-17,15]之间，越高的权重，意味着更可能被oom killer选中，-17表示禁止被kill掉。关于kill机制，涉及到2个内核参数：

1、oom_kill_allocating_task

控制在OOM时是否杀死触发OOM的进程。

如果设置为0，OOM killer会扫描进程列表，选择一个进程来杀死。通常都会选择消耗内存内存最多的进程，杀死这样的进程后可以释放大量的内存。

如果设置为非零值，OOM killer只会简单地将触发OOM的进程杀死，避免遍历进程列表（代价比较大）。如果panic_on_oom被设置，则会忽略oom_kill_allocating_task的值。

默认值是0。

2、vm.panic_on_oom

控制内核在OOM发生时时是否panic。

如果设置为0，内核会杀死内存占用过多的进程。通常杀死内存占用最多的进程，系统就会恢复。

如果设置为1，在发生OOM时，内核会panic。然而，如果一个进程通过内存策略或进程绑定限制了可以使用的节点，并且这些节点的内存已经耗尽，oom-killer可能会杀死一个进程来释放内存。在这种情况下，内核不会panic，因为其他节点的内存可能还有空闲，这意味着整个系统的内存状况还没有处于崩溃状态。

如果设置为2，在发生OOM时总是会强制panic，即使在上面讨论的情况下也一样。即使在memory cgroup限制下发生的OOM，整个系统也会panic。

默认值是0。

将该参数设置为1或2，通常用于集群的故障切换。选择何种方式，取决于你的故障切换策略。

代码判断逻辑如下：

void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask,

int order, nodemask_t *nodemask, bool force_kill)

{

// 等待notifier调用链返回，如果有内存了则返回

blocking_notifier_call_chain(&oom_notify_list, 0, &freed);

if (freed > 0)

return;

// 如果进程即将退出，则表明可能会有内存可以使用了，返回

if (fatal_signal_pending(current) || current->flags & PF_EXITING) {

set_thread_flag(TIF_MEMDIE);

return;

}

// 如果设置了sysctl的panic_on_oom，则内核直接panic

check_panic_on_oom(constraint, gfp_mask, order, mpol_mask);

// 如果设置了oom_kill_allocating_task

// 则杀死正在申请内存的process

if (sysctl_oom_kill_allocating_task && current->mm &&

!oom_unkillable_task(current, NULL, nodemask) &&

current->signal->oom_score_adj != OOM_SCORE_ADJ_MIN) {

get_task_struct(current);

oom_kill_process(current, gfp_mask, order, 0, totalpages, NULL,

nodemask,

"Out of memory (oom_kill_allocating_task)");

goto out;

}

// 用select_bad_process()选择badness指

// 数(oom_score)最高的进程

p = select_bad_process(&points, totalpages, mpol_mask, force_kill);

if (!p) {

dump_header(NULL, gfp_mask, order, NULL, mpol_mask);

panic("Out of memory and no killable processes...\n");

}

if (p != (void *)-1UL) {

// 查看child process, 是否是要被killed，则直接影响当前这个parent进程

oom_kill_process(p, gfp_mask, order, points, totalpages, NULL,

nodemask, "Out of memory");

killed = 1;

}

out:

if (killed)

schedule_timeout_killable(1);

}

计算权值时会将是否为系统进程、进程RSS和swap内存占用考虑进去。当然也可自行设置：echo 17 > /proc/[pid]/oom_adj（不允许oom杀掉这个进程）

计算逻辑代码如下：

unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,

const nodemask_t *nodemask, unsigned long totalpages)

{

long points;

long adj;

// 内部判断是否是pid为1的initd进程，是否是kthread内核进程，是否是其他cgroup，如果是则跳过

if (oom_unkillable_task(p, memcg, nodemask))

return 0;

p = find_lock_task_mm(p);

if (!p)

return 0;

// 获得/proc/[pid]/oom_adj权值，如果是OOM_SCORE_ADJ_MIN则返回

adj = (long)p->signal->oom_score_adj;

if (adj == OOM_SCORE_ADJ_MIN) {

task_unlock(p);

return 0;

}

// 获得进程RSS和swap内存占用

points = get_mm_rss(p->mm) + p->mm->nr_ptes +

get_mm_counter(p->mm, MM_SWAPENTS);

task_unlock(p);

// 计算步骤如下，【计算逻辑比较简单，不赘述了】

if (has_capability_noaudit(p, CAP_SYS_ADMIN))

adj -= 30;

adj *= totalpages / 1000;

points += adj;

return points > 0 ? points : 1;

}

oom机制分析及对应优化策略相关推荐

inputstreamreader未关闭会导致oom_Linux内核OOM机制分析和防止进程被OOM杀死的方法...
问题描述 Linux 内核有个机制叫 OOM killer(Out-Of-Memory killer),该机制会监控那些占用内存过大,尤其是瞬间很快消耗大量内存的进程,为了防止内存耗尽而内核会把该进程 ...
Chrome V8系列--浅析Chrome V8引擎中的垃圾回收机制和内存泄露优化策略
V8 实现了准确式 GC,GC 算法采用了分代式垃圾回收机制.因此,V8 将内存(堆)分为新生代和老生代两部分. 一.前言 V8的垃圾回收机制:JavaScript使用垃圾回收机制来自动管理内存.垃圾 ...
逃逸分析--代码三大优化策略（堆不是分配对象存储的唯一选择）
堆是分配对象存储的唯一选择吗? 随着JIT编译器的发展与逃逸分析逐渐成熟,栈上分配.标量替换优化技术将会导致一些微妙的变化,所以对象都分配到堆上也渐渐变得不是那么绝对了. 在Java虚拟机中,对象是在 ...
Android 系统性能优化（43）---Android OOM案例分析
Android OOM案例分析在Android(Java)开发中,基本都会遇到java.lang.OutOfMemoryError(本文简称OOM),这种错误解决起来相对于一般的Exception或 ...
搜索引擎优化系统知名乐云seo_搜索引擎优化策略分析-乐云SEO
搜索引擎优化策略分析-乐云SEO 类别:seo技术来源:日期:2020-04-20 09:59:10人气值: Seo推广是一种将网站优化和网络运营媒体推广相结合的技术,现在它恰好是最流行的媒体.正因 ...
用科技词汇润色下句：并将模型在中国西北地区应用，对水碳能耦合循环过程进行定量评估和时空格局分析，旨在优化区域生态系统管理策略。...
我们将在中国西北地区应用机器学习模型,对水碳能耦合循环进行定量评估和时空格局分析,以优化该地区的生态系统管理策略.
性能优化分析及常见性能优化策略总结
最近,大家似乎都对性能优化分析,这一方面比较感兴趣.一方面是比较感兴趣,另一方面就是遇见许多类似的状况,但是,却不知从何下手,根源在哪里?应当如何正确优化?首先,先跟大家讲解下常见的性能优化策略分类! ...
Linux内核OOM机制的详细分析
Linux 内核有个机制叫OOM killer(Out-Of-Memory killer),该机制会监控那些占用内存过大,尤其是瞬间很快消耗大量内存的进程,为了防止内存耗尽而内核会把该进程杀掉.典型的 ...
Linux内核OOM机制的详细分析【转】
本文转载自:http://blog.csdn.net/liukuan73/article/details/43238623 Linux内核根据应用程序的要求分配内存,通常来说应用程序分配了内存但是并没 ...

oom机制分析及对应优化策略

oom机制分析及对应优化策略相关推荐

最新文章

热门文章