Xiuno 高并发实战：PHP-FPM 深度调优与 Opcache 加速全攻略

52JinY 助手

最近有几个朋友问我，Xiuno 论坛在流量稍微大一点之后就开始出现 502、响应变慢的问题，其实这个大概率不是 Xiuno 本身的锅，而是 PHP-FPM 的配置没跟上。今天把我自己踩坑总结出来的东西写下来，希望对有同样困扰的人有用。

首先说 PHP-FPM 的进程池配置。很多人装完环境之后完全不动默认配置，pm 模式直接用 static 或者 dynamic 默认值，进程数低得可怜，一旦并发稍微高一点，请求就开始排队，Nginx 那边等不到响应自然就 502 了。我的建议是服务器内存在 4G 左右的情况下，可以把 pm 改成 dynamic，pm.max_children 设置到 50 左右，pm.start_servers 设 10，pm.min_spare_servers 设 5，pm.max_spare_servers 设 20。这个数字不是固定的，要根据你单个 PHP 进程实际占用的内存来算，用 ps 命令看一下平均内存占用，拿总可用内存除一下，别让进程把内存撑爆，不然系统开始用 swap 反而更慢。

另外一个经常被忽视的参数是 pm.max_requests。这个值控制每个子进程处理多少请求之后自动重启，默认很多发行版是 0，也就是永不重启。听起来省事，但实际上 PHP 进程跑久了会有内存泄漏的问题，特别是装了一些第三方插件的 Xiuno，建议设成 500 到 1000，让进程定期轮换，内存占用会稳定很多。

然后说 Opcache，这个东西开了和没开性能差距是肉眼可见的。Xiuno 是 PHP 框架跑的，每次请求都要解析一堆 PHP 文件，如果没有 Opcache，每次都重新编译，CPU 白白浪费。php.ini 里面把 opcache.enable 设成 1，opcache.memory_consumption 根据你代码量来，Xiuno 加插件的情况下 128M 到 256M 够用了，opcache.max_accelerated_files 建议设到 10000 以上，防止文件数超限之后 Opcache 失效。opcache.validate_timestamps 这个参数生产环境可以设成 0，也就是不检查文件时间戳，性能更好，但代价是改了 PHP 文件之后需要手动 reload 一下 PHP-FPM 才能生效，开发环境就别这么干了。

还有一点容易忽略的是 request_terminate_timeout，这个参数控制 FPM 杀掉超时进程的时间。如果不设，某个慢查询或者卡住的请求会一直占着进程不释放，其他请求只能等。建议设成 30s 到 60s，视你的业务逻辑而定，反正别让僵尸进程一直挂着。

最后提一个调试思路。遇到高并发问题先别急着乱改，先用 php-fpm 的 slowlog 功能，把 request_slowlog_timeout 设成 3s，让系统记录超过 3 秒的请求调用栈，再结合 Nginx 的 access log 看看到底是哪些接口慢。很多时候问题不在 FPM 配置本身，而是某个数据库查询没加索引，或者某个接口在做很重的操作，把这种根源问题解决了，比光调进程数有效得多。

配置这东西没有万能公式，服务器配置不同、流量特征不同，最优参数也不一样，多压测、多观察监控，才是正路。