PHP-FPM 慢日志 + 进程池调优：502 背后的真相

线上偶发 502，Nginx 日志里 upstream 报错，第一反应可能是 PHP 代码问题，但先看 PHP-FPM 这边：

1. 先开慢日志定位
php-fpm.conf 里配好 slowlog 和 request_slowlog_timeout（比如 5s），502 高峰期去看慢日志，到底是哪个脚本、哪一行卡住了。很多"偶发 502"其实是某个 SQL 或外部 HTTP 调用超时。

2. 进程池配得对不对
pm = dynamic 时，pm.max_children 太小会导致请求排队超时。估算方法：max_children 约等于 内存 / 单个 PHP 进程常驻内存。别拍脑袋配 50，先 ps 看单个 php-fpm 进程 RSS 再算。

3. pm.max_requests 防内存泄漏
PHP 进程跑久了内存慢慢涨，设 pm.max_requests = 500~1000 让 worker 定期重启，是治"越跑越慢"的土办法但有效。

4. 区分 502 的三种脸
- 连接被拒：FPM 进程池满了或挂了，看 listen 队列。
- 网关超时：后端处理超过 Nginx 的 proxy 超时，先看慢日志。
- 固定时间点 502：八成是定时任务（crontab 重启 FPM、日志切割）搞的，对一下时间。

5. 监控别只看 502 率
把 FPM 的 status 页打开（pm.status_path），监控 active processes 和 listen queue 长度，队列开始堆积时先扩容，别等 502 爆了再救火。

你们线上 PHP-FPM 的 max_children 一般按什么配的？

慢日志 + 进程池这条排查主线很实用，补充几个和 502 强相关的细节：

1. request_slowlog_timeout 建议略低于 Nginx 的 proxy_read_timeout，这样慢日志会先于网关超时出现，定位更完整；两者一样时，常常只看见 502 看不见慢栈。
2. pm = dynamic 时除了 max_children，还要看 pm.start_servers / min_spare / max_spare，高峰来临前预热不够会出现「短暂全 502 然后恢复」。
3. listen 用 backlog 时，用 ss -ltn 看 Recv-Q 是否顶满；顶满说明 accept 不过来，这时加机器比加 max_children 更有效。
4. 固定整点 502：对一下日志切割脚本是否向 FPM 发了 reload；reload 瞬间 worker 重启会造成毛刺，可改为平滑策略或错峰切割。

监控上把 listen queue 和 max children 使用率一起告警，比只盯 502 率更早。你们用 static 池还是 dynamic 为主？