今天小編就爲大家分享一篇關於php-fpm中max_children的配置,小編覺得內容挺不錯的,現在分享給大家,具有很好的參考價值,需要的朋友一起跟隨小編來看看吧
現在nginx + fpm 基本成爲主流的配置,其中我們比較關注的是pm.max_chindren的配置
首先,我們關注一個設置: pm = static/dynamic
,
這個選項是標識fpm子進程的產生模式:
static :表示在fpm運行時直接fork出pm.max_chindren
個worker進程
dynamic:表示,運行時fork出start_servers
個進程,隨着負載的情況,動態的調整,最多不超過max_children個進程。
一般推薦用static,優點是不用動態的判斷負載情況,提升性能,缺點是多佔用些系統內存資源。
上面的告訴我們max_chindren代表的worker的進程數。普遍認爲,這個配置越多能同時處理的併發也就越多,這是一個比較大的誤區:
- 1) 其實進程多了,增加進程切換的開銷,更核心的是,能併發執行的fpm進程不會超過cpu個數。通過多開worker的個數來提升qps, 是錯誤的理解,不會說你多開了幾個進程,就多出幾個cpu來處理。
- 2) worker進程開少了,如果server比較繁忙的話,會導到nginx把數據打到fpm的時候,發現所有的woker都在工作中,沒有空閒的worker來接受請求,從而導致502。
- 3) 在實際業務中,由於我們有很多的i/o操作,比如讀取數據庫,或者內部rpc調用這類在等待i/o的過程中,進程會被系統sleep, 而不佔用cpu,如果配置worker少了,也會導致cpu利用不上
那worker數到底該怎麼配置呢?
理論上woker進程數=cpu的個數是最合理的,但由於第2點,可能每個worker都沒處理完請求,這樣,就會頻現502了。但多開進程,只是說避免502,暫時把請求hang住,但這只是緩解之道,實際上這不但不會增加系統的併發,而且會加重系統的負荷,所以,基於2,3 ,設置一個合理的worker數就比較重要了。
天下武功,唯快不破,只有儘可能的提升程序的效率,把單個請求的時間壓縮到最低,這樣,單個worker的處理時間變短了,那在單位時間裏能處理的請求自然就多了。
那麼可以通過每個worker在單位時間內處理的請求數來預估max_children
的個數。假如最大的一個請求的處理時間(xhprof裏看cpu時間)是100ms內,而在100ms之內同時有100個請求過來,那了理論上就需要配置100個worker進程,先把請求給hang住。
但最大的請求耗時可能會受很多外在的情況影響,不太好預估,尤其是網絡i/o也算在裏面,我們可以借用第三方的profile工具,比如xhprof, 這類工具可以統計cpu的耗時,通過這個時間來計算真正的worker數量,比總時間來計算要合理很多,其實這裏有一個捷徑,來配置你的max_children數, 就是你前期先把max_childnren設置成一個比較大的值,穩定運行一段時間後,觀察fpm的status裏的 max active processes
是多少,然後把max_children配置比他大一些就ok了。
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對神馬文庫的支持。如果你想了解更多相關內容請查看下面相關鏈接