说明：此文章转载自http://www.perfgeeks.com/?p=599，[PS处非原文内容]
具体情况：
测试人员向我们反映：在Facebook平台的游戏比其它平台的游戏明显更慢。我询问，是不是因为网络原因。他们说：不是，其它游戏也比较流畅。使用httpwatch查看了http请求，发现api.php请求花了6秒，且大部分时间是红色(httpwatch红色表示服务器运算时间)。平常2秒，现在6秒,服务器处理时间在不同的服务器相差这么多。直觉告诉：服务器资源。
[PS:一般如果反应web站点很慢，就先去查看下系统的资源是否足够。某种原因导致资源不够导致网站慢，这样的情况还是挺常见的。比如公司中有一台编译服务器，刚加上的时候就经常出现假死的状态，导致加载上面的一个内部系统经常很慢。上去一看就发现是资源消耗过大啊。具体原因就是程序编译的时候使用了8所有的cpu核数来进行编译，make-j8。并且程序也可以加上判断，当发现内部资源不够时，自己把自己kill掉。]
服务器概况
操作系统:CentOS5.3-64-2.6.18-164.el5
应用服务Nginx0.6、PHP-Fpm、MySQL5.1、PHP5.2、Memcached
Memcached仅cached游戏系统设置与模板参数据
故障检测
1.别的先不管，先top看一下cpu、ram、swap哪个比较紧张。
由上图分析，可以看出共有602个进程，其中有601个进程休眠了。这好像有点不对劲，内核进程也就80个左右，加上memcached, nginx, mysqld，也不会超出90个。除了这些，剩下的只有php-fpm管理的php-cgi，难道是…？[PS:原来系统原本的进程也才80而已,此处一看就知道内存资源几乎耗尽，但具体是什么进程耗尽了呢？] CPU显示，CPU压力并不大，可以说没有压力。我们再看内存使用概要，发现4G的内存，消耗得所剩余无几(free+buffers)， 95%以上的内存都已分配。交互空间使用情况，我们暂时不去关心。指令top还列出了占用资源最多的进程，运行时间最久(Time+)的mysqld(约2小时)占用资源并不是最多。另外，再看php-cgi,单个php-cgi占用的内存也不算多。所以，可以大胆地猜想：服务器内存资源比较紧张，并没有被某个进程占用大量内存，有可能被某些挂起的进程占着内存没有释放。通过free进一步监控内存使用情况，验证我们的想法。[PS:原来系统原本的进程也才80而已,此处一看就知道内存资源几乎耗尽，但具体是什么进程耗尽了呢？] 2.指令free，了解RAM资源使用情况。当然，你也可以查看文件/proc/meminfo
我们先来看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额定值，需要换出内存页。
[PS:SWPD频繁就意味着你此时的物理内存不够了，当然不一定是“真的”不够，有可能是某种原因造成系统原本够的内存变得不够了]
查看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找出消耗内存的元凶。 [PS:另两篇篇介绍vmstat的文章，此处作者基本判断的就是swpd free si so
http://www.cnblogs.com/ggjucheng/archive/2012/0
虚拟内存简介：
在系统中运行的每个进程都需要使用到内存，但不是每个进程都需要每时每刻使用系统分配的内存空间。当系统运行所需内存超过实际的物理内存，内核会释放某些进程所占用但未使用的部分或所有物理内存，将这部分资料存储在磁盘上直到进程下一次调用，并将释放出的内存提供给有需要的进程使用。
虚拟内存调用过程：
在Linux内存管理中，主要是通过“调页Paging”和“交换Swapping”来完成上述的内存调度。调页算法是将内存中最近不常使用的页面换到磁盘上，把活动页面保留在内存中供进程使用。交换技术是将整个进程，而不是部分页面，全部交换到磁盘上。
分页(Page)写入磁盘的过程被称作Page-Out，分页(Page)从磁盘重新回到内存的过程被称作Page-In。当内核需要一个分页时，但发现此分页不在物理内存中(因为已经被Page-Out了)，此时就发生了分页错误（Page Fault）。SI=Page-in SO=Page-out
vmstat查看参数意义：
bi块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte，我本机上没什么IO操作，所以一直是0，但是我曾在处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s，磁盘写入速度差不多140M每秒
bo块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。
in每秒CPU的中断次数，包括时间中断
cs每秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。
us用户CPU时间，我曾经在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
sy系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
id空闲 CPU时间，一般来说，id + us + sy = 100,一般我认为id是空闲CPU使用率，us是用户CPU使用率，sy是系统CPU使用率。
4.指令ps找出消耗内存的元凶
指令ps比较常用，也比较简单。上面报告结果，我们一眼就可以命中php-cgi这个进程。虽然单个php-cgi占用内存并不算太大，但是503个php-cgi进程，就有点恐怖了。几乎占尽了全部内存（503*0.3%）。我们可以猜想，php-cgi由php-fpm管理，是不是可以php-fpm的某个参数配置不当，导致打开过多的php-cgi进程。
5. 设置php-fpm进程数量管理通过重新将php-conf.conf的max_children值设置为150，系统内存又恢复到正常使用情况。free、si、so、b均表示内存系统资源正常，没有压力。
php-cgi进程释放的内存并不会被系统立即回收，一个php-cgi大概占用20MB内存（取决于你加载的php extensions）。所以，有必要限制你启动的php-cgi进程数量。那么，这个数量多少合适呢，你可以在服务器高峰期通过top统计出php-cgi数量。也可以像php-fpm建议的那样，通过netstat -np | grep 127.0.0.1:9000来收集数据，通过设置max_children使等待的数量尽量小
6.一个php-cgi占用多少内存
一个php-cgi进程，大概占用多少内存呢，大概是20MB(具体的要看你的php加载了多少模块)。可以通过pmap指令查看哪些地方占用了内存。所以，尽量不要加载不必要的php扩展模块，可以减少不必要的内存浪费。