我们在设置pm.max_requests之前必须先要了解php-fpm三种模式：
- 1、静态static
- 2、动态dynamic
- 3、按需ondemand
跟 pm.max_requests设置 有关的，只有动态dynamic模式。
dynamic：动态模式。
相关参数：
- 启动进程数
pm.start_servers - 启动后进程数在
pm.min_spare_servers和pm.max_spare_servers之间 - 超过
pm.max_requests请求数重新生成子进程
再让大家了解一下：
一、pm.max_requests作用是什么?
设置每个子进程重生之前服务的请求数，对于可能存在内存泄漏的第三方模块来说是非常有用的.。
如果设置为 ’0′ 则一直接受请求，等同于 PHP_FCGI_MAX_REQUESTS 环境变量。
默认值: 0
pm.max_requests = 500
这段配置的意思是，当一个 PHP-CGI 进程处理的请求数累积到 500 个后，自动重启该进程。
注意：
pm.max_requests设置得太小也容易出现无进程可用(502状态)，一般来说，普通网站设置max_requests 300~500 合适，但也要结合pm.start_servers和你的网站访问量来看，也可以适当调大和减少，这个是因情况而异的。
二、为什么需要重启进程呢?
一般在项目中，我们多多少少都会用到一些 PHP 的第三方库，这些第三方库经常存在内存泄漏问题，当然了，也有可能是自己写的程序代码。如果不定期重启 PHP-CGI 进程，势必造成内存使用量不断增长。因此 PHP-FPM 作为 PHP-CGI 的管理器，提供了这么一项监控功能，对请求达到指定次数的 PHP-CGI 进程进行重启，保证内存使用量不增长。
正是因为这个机制，在高并发的站点中，经常导致 502 错误，我猜测原因是 PHP-FPM 对从 NGINX 过来的请求队列没处理好。
注意：
有时候由于 php-fpm 有好多闲置的进程一直不释放， 导致内存占用过大，FastCGI 进程一旦加载就不会释放，当其工作完成后，就休眠于 FastCGI 系统池中，等待下一次被唤醒。甚至是php-fpm假死，也会出现502的错误，只能重启php-fpm才能解决这个问题。
例如：Nginx报错upstream timed out (110: Connection timed out) 就是由于pm.max_requests 默认值为0，没有重启所引起的。
目前我们的解决方法是，把这个值尽量设置大些，尽可能减少 PHP-CGI 重新 SPAWN 的次数，同时也能提高总体性能。在我们自己实际的生产环境中发现，内存泄漏并不明显，因此我们将这个值可以设置得非常大。
如果pm.max_requests没有设置重启参数，默认为0不限制最大服务次数，也就是子进程永远不重启，经验表明，长时间不重启子进程会导致系统负载异常，处理时间变长等现象。
总结：
pm.max_requests究竟设置多大?大家要根据自己的实际情况来设置这个值，例如我设置的(204800)不能盲目地加大或设置过小。如果你设置过小，有可能会造成“php-fpm占用cpu和内存过高100% ”。
有时候设置为0，时间久了，占的内存就大了，还一直不释放，如果遇到请求任务过多，处理不过来，还会造成php-fpm子进程假死的情况，那时候就会经常出现502 Bad Gateway的错误，以及你打开.php的文件总是感觉很慢，请求php文件一直处于pending状态。
通俗点讲，设置“pm.max_requests”参数小一点，就是让php-fpm能够自动的频繁重启，关于具体设置多大?要根据你的服务器配置以及流量状况来分析，自己可以去做测试。
经过我的的测试，我发现pm.max_requests设置太大会出现504 Gateway Time-out，pm.max_requests设置太小，平均负载 Load Average又会超出正常值的范围，甚至更高。
