【chromium】 Chromium OS的oom机制

前一段时间，运行在Chromium OS上的一个相机应用经常会自己崩溃，进程戛然而止，测试过程中发现使用的内存以肉眼可见的内存增长，当增长到1G左右，应用窗口突然消失，虽然原因不明，但是能猜到个大概，和内存的增长是有关系的。虽然应用所在的renderer进程是browser的子进程，但是并没有相关日志可查，如果是因为内存增长导致进程被杀，应该从系统层分析，查了位于/var/log/memory的日志，发现确实有kill进程的迹象，原因是oom，那么什么是oom？满足什么条件的进程才会被杀呢？有先杀后杀的顺序么，如果没有，会不会因为应用的内存增长错杀别的进程？

进程击杀顺序

首先要清楚的一个概念：浏览器确实干涉了它和它的子进程的oom策略

浏览器一开始只有一个browser进程，而renderer进程是由Zygote进程fork出来的，并且在进行进程初始化的流程中（这个进程初始化是一个统一的流程，每个进程都会走，详情可以看另一篇文章GPU进程启动流程分析）对初始的oom score做了设定，但是oom机制使用的是linux内核本身的oom机制。

看下oom score，oom score的值越小，越有可能最晚被击杀，产生renderer进程的Zygote进程和Browser进程也是可以被杀掉的，但是优先级排在最后。

renderer进程初始化时oom score是300。最大的分数值为1000，意思是当进程的oom score达到1000时，该进程可能会在很短的时间内被优先击杀。

linux内核设定的oom score的范围并没有刚才描述的这么大，它值是-15到15的一个区间，和刚才提到的-1000到1000类似。这个值是相互转换的按比例进行换算。比如200 = 3。

最终OOM-Killer是通过/proc//oom_score这个值来决定哪个进程被杀死。这个值是系统综合进程的内存消耗量、CPU时间(utime+stime)、存活时间(utime - start_time)和oom_adj计算出的，消耗内存越多oom_score值越高，存活时间越长值越低。另外，Linux在计算进程的内存消耗的时候，会将子进程所耗内存的一半算到父进程中(有兴趣的话可以查看内核代码mm/oom_kill.c：badness函数)。

Linux下有3种Overcommit策略，可以通过/proc/sys/vm/overcommit_memory配置，取0、1和2三个值，默认是0：

1. 取值0：启发式策略，比较多的内存申请可能会被拒绝，如当前内存2G，突然申请1T的内存(一般当系统启动selinux模块时有效，其他情况等同取值1)；

2. 取值1：允许分配比当前内存资源多的内存；

3. 取值2：系统所能分配的内存资源不能超过swap+内存资源*系数(/proc/sys/vm/overcommit_ratio，默认50%，可调整)。如果资源已经用光，再有内存申请请求时，都会返回错误。

chromium os测试环境的值取值为1，这意味着，你可以当前可用内存为2G，你可以申请比2G更多的内存。