php-fpm 启动参数配置详解

需要约定几个目录

2. #测试php-fpm配置
3. /usr/local/php/sbin/php-fpm -t
4. /usr/local/php/sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf -t
6. #启动php-fpm
7. /usr/local/php/sbin/php-fpm
8. /usr/local/php/sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf
10. #关闭php-fpm
11. kill -int `cat /usr/local/php/var/run/php-fpm.pid`
13. #重启php-fpm
14. kill -usr2 `cat /usr/local/php/var/run/php-fpm.pid`

复制代码

二，php-fpm.conf重要参数详解

2. $ctx = stream_context_create(array(
3. 'http' => array(
4. 'timeout' => 10 //设置一个超时时间，单位为秒
5. )
6. ));
8. 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查询过慢的问题，根据提示信息再排查问题就有很明确的方向了。