Archive for 五月, 2014

在几个不是很繁忙的线上服务器发现php-fpm进程数达到500多,且存在一些运行时间长达几个月的进程。

进行了以下排查,以确定:phpfpm运行是否有问题,是否需要重启。

查看这些进程是否被正常启动

由于php-fpm.log中,会以notice级别打印worker进程的启动和回收时间,故可以通过以下语句检查有哪些php没有被记录到(ps axuf可以查看到进程的父子关系):

$cd /path/to/php-fpm.log

$for word in `ps axu | grep php | perl -ne 'chomp; @tmp=split " +", $_; print $tmp[1]."\n";'` ; do  if grep $word php-fpm.log >/dev/null ; then echo -n ''; else echo $word;  fi ; done

执行结果,发现有173个进程未被记录,一部分有可能是在php-fpm父进程启动时,直接fork出来的,所以未记录。但还剩余几十个,我也不知道啥原因了。

确认进程是否存活

通过root帐号登录上去,strace -p <pid>,其中pid是上面173个进程之一。发现正常滚动,并能看到对php方法的调用,故确定该进程存活,且可以提供服务。

为什么有这么多进程存在呢?

虽然对服务没有影响,但这么多进程存在,是否正常呢?

首先得看下php-fpm.conf:

pm = dynamic
pm.max_children = 8192
pm.start_servers = 128
pm.min_spare_servers = 128
pm.max_spare_servers = 1024
pm.max_requests = 500000

 

由于我们的空闲进程配置为128 ~ 1024,而max_request配置为50w,并且之前机器流量不大,所以可能很长一段时间,进程都不会因为处理完了max_request个请求、或者超过了spare_servers个数 而被回收。

而一个php-fpm进程占用12m左右非共享内存,根据机器配置,cpu、内存配置来看,支持1k个php-fpm进程是足够的。

可能出现什么问题?

为什么会对php进程数这么紧张呢?一个是假如php进程在进行网络连接时,遇到了丢包等问题,有可能会导致进程hang住,这样就相当于白白浪费机器资源了。另一个是,据说在某些情况下,php worker进程不会被正常回收,这也是需要避免的问题。另外,任何一个软件都不可能完全避免bug,我们也需要保持警惕,以免触发了某些未知的问题。