1、php-fpm.conf中的pm
pm是來控制php-fpm的工作進程數到底是一次性產生固定不變（static）還是在運行過程中隨著需要動態變化（dynamic）。眾所周知，工作 進程數與服務器性能息息相關，太少則不能及時處理請求，太多則會占用內存過大而拖慢系統。因為php-fpm處理請求時會隨著處理的請求數的增加而占用越 來越多的內存，所以static模式下往往不好判斷啟動的能使內存利用最大化的固定進程數，所以想到了dynamic模式。可是為什么我們不用 dynamic模式呢，試想某個時刻請求數比較低，20個進程足夠應付，突然壓力增大了，出現了40個并發PHP請求，按照最小5個空閑進程的設置就需要 45個進程，也就是說需要在短時間內創建出25個進程，我們知道創建進程的操作是比較消耗系統資源的，再加上40個并發PHP請求肯定也會給MySQL帶 來一定的壓力，此時再創建25個進程無疑是雪上加霜，所以我在這里還是選擇了static模式。

2、php-fpm.conf中的pm.max_requests
根據說明我們知道這個參數的含義是php-fpm工作進程處理完多少請求后自動重啟，主要目的就是為了控制請求處理過程中的內存溢出，使得內存占用在一個 可接受的范圍內。從這里我們感覺這個數字似乎設置的小一點更加有利于性能提升，但是當這個數字非常小的時候會發生一種情況，由于PHP請求是平均地分配給 各個工作進程的，如果這個值太小就會導致所有的工作進程幾乎同時達到這個值并且進入需要重啟的狀態，當所有的工作進程都在同一時刻重啟就會發生在數秒內甚 至更長的時間PHP將停止響應直到所有的進程均重啟完為止。這是不能接受的，所以我一般會把這個值設置為PHP啟動后第一批工作進程達到此值需要重啟時， 第一個進程重啟與最后一個進程重啟之間的時間相差1分鐘以上，一般在壓力比較大的晚上這個差值將會擴大到5分鐘左右，此時對進程重啟對服務器的負面影響就 可以忽略了。

3、php.ini中的memory_limit
顧名思義，這個值是用來限制PHP所占用的內存的，具體一點說就是一個PHP工作進程即php-fpm所能夠使用的最大內存，默認是128MB，一開始在 虛擬機中我設置為PHP 5.1.6的默認值16MB，發現大于16MB的附件將無法下載，也就是說PHP 5.3中附件是從硬盤完整讀取到PHP內存中再傳給nginx的，這跟PHP 5.1.6+Apache 2.2.3不同，后者讀取附件是PHP并不加載這個附件而是直接交給Apache來加載，這就使得php-fpm占用內存大了不少。當php-fpm占用 內存達到了memory_limit所限制的值時，當前進程會被fpm主進程使用TERM信號終止掉，此時被處理的PHP請求將返回客戶端502錯 誤，nginx的error log中將記錄出錯原因是“Connection reset by peer”。可是更加令人難以理解的事情發生了，在使用了eAccelerator的PHP 5.3上，居然發生了當php-fpm內存達到memory_limit所限制的值時，所有進程都開始瘋狂重啟而不再接受任何請求，此時除非使用kill 命令殺死主進程，否則php-fpm永遠都不會恢復響應，可想而知nginx必然出現無止境的502錯誤了。。。

?

轉載于:https://www.cnblogs.com/agang-php/p/5109739.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的PHP的pm、pm.max_requests、memory_limit的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。