事故现象:
机房一台服务器运行一段时间后,突然发现系统资源即将被耗尽!
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的设置。
sort -k3 -rn表示按照第3列的值进行降序排列 [root@localhost ~]# ps -A -o comm,pmem,pcpu|uniq -c|head -2 1 COMMAND %MEM %CPU 1 init 0.0 0.0 [root@localhost ~]# ps -A -o comm,pmem,pcpu|uniq -c|sort -k1 -rn|head -5 89 zabbix_server 0.0 0.0 59 oracle 2.0 0.0 40 events_power_ef 0.0 0.0 8 nginx 0.0 0.0 7 zabbix_server 0.0 0.0 [root@localhost ~]# ps -A -o comm,pmem,pcpu|uniq -c|sort -k3 -rn|head -5 4 oracle 33.8 0.6 5 oracle 32.3 0.0 1 oracle 15.1 0.5 1 oracle 15.0 0.5 1 oracle 14.9 0.5