現(xiàn)在nginx + fpm 基本成為主流的配置，其中我們比較關注的是pm.max_chindren的配置

首先，我們關注一個設置： pm = static/dynamic，

這個選項是標識fpm子進程的產(chǎn)生模式：

static ：表示在fpm運行時直接fork出pm.max_chindren個worker進程

dynamic：表示，運行時fork出start_servers個進程，隨著負載的情況，動態(tài)的調(diào)整，最多不超過max_children個進程。

一般推薦用static，優(yōu)點是不用動態(tài)的判斷負載情況，提升性能，缺點是多占用些系統(tǒng)內(nèi)存資源。

上面的告訴我們max_chindren代表的worker的進程數(shù)。普遍認為，這個配置越多能同時處理的并發(fā)也就越多，這是一個比較大的誤區(qū)：

• 1) 其實進程多了，增加進程切換的開銷，更核心的是，能并發(fā)執(zhí)行的fpm進程不會超過cpu個數(shù)。通過多開worker的個數(shù)來提升qps， 是錯誤的理解，不會說你多開了幾個進程，就多出幾個cpu來處理。
• 2) worker進程開少了，如果server比較繁忙的話，會導到nginx把數(shù)據(jù)打到fpm的時候，發(fā)現(xiàn)所有的woker都在工作中，沒有空閑的worker來接受請求，從而導致502。
• 3) 在實際業(yè)務中，由于我們有很多的i/o操作，比如讀取數(shù)據(jù)庫，或者內(nèi)部rpc調(diào)用這類在等待i/o的過程中，進程會被系統(tǒng)sleep, 而不占用cpu，如果配置worker少了，也會導致cpu利用不上

那worker數(shù)到底該怎么配置呢？

理論上woker進程數(shù)=cpu的個數(shù)是最合理的，但由于第2點，可能每個worker都沒處理完請求，這樣，就會頻現(xiàn)502了。但多開進程，只是說避免502，暫時把請求hang住，但這只是緩解之道，實際上這不但不會增加系統(tǒng)的并發(fā)，而且會加重系統(tǒng)的負荷，所以，基于2，3 ，設置一個合理的worker數(shù)就比較重要了。

天下武功，唯快不破，只有盡可能的提升程序的效率，把單個請求的時間壓縮到最低，這樣，單個worker的處理時間變短了，那在單位時間里能處理的請求自然就多了。

那么可以通過每個worker在單位時間內(nèi)處理的請求數(shù)來預估max_children的個數(shù)。假如最大的一個請求的處理時間(xhprof里看cpu時間)是100ms內(nèi)，而在100ms之內(nèi)同時有100個請求過來，那了理論上就需要配置100個worker進程，先把請求給hang住。

但最大的請求耗時可能會受很多外在的情況影響，不太好預估，尤其是網(wǎng)絡i/o也算在里面，我們可以借用第三方的profile工具，比如xhprof, 這類工具可以統(tǒng)計cpu的耗時，通過這個時間來計算真正的worker數(shù)量，比總時間來計算要合理很多，其實這里有一個捷徑，來配置你的max_children數(shù)， 就是你前期先把max_childnren設置成一個比較大的值，穩(wěn)定運行一段時間后，觀察fpm的status里的 max active processes 是多少，然后把max_children配置比他大一些就ok了。

總結

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。如果你想了解更多相關內(nèi)容請查看下面相關鏈接

最新評論