Out-of-Memory (OOM) Killer
以前遇到段错误时,不懂如何查,就没有再深究,后来学会了调试和远程调试,才进一步地了解.记得,遇到段错误是,socket 网络编程时候遇到的，因为涉及到文件io操作,一串乱的积存器值前提示说不能打开文件，也就是文件无法建立,开始以为是文件系统只读,后来发现,不是这里的问题。今天socket接收并保存成功了文件到文件系统的tmp目录下，重复试过几次,确定没有问题,我用一个应用程序加载图片显示,不段刷新图片内容,出现了Out-of-Memory (OOM) Killer的错误,程序自动跳出,系统似乎死了,重复实验了下，记录了整个系统打印消息。
第一次注意到 Linux 这个多年来就存在的特性：OOM Killer 。
?OOM Killer 是一层保护机制，用于避免 Linux 在内存不足的时候不至于出太严重的问题，把无关紧要的进程杀掉，有些壮士断腕的意思。
先要学习点老知识，在 32 位CPU 架构下寻址是有限制的。Linux 内核定义了三个区域：# DMA: 0x00000000 - 0x00999999 (0 - 16 MB)?
# LowMem: 0x01000000 - 0x037999999 (16 - 896 MB) - size: 880MB
# HighMem: 0x038000000 - <硬件特定>?
LowMem 区 (也叫 NORMAL ZONE ) 一共 880 MB，而且不能改变(除非用 hugemem 内核)。对于高负载的系统，就可能因为 LowMem 利用不好而引发 OOM Killer 。一个可能原因是 LowFree 太少了，另外一个原因是 LowMem 里都是碎片，请求不到连续的内存区域【根据我遇到的一个案例，一个猜想是 有些应用一次性请求比较大的内存，恰恰又是 880M 之内的，空闲的(LowFree)不够大，就会触发 OOM Killer 出来干活】。检查当前 LowFree 的值：
# cat /proc/meminfo |grep LowFree?
检查LowMem内存碎片：
# cat /proc/buddyinfo
上面这条命令要在 2.6 Kernel 环境下有效。据说使用 SysRq 的方式更好，不过 Hang 的时候再用吧。参见 Metalink Note:228203.1 。
根据一些文档描述，OOM Killer 在 2.4 与 2.6 上表现是不一样的。2.4 的版本中是把新进来(新申请内存)的进程杀掉。而 2.6 上是杀掉占用内存最厉害的进程(这是很危险的，很容易导致系统应用瘫痪)。
对于 RHEL 4 ，新增了一个参数： vm.lower_zone_protection 。这个参数默认的单位为 MB，默认 0 的时候，LowMem 为 16MB。建议设置 vm.lower_zone_protection = 200 甚至更大以避免 LowMem 区域的碎片，是绝对能解决这个问题的(这参数就是解决这个问题出来的)。
而对于 RHEL 3 (Kernel 2.4) 似乎没什么好办法，一个是用 Hugemem 内核(天知道会不会引入新的毛病)，一个是升级到 2.4.21-47 并且使用新的核心参数 vm.vm-defragment 控制碎片的数量。再就是使用 RHEL 4 (Kernel 2.6)，这又绕回去了。说白了，如果遇到 OOM Killer ，基本上是低版本 Kernel 设计上有点缺陷。
其它，如果去查询 RedHat 的 Bug 库，会发现不少 Kernel 版本也有 Bug 的。尤其在使用 NFS 的场景。
Tip: OOM Killer 的关闭与激活方式：
# echo "0" > /proc/sys/vm/oom-kill?
# echo "1" > /proc/sys/vm/oom-kill