内存知识---内存问题分析方法及思路

分析内存问题主要需要具备以下知识掌握：

1. 熟悉内存分配和回收机制

2. 熟悉swap/zram和/proc/sys/vm/swappiness的作用

3. 熟悉Android的LMK和底层的OOM

Android的lowmemory killer是基于linux的OOM（out ofmemory）规则改进而来的。OOM通过一些比较复杂的评分机制，对运行进程进行打分，然后将分数高的进程判定为bad进程，杀死进程并释放内存。OOM只有当系统内存不足的时候才会启动检查，而lowmemory killer则不仅是在应用程序分配内存发现内存不足时启动检查，它也会定时地进行检查。

Low memory killer主要是通过进程的oom_adj来判定进程的重要程度的。oom_adj的大小和进程的类型以及进程被调度的次序有关。

Low memory killer的具体实现在kerne， 即drivers/staging/android/lowmemorykiller.c

1.1 基本原理

Low Memory Killer与OOM的区别：OOM即Out ofMemory是标准linuxKernel的一种内存管理机制，LowMemory Killer在它基础上作了改进：OOM基于多个标准给每个进程打分，分最高的进程将被杀死；LowMemory Killer则用oom_adj和占用内存的大小来选择Bad进程，OOM在内存分配不足时调用，而LowMemory Killer每隔一段时间就会检查，一旦发现空闲内存低于某个阈值，则杀死Bad进程。

基本实现原理：在linux中，存在一个名为kswapd的内核线程，当linux回收存放分页的时候，kswapd线程将会遍历一张shrinker链表，并执行回调，或者某个app分配内存，发现可用内存不足时，则内核会阻塞请求分配内存的进程分配内存的过程，并在该进程中去执行lowmemorykiller来释放内存。（具体kswapd怎么工作，没有研究）。

 

1. 代表系统所保留空闲内存的最低限。

在系统初始化时会根据内存大小计算一个默认值，计算规则是：
min_free_kbytes = sqrt(lowmem_kbytes * 16) = 4 * sqrt(lowmem_kbytes)(注：lowmem_kbytes即可认为是系统内存大小）
另外，计算出来的值有最小最大限制，最小为128K，最大为64M。
可以看出，min_free_kbytes随着内存的增大不是线性增长，comments里提到了原因“because network bandwidth does not increase linearly with machine size”。随着内存的增大，没有必要也线性的预留出过多的内存，能保证紧急时刻的使用量便足矣。

2.min_free_kbytes的主要用途是计算影响内存回收的三个参数 watermark[min/low/high]

1. watermark[high] > watermark [low] > watermark[min]，各个zone各一套

2)在系统空闲内存低于 watermark[low]时，开始启动内核线程kswapd进行内存回收（每个zone一个），直到该zone的空闲内存数量达到watermark[high]后停止回收。如果上层申请内存的速度太快，导致空闲内存降至watermark[min]后，内核就会进行direct reclaim（直接回收），即直接在应用程序的进程上下文中进行回收，再用回收上来的空闲页满足内存申请，因此实际会阻塞应用程序，带来一定的响应延迟，而且可能会触发系统OOM。这是因为watermark[min]以下的内存属于系统的自留内存，用以满足特殊使用，所以不会给用户态的普通申请来用。

3）三个watermark的计算方法：
watermark[min] = min_free_kbytes换算为page单位即可，假设为min_free_pages。（因为是每个zone各有一套watermark参数，实际计算效果是根据各个zone大小所占内存总大小的比例，而算出来的per zone min_free_pages）
watermark[low] = watermark[min] * 5 / 4
watermark[high] = watermark[min] * 3 / 2
所以中间的buffer量为 high - low = low - min = per_zone_min_free_pages * 1/4。因为min_free_kbytes = 4* sqrt(lowmem_kbytes），也可以看出中间的buffer量也是跟内存