针对 Fresns 的 PHP-FPM 调优

针对 Fresns 的 PHP-FPM 调优，核心原则与你之前了解的一致：先测量，再计算。Fresns 作为 Laravel 应用，单进程内存占用通常会比纯 API 服务更高（框架本身 + 插件系统），因此对内存预算的估算需要更保守一些。

📋 先看硬性要求：Fresns 的环境门槛

在调优之前，先确认你的 PHP 环境满足 Fresns 的基本要求，否则调优无从谈起：

• PHP 版本：不低于 PHP 8.1，官方推荐 8.2。

• 必需扩展：mbstring、fileinfo、opcache 必须安装。

• 必需函数：symlink、putenv、proc_open、shell_exec、passthru 需要启用，用于插件安装和升级。

• PHP 超时限制：建议适当加大，避免插件依赖下载或大文件上传时超时。

🧮 针对 Fresns 的内存计算

Fresns 的单进程内存占用受已安装插件影响较大，插件越多、逻辑越复杂，单进程 RSS 就越高。

第一步：实测单进程内存

在你的 Fresns 站点经历一次正常访问高峰后，运行以下命令查看所有 php-fpm 进程的平均常驻内存：

ps --no-headers -o rss -C php-fpm | awk '{sum+=$1; n++} END {printf "%d MB avg across %d procs\n", sum/n/1024, n}'

第二步：计算 pm.max_children

通用公式为：(可用内存 × 0.7) ÷ 单进程平均内存。

对于 Fresns，建议将安全系数再收紧一些。假设你的服务器有 4GB 内存，扣除系统、MySQL、Nginx、Redis 后，实际可分配给 PHP-FPM 的约为 2.5GB。若实测单进程平均占用 100MB（考虑到 Laravel 框架和插件加载），则：

pm.max_children ≈ (2560MB × 0.7) ÷ 100MB ≈ 18

宁可稍保守，也不要四舍五入调高，因为 Fresns 在安装插件或执行升级时，进程内存可能会瞬时飙升。

⚙️ 推荐参数配置（以 4GB 内存服务器为例）

基于上述计算，以下是一组针对 Fresns 的参考配置：

pm = dynamic
pm.max_children = 15
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500

参数说明：

• pm.start_servers：建议设为 pm.max_children 的 25%-40% 左右，保证启动时有足够的进程响应初始请求。

• pm.max_requests = 500：Fresns 的插件生态可能导致某些插件存在轻微内存泄漏，设一个较低的阈值（如 500）可以让 worker 定期重启，释放内存。如果确认所有插件都很轻量，可以适当调高。

• pm.max_spare_servers：不建议超过 pm.max_children 的 60%，避免闲置进程占用过多内存。

🔧 Fresns 特有注意事项

1. 长查询字符串导致的 502 错误

Fresns 的账号中心通过插件实现，登录/注册时会传递很长的 “access token” URL。如果 PHP-FPM 或 Nginx 的缓冲区太小，可能触发 502 Bad Gateway。

在 Nginx 配置中增加以下 FastCGI 缓冲区参数：

fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;

2. 队列进程与 PHP-FPM 的关系

Fresns 的队列任务（如通知、邮件）依赖 pcntl_signal 等函数。如果你配置了异步队列（如 Redis 队列），队列 worker 会作为独立的 PHP 进程运行，不占用 PHP-FPM 的进程池，但会消耗额外的内存。在计算 pm.max_children 时，这部分内存需要提前从总预算中扣除。

3. OPcache 必须启用

Fresns 官方要求安装 opcache 扩展。确保 php.ini 中 opcache 已开启，并适当设置 opcache.memory_consumption（建议 128MB 或更高），这对 Laravel 应用的性能提升非常明显。

💡 上线后的验证

调优不是一劳永逸的。配置生效后，关注以下几点：

• 检查 PHP-FPM 错误日志：如果频繁出现 server reached pm.max_children setting，说明进程池打满，请求在排队。此时应先排查是否有慢查询或外部 API 拖慢了进程，而不是盲目调大数值。

• 观察内存：用 free -m 确认系统没有开始使用 swap。一旦 PHP-FPM 进程被挤入 swap，响应速度会断崖式下降。

• 监控 502 错误：如果用户反馈登录/注册时出现 502，优先检查上面提到的 Nginx FastCGI 缓冲区配置。

如果你能告诉我服务器的具体内存大小和当前安装的插件数量，我可以帮你算一组更精确的参考值。