Linux 的 Out-of-Memory (OOM) Killer

同事在 Linux 服务器上遇到点小问题，我也上去折腾半天。这还是第一次注意到 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

更多参考信息:

1) OOM killer “Out of Memory: Killed process” SOLUTIONS / SUMMARY【对我遇到的案例没鸟用】
2) Metalink Notes : Linux Kernel Lowmem Pressure Issues and Kernel Structures
3) Respite from the OOM killer

–EOF–

头疼欲裂，零散记录点东西，备查。

Yahoo! 的数据仓库: 世界上最大最忙

微软对 Yahoo! 的收购持久战可能让很多人都新闻疲劳了。但今天看到的这个关于 Yahoo！的技术新闻还是值得看一下的：Size matters: Yahoo claims 2-petabyte database is world’s biggest, busiest 。Yahoo! 的 VP Waqar Hasan 在文中披露 Yahoo！的数据仓库当前容量为 2PB。用于分析每月5亿的用户访问行为，每天处理 240 亿次的事件，号称世界上单个最大、最忙的数据库。

尽管有的数据仓库容量要比雅虎的大。但那些 DB 或是存储非关系性数据，或是存储的压缩后的原始数据，不能进行即时分析，雅虎之前的也有数百 T 这样的数据。眼下 Yahoo！数据仓库存储的是结构化、可分析的数据。预计下一年可能膨胀到数十 PB 。eBay 号称数据总量有 6PB ，不过根据一些消息来看，单个最大的 DB 只有 1.4 PB。

Yahoo! 在 2005 年买了一家叫 Mahat Technologies 的初创公司（就是 Waqar Hasan 操刀的)，这家公司以 PostgreSQL 数据库为基础，开发了一个新型 DB，其特点是 基于列 的而不是 基于行 的模式。不难理解，这样数据写入的速度会慢下来，但是读取的速度会快很多【去年的侠客行上，雷鸣在演讲的时候讲过他在百度的时候做的一个优化的例子。和这个思想非常相似，所以当时我说对我”有启发“】。Yahoo! 买了之后，对该产品进行了持续性的改进(内部代号: ELCARO ?) ，比如压缩，并行处理能力加强、优化查询等等特性的添加改进。而针对使用者的接口仍是 PostgreSQL 。这应该也算 PostgreSQL 在顶级企业又一个成功案例。

这么大的数据库并没有采用传统的 SMP 架构构建，而是采用普通 PC 作集群(用了不到 1000 台) 。很明显这是 Share Nothing 而不是 Share Storage 的 DB 集群。通过上述独特的设计方式，能够对此海量数据进行有效的分析，这是个不小的技术革新，也是与 Google Map Reduce 完全不同的计算模式。

让人感慨的是关于世界上的超大数据库一文中罗列的数据，现在看起来已经并不惊人了。以前总说信息爆炸，这个时代刚刚来临。

–EOF–

侠客行会议归来

从侠客行会议刚回来。不要问我技术内容了，只是简单记录一下流水涨吧。

早晨还没洗漱完毕就有朋友给我打电话询问门票的事情，赶紧出门赶到了会场。在大门口附近送了一会儿票(其实到了现场就知道对门票的控制没那么严格，基本上都能入场，只是答应了大家的事情，就尽量的要做到。希望没有朋友因为没门票而觉得不爽)。差不多后，进入五楼的主会场。

会场内为每个参会者准备了一个资料袋，环保的 “I’m NOT a plastic bag“，值得一提。一开场的大屏幕动画做的很好，伴随着鼓声，一个个武功高手动作各异的剪影飘过，估计那会儿会场里的人都会比较激动。

在会场里遇到了客奇集的陈成罕，对我的 Blog 提了点意见：为什么技术细节不够多? 唉，其实当时没告诉他的是，我也想多加点技术细节，只是…… 这次他们那边一共来了六位工程师，其中还有不老歌的 York ，下午的时候终于看到了 York，可惜没能畅谈。在会场边上走进走出的（我这是来参会的么?)，听演讲的效果并不是很好。对陈世卿博士的主题演讲比较感兴趣的，尽管了解不到实际的内容，但毕竟是见证计算机发展历史的人，沾点仙气也不错的。David Axmark 看起来是个绅士，语气淡然。老马演讲开始的时候几乎所有在走廊里的人都回到了会场……老马明显比前一段时间瘦了很多–本来就瘦

在会场外和组织这次会议同事聊了一会儿，他们也不容易，世界上哪有十全十美的会议呢? infoQ 、博文视点、CSDN 的编辑朋友也都见到了。这次 InfoQ 还是会议的合作媒体，上午自己接受了他们的视频采访，现在回想起来时候发现大部分的话题都落在 Web 2.0 上了，不知道是否很合适。对于这样的采访没啥经验，等待出来的效果吧。大家都是不错的朋友，所以也建议他们别错过对支付宝我另一个同事的采访。

下午先是听了半场 A Look at Hadoop ，这本应该是个很有趣的话题，可惜现场效果似乎并非很好，本来准备了要问个问题的。接着就去配合 InfoQ 编辑对支付宝首席架构师程立的采访去了。采访效果我觉得非常好，我自己也听的很过瘾。希望能早点看到整理后的采访内容。

采访完毕出来，到二楼去找刚赶到杭州的车东，客奇集的朋友们也都在这里，把 Yupoo 的阿华同学也给大家介绍了一下。比较可惜的是晚上没有安排什么技术交流，否则这么多朋友聚在一起倒是能大聊特聊的。

听完了 Flickr Architecture 这个主题高屋建瓴般的讲座，会议就结束了。在会议结束的时候随车东和淘宝的卢亮聊了几句，尽管在同一个公司，但还是第一次见面。意外的发现前面的嘉宾里面有 LVS 的创始人章文嵩博士，失敬失敬。上一届章博士有个主题分享来着。这次简单的交流一会儿，很多细节都讲的比较清楚。

听了一些其它朋友的简单反馈，关于下午各个场次内的演讲情况：有些名气大的人不一定口才好，口才好不一定技术讲的清楚。

晚上阿里巴巴 DBA 大聚会，将近 30 人，IT168 的熊老师买单(据说他们刚收购了 ChinaUnix)，想起来，其实 DBA 们好久没聚在一起了。吃过饭，回家的路上觉得好累。

–EOF–

PHP FastCGI 进程管理器: PHP-FPM

最近 PHP-FPM (PHP FastCGI Process Manager) 这个话题在讨论组里很受关注。使用 PHP 的朋友对于 FastCGI 进程的管理估计都很头疼，比如 Nginx 下的 FastCGI 就有不少人用的 Lighttpd 的 spawn-fcgi 来对进程进行管理。但这样存在不少缺点(中文版本)。

PHP-FPM 配置起来很简单，但有一点比较有意思的是如何确定 Worker 的数量。PHP-FPM 作者 Andrei Nigmatulin 在新闻组里提到的小技巧如下：

1) 用 Linux top 命令观察 (这个方式比较土)
2) 用 'netstat -np | grep 127.0.0.1:9000' 收集数据。
设置  php-fpm.conf 中的 max_children 的数值使 等待的数量变为最小。

目前使用 PHP-FPM 还只是通过 Patch 方式，然后编译，期待能够早点并入正式的 PHP 代码中。当然，PHP 核心开发的那些大爷们也不知都在忙什么呢，莫非还在为 Unicode 较劲呢?

–EOF–

Tips : PHP-FPM on highload tips