我們在設置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又會超出正常值的范圍，甚至更高。