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

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

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

?

轉(zhuǎn)載于:https://www.cnblogs.com/agang-php/p/5109739.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。