Linux优化排错 1.12 Overcommit 和 OOM

> Linux 允许进程申请的内存超出实际的可用内存，这叫overcommit;当进程真的要使用这些内存而Linux 提供不了内存的时候，就会把一些进程kill掉来释放一些内存，这叫oom_killer。

#overcommit
* 通常进程都会比真实需要的多申请一些内存，这导致了内存的浪费。
* Linux “分配”内存给进程后，只有进程真正的开始往这些内存中放数据的时候，内核才会真的把内存交给进程，所以Linux可以把已经“分配”出去的内存再次分配给其它进程，这些内存泡沫（就像经济泡沫）和真实内存组成了虚拟内存。
* 如果进程要使用内核已经“分配”给他的内存而事实上内核已经没有内存可分配的时候，就触发oom_killer(内核是个老流氓)。
***
##配置overcommit
###sysctl vm.overcommit_memory=0
适当overcommit，只有当进程申请的内存小于剩余可用内存的时候，才分配内存
***
###sysctl vm.overcommit_memory=1
来者不拒，要多少都答应
***
###sysctl vm.overcommit_memory=2
不准overcommit，且分配的内存不可超过一个可配置的值，永远不会触发oom_killer
**细节：**
```
[root@test1 ~]# cat /proc/meminfo | grep -i commit
CommitLimit:     2489920 kB
Committed_AS:      91060 kB
```
CommitLimit  => 分配的内存不允许超过这个值
Committed_AS => 当前已经分配的内存
**CommitLimit的计算方式:**
```
CommitLimit = (实际内存 - hugepages) * vm.overcommit_ratio / 100 + swap
```
或者通过vm.overcommit_kbytes 配置。
vm.overcommit_kbytes 和 vm.overcommit_ratio 都是内核参数，可以通过sysctl 设置。
***
#OOM_KILLER
当overcommit导致内存不够时，有新的进程申请内存就会触发oom_killer,通常都会被记录在/var/log/message中
##杀哪一个进程
* 可以比较简单的理解成杀那个占用内存多且不重要的进程（啥叫不重要看你怎么配的，内核认为除了root都不重要）
* cat /proc/pid/oom_score, 内核的打分，越高越可能被杀，等于0表示不会被杀
* echo -17~15 > /proc/[pid]/oom_adj，类似于修改进程的nice值，越低越重要，-17是绝对不会被kill，一般建议-15
* 又或者sysctl vm.oom_kill_allocating_task = 1, 谁触发oom就kill谁（压垮骆驼的最后一根稻草），看谁运气好。。。 
***
##不杀好吗？
那就让整个系统重启
* sysctl vm.panic_on_oom=1, 发生oom的时候让内核panic
* sysctl kernel.panic=N， 发生kernel panic 的N秒后自动reboot

乱读天书， 不求甚解

乱读天书，不求甚解