事故记录：php-cgi进程过多导致系统资源耗尽

事故现象： 机房一台服务器运行一段时间后，突然发现系统资源即将被耗尽！

1）top命令查看一下系统的cpu ram swap的使用情况

由上图分析，可以看出 1--共有602个进程，但其中有601个进程休眠了。 这就有点不对劲，这台服务器的内核进程也就80个左右，加上memcached, nginx, mysqld，也不会超出90个，除了这些，剩下的只有php-fpm管理的php-cgi了。 2--CPU显示，CPU压力并不大，可以说没有压力。 3--内存使用概要，发现4G的内存，消耗得所剩余无几(free+buffers)，95%以上的内存都已分配；交互空间使用情况，暂时不去关心。指令top还列出了占用资源最多的进程，运行时间最久(Time+)的mysqld(约2小时)占用资源并不是最多。 4--再看php-cgi,单个php-cgi占用的内存也不算多。 所以，可以大胆地猜想：服务器内存资源比较紧张，并没有被某个进程占用大量内存，有可能被某些挂起的进程占着内存没有释放。通过free进一步监控内存使用情况，验证我们的想法。

2）查看ram的使用情况

先来看Mem统计信息，total表示物理内存总量，约4G。used，表示已分配内存，分配了并不表示使用了，包括(buffer&cached)。free指未分配的内存,buffers与cached表示分配了但还没有被使用的内存。第二行(buffers/cache)的，used表示真正被使用了内存，由第一行的(used-buffer-cached)得到，free则表示还没有被使用的内存,由第一行的(free+buffer+cached)得到。Swap行则表示内存交换使用情况，少量的(不频繁地)swpd，是不会影响服务器性能的，因为系统需要将V类型的内存页面交换出去或者调整了buffer与cached的大小。但是频繁地swpd，则有可能意味着服务器物理内存不足，小于指定的swap额定值，需要换出内存页。

查看free结果的时候，主要查看第二行。一眼就能看出4G的内存，其中有3898M内存被用了，还有49M内存没有，都快用完了。 这也证实了第一步的猜想，内存被用完！ 这里，可以进一步猜想，内存空间严重不足的情况下，进程会被blocked，系统会不断地将不用的数据换出so，将要用的数据读入si。 下面通过vmstat进一步验证这个猜想。

3）vmstat监控内存的使用情况

作为对内存监控，比较重要的还是swpd、free、si、so。 一般系统不繁忙的状态下，可以看到swpd,so的值不会持续很高，经常为0。 这里看到swpd值为1.5G，以及free值很小，再一次表明物理内存不足。其中si报告了每秒从swap区移入到物理内存的内存总量，so报告了每秒从物理内存移出到swap区的内存总量。 当然，si有时较大，并不要过份的焦虑，经常碰到一个程序需要较大内存来读写媒体文件时，si值就会变大。反倒是so，它通常是一个内存紧缺的一个信号，如果长时间这个值一直保持较大的话，则很有可能内存不够，小额波动，可以不用理会。接下来，可以通过ps找出消耗内存的元凶。

4）ps找出消耗内存的元凶

指令ps比较常用，也比较简单。从上面报告结果中可以一眼看到php-cgi这个进程。虽然单个php-cgi占用内存并不算太大，但是503个php-cgi进程，就有点恐怖了。几乎占尽了全部内存（503*0.3%）。php-cgi由php-fpm管理，因此可以断定，是由于php-fpm配置文件php.ini中的max_children参数配置不当，才导致打开过多的php-cgi进程。所以要适当调整下max_children的设置。