#测试php-fpm配置/usr/local/php/sbin/php-fpm -t/usr/local/php/sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf -t #启动php-fpm/usr/local/php/sbin/php-fpm/usr/local/php/sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf #关闭php-fpmkill -int `cat /usr/local/php/var/run/php-fpm.pid` #重启php-fpmkill -usr2 `cat /usr/local/php/var/run/php-fpm.pid`
复制代码
二，php-fpm.conf重要参数详解
$ctx = stream_context_create(array( 'http' => array( 'timeout' => 10 //设置一个超时时间，单位为秒 ))); file_get_contents($str, 0, $ctx);
复制代码
2,max_requests参数配置不当，可能会引起间歇性502错误：pm.max_requests = 1000设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 ’0′ 则一直接受请求. 等同于 php_fcgi_max_requests 环境变量. 默认值: 0.这段配置的意思是，当一个 php-cgi 进程处理的请求数累积到 500 个后，自动重启该进程。
但是为什么要重启进程呢？
一般在项目中，我们多多少少都会用到一些 php 的第三方库，这些第三方库经常存在内存泄漏问题，如果不定期重启 php-cgi 进程，势必造成内存使用量不断增长。因此 php-fpm 作为 php-cgi 的管理器，提供了这么一项监控功能，对请求达到指定次数的 php-cgi 进程进行重启，保证内存使用量不增长。
正是因为这个机制，在高并发的站点中，经常导致 502 错误，我猜测原因是 php-fpm 对从 nginx 过来的请求队列没处理好。不过我目前用的还是 php 5.3.2，不知道在 php 5.3.3 中是否还存在这个问题。
目前我们的解决方法是，把这个值尽量设置大些，尽可能减少 php-cgi 重新 spawn 的次数，同时也能提高总体性能。在我们自己实际的生产环境中发现，内存泄漏并不明显，因此我们将这个值设置得非常大（204800）。大家要根据自己的实际情况设置这个值，不能盲目地加大。
话说回来，这套机制目的只为保证 php-cgi 不过分地占用内存，为何不通过检测内存的方式来处理呢？我非常认同高春辉所说的，通过设置进程的峰值内在占用量来重启 php-cgi 进程，会是更好的一个解决方案。
3,php-fpm的慢日志，debug及异常排查神器：request_slowlog_timeout设置一个超时的参数，slowlog设置慢日志的存放位置tail -f /var/log/www.slow.log上面的命令即可看到执行过慢的php过程。
大家可以看到经常出现的网络读取超过、mysql查询过慢的问题，根据提示信息再排查问题就有很明确的方向了。