max_requests通过强制worker进程定期重启来缓解内存泄漏，因memory_limit仅限单请求内存，而进程长期运行会导致未释放资源持续累积；设为500–2000可平衡稳定性与性能，避免设0或过大，并需配合pm模式、超时及日志配置。
max_requests 是 PHP-FPM 中一个直接干预内存泄漏累积的关键参数，它不修复代码缺陷，但能有效“兜底”——通过主动回收进程，切断持续增长的内存占用链。
max_requests 为什么能缓解内存泄漏
PHP-FPM 的 worker 进程是常驻型的，一个进程会连续处理成百上千个请求。而 memory_limit 只限制单次请求的内存使用，并不限制整个进程生命周期内的累计内存增长。如果代码中存在未释放的全局变量、静态属性、循环引用或扩展层（如某些 C 扩展）导致的资源滞留，内存就会随请求数增加而缓慢堆积。max_requests 的作用就是：当一个 worker 进程处理完设定数量的请求后，自动退出并由新进程替代。旧进程持有的全部内存（包括泄漏部分）被操作系统彻底回收，新进程从干净状态开始，内存占用回归基线。
如何设置合理的 max_requests 值
这个值没有统一标准，需结合实际观测和业务特征调整：
-
先观察再设值：用
ps aux --sort=-%mem | grep php-fpm或systemctl status php-fpm查看各 worker 进程 RSS 内存是否随运行时间明显上升；也可配合pm.status_path开启状态页，统计processes列中的requests和memory字段变化趋势。 -
保守起步：若无历史数据，建议从
500开始（即pm.max_requests = 500），适用于多数中等负载业务。 -
高风险场景调低：如使用老旧扩展、自定义 Zend 扩展、或已知存在 GC 弱点的 PHP 版本（如 < 7.4），可设为
100–300。 -
低风险/高稳定性场景可略高：纯现代框架（Laravel/Symfony + OPcache + PHP 8.2+）、无全局状态缓存的 API 服务，可尝试
1000–2000，减少进程重启开销。 -
避免设为 0 或非常大值：
0表示禁用该机制，失去防护；超过5000后收益递减，且可能掩盖真实泄漏问题。
配合使用的必要配置项
仅靠 max_requests 不够，还需同步检查以下设置，确保机制生效且不引发副作用：
立即学习“PHP免费学习笔记（深入）”；
-
pm = dynamic（或static）：ondemand模式下进程生命周期短，max_requests效果不明显，一般不推荐用于生产 Web 服务。 -
request_terminate_timeout应小于 Nginx 的fastcgi_read_timeout：防止 PHP 进程卡死时被 Nginx 断连，而自身未及时退出。 -
php_admin_value[memory_limit]仍需合理设置（如256M）：它虽不限制进程总内存，但能阻止单次请求失控拖垮整个 worker。 - 日志级别设为
notice或warning：开启log_level = notice，便于捕获child exited on signal类日志，确认进程是否按预期重启。
不复杂但容易忽略
