LNMP中PHP-FPM配置详解

LNMP中PHP-FPM配置详解

一 架构与配置文件结构

先快速回顾一下基础：在LNMP环境里，Nginx并不直接处理PHP，而是通过FastCGI协议把请求转给PHP-FPM。PHP-FPM本身采用经典的master/worker模型——master负责统筹调度，worker才是真正干活、执行脚本的。配置文件通常分为两块：全局的php-fpm.conf，以及进程池配置，放在/etc/php/{version}/fpm/pool.d/*.conf目录下，最常见的默认池就是www.conf。

进程间通信方式有两种：Unix socket和TCP。Unix socket走本地文件（比如/run/php/php{version}-fpm.sock），性能通常更好；TCP方式则监听127.0.0.1:9000。如果你管理多个站点，完全可以按需拆分出多个pool，每个pool单独配置资源限制，做到真正的隔离——一个站点崩了不会拉着全站陪葬。

二 核心配置项与推荐值

进程管理（pm）

进程管理模式是重中之重。模式选项上，dynamic是最常用的，能够根据负载自动伸缩；如果你的服务器内存特别富裕、并发请求又很稳定，static模式也可以考虑，提前固定worker数量，省去动态调度的开销。

关键参数有五个：pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers。它们之间有个经验关系：start_servers通常取(min_spare + max_spare) / 2，而且务必确保max_children大于max_spare_servers，否则动态伸缩的上限会被卡死。

请求与脚本控制

pm.max_requests这个参数值得花心思——它控制每个子进程在处理了多少个请求之后自动重启。设置为0意味着永远不重启，但很多第三方扩展可能存在隐性的内存泄漏，累积下去会吃掉大量内存。建议设成1000~5000之间的值，每隔一段时间刷新一下进程，比让问题慢慢酿成事故要稳妥。

request_terminate_timeout是强制性的“一刀切”上限，覆盖PHP脚本自身的max_execution_time，因为有些脚本会设法绕过这个限制。默认0表示不限制，生产环境最好给个合理值，比如30秒或60秒。另一个好搭档是request_slowlog_timeout和slowlog路径，设置成10秒，当脚本执行超过这个时间，PHP-FPM会自动把完整的调用栈记录下来——这可是定位性能瓶颈的利器。

监听与权限

如果你选择Unix socket，那么listen.owner、listen.group和listen.mode必须和Nginx worker进程的用户一致，否则会报Permission denied。通常设置为www:www 0660。如果使用TCP，可以用listen.allowed_clients限制只有特定IP才能连接，增强安全性。

日志与告警

全局日志用error_log和log_level控制。在进程池里，还可以通过php_admin_value[error_log]和php_admin_flag[log_errors]把错误日志写入独立文件，方便按池追踪。此外，pm.status_path和ping.path是监控和存活探测的好帮手——配置一个/status路径可以看到当前进程数、活跃数、排队数等状态，/ping配合pong响应，监控系统拿来探活再方便不过。

资源与系统限制

rlimit_files和rlimit_core分别控制文件描述符上限和core dump开关。并发高的时候，很容易因为文件描述符耗尽遇到“Too many open files”错误，所以这个值建议调大，比如65535。core dump一般生产环境关闭，设为0即可。

三 调优计算与示例配置

调优不是拍脑袋，可以用简单估算来起步。首先，测量你的PHP应用单进程占用的内存——通常看RSS（Resident Set Size），一个跑着框架和OPcache的进程大约在40~120MB之间。然后拿可用内存除以单进程内存，得到理论最大进程数N_max。注意要给系统和其他服务留出余量，别把内存全部吃光。

举个计算例子：假设服务器可用内存8GB，单进程RSS约为80MB，那么N_max ≈ 8192 / 80 ≈ 102。但你的峰值并发可能是150，那这就不够了——要么扩大内存，要么优化单进程内存占用。如果暂时只能这样，可以设置pm.max_children = 120，略超理论值但靠换页扛一扛。动态参数可以这样试：pm.start_servers = 40，pm.min_spare_servers = 20，pm.max_spare_servers = 60，满足start介于min和max之间，且max_children大于max_spare。

下面是一份/etc/php/{version}/fpm/pool.d/www.conf的参考配置片段（注意数字仅为演示，请按实际环境调整）：

进程管理

pm = dynamic
pm.max_children = 120
pm.start_servers = 40
pm.min_spare_servers = 20
pm.max_spare_servers = 60
pm.max_requests = 1000

请求控制

request_terminate_timeout = 0
request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/www-slow.log

监听与权限（Unix socket）

listen = /run/php/php{version}-fpm.sock
listen.owner = www
listen.group = www
listen.mode = 0660

日志与状态

php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
pm.status_path = /status
ping.path = /ping
ping.response = pong

资源限制

rlimit_files = 65535
rlimit_core = 0

如果改用TCP监听，只需把listen改成127.0.0.1:9000，并可以加上listen.allowed_clients = 127.0.0.1限制来源。

四 Nginx 联动与验证

Nginx那边需要配置FastCGI反向袋里。典型的location片段如下：

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php{version}-fpm.sock;
    # 或者 fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
}

改完配置先做语法检查：PHP-FPM用php-fpm -t，Nginx用nginx -t。没问题就重启服务：systemctl start php{version}-fpm和systemctl restart nginx。如果你更喜欢手动信号控制，平滑重启用kill -USR2 ，优雅停止用kill -INT 。

验证方法很简单：创建一个/var/www/html/info.php，内容写，浏览器访问这个文件，如果能正常看到PHP信息页面，说明联动成功。再试试/status和/ping路径——注意防火墙和访问控制要放行，否则会被拦截。

五 监控 日志与常见故障排查

日常运维中，重点盯住三个日志：/var/log/php-fpm.log（PHP-FPM全局日志）、Nginx的error.log，以及你设置的进程池慢日志。配合pm.status_path输出的指标（active、queued、idle等），可以及时发现进程池是否吃紧、是否存在阻塞。

下面列出几个最常遇到的问题及处理思路：

• 502 Bad Gateway：多半是因为PHP-FPM进程不足、崩溃或者监听配置不匹配。先检查pm.max_children是否太小导致进程全部繁忙，再确认FPM是否还在运行，然后核对Nginx的fastcgi_pass地址是否与FPM的listen一致。最后翻看FPM和Nginx的错误日志，基本能定位。
• 504 Gateway Timeout：说明脚本执行超过了FPM设定的超时时间。要么增大request_terminate_timeout，要么优化慢脚本。利用request_slowlog_timeout和slowlog可以精确定位到底是哪个脚本在拖累。
• File not found：通常是SCRIPT_FILENAME拼接错误，或者Nginx的root配置没对上。检查一下Nginx里的fastcgi_param SCRIPT_FILENAME值是否指向了真实存在的文件路径。
• Permission denied（socket）：Unix socket权限问题。确认listen.owner/listen.group/listen.mode与Nginx worker进程用户一致，同时socket文件所在目录也要有适当的权限。

把这些基础打扎实，PHP-FPM的稳定性就有了底气。当然，实际环境千差万别，上面的数值仅作参考，真正的调优必须结合你的业务场景、内存大小和并发模型来做针对性调整。最后再强调一句：日志是最好的老师，遇到问题先看日志，往往比瞎猜要快得多。