站長資訊網(wǎng)
現(xiàn)在nginx + fpm 基本成為主流的配置，其中我們比較關(guān)注的是pm.max_chindren的配置
首先，我們關(guān)注一個(gè)設(shè)置： pm = static/dynamic。
相關(guān)學(xué)習(xí)推薦：PHP編程從入門到精通
這個(gè)選項(xiàng)是標(biāo)識(shí)fpm子進(jìn)程的產(chǎn)生模式：
static ：表示在fpm運(yùn)行時(shí)直接fork出pm.max_chindren個(gè)worker進(jìn)程
dynamic：表示，運(yùn)行時(shí)fork出start_servers個(gè)進(jìn)程，隨著負(fù)載的情況，動(dòng)態(tài)的調(diào)整，最多不超過max_children個(gè)進(jìn)程。
一般推薦用static，優(yōu)點(diǎn)是不用動(dòng)態(tài)的判斷負(fù)載情況，提升性能，缺點(diǎn)是多占用些系統(tǒng)內(nèi)存資源。
上面的告訴我們max_chindren代表的worker的進(jìn)程數(shù)。普遍認(rèn)為，這個(gè)配置越多能同時(shí)處理的并發(fā)也就越多，這是一個(gè)比較大的誤區(qū)：
- 1) 其實(shí)進(jìn)程多了，增加進(jìn)程切換的開銷，更核心的是，能并發(fā)執(zhí)行的fpm進(jìn)程不會(huì)超過cpu個(gè)數(shù)。通過多開worker的個(gè)數(shù)來提升qps， 是錯(cuò)誤的理解，不會(huì)說你多開了幾個(gè)進(jìn)程，就多出幾個(gè)cpu來處理。
- 2) worker進(jìn)程開少了，如果server比較繁忙的話，會(huì)導(dǎo)到nginx把數(shù)據(jù)打到fpm的時(shí)候，發(fā)現(xiàn)所有的woker都在工作中，沒有空閑的worker來接受請求，從而導(dǎo)致502。
- 3) 在實(shí)際業(yè)務(wù)中，由于我們有很多的i/o操作，比如讀取數(shù)據(jù)庫，或者內(nèi)部rpc調(diào)用這類在等待i/o的過程中，進(jìn)程會(huì)被系統(tǒng)sleep, 而不占用cpu，如果配置worker少了，也會(huì)導(dǎo)致cpu利用不上
那worker數(shù)到底該怎么配置呢？
理論上woker進(jìn)程數(shù)=cpu的個(gè)數(shù)是最合理的，但由于第2點(diǎn)，可能每個(gè)worker都沒處理完請求，這樣，就會(huì)頻現(xiàn)502了。但多開進(jìn)程，只是說避免502，暫時(shí)把請求hang住，但這只是緩解之道，實(shí)際上這不但不會(huì)增加系統(tǒng)的并發(fā)，而且會(huì)加重系統(tǒng)的負(fù)荷，所以，基于2，3 ，設(shè)置一個(gè)合理的worker數(shù)就比較重要了。
天下武功，唯快不破，只有盡可能的提升程序的效率，把單個(gè)請求的時(shí)間壓縮到最低，這樣，單個(gè)worker的處理時(shí)間變短了，那在單位時(shí)間里能處理的請求自然就多了。
那么可以通過每個(gè)worker在單位時(shí)間內(nèi)處理的請求數(shù)來預(yù)估max_children的個(gè)數(shù)。假如最大的一個(gè)請求的處理時(shí)間(xhprof里看cpu時(shí)間)是100ms內(nèi)，而在100ms之內(nèi)同時(shí)有100個(gè)請求過來，那了理論上就需要配置100個(gè)worker進(jìn)程，先把請求給hang住。
但最大的請求耗時(shí)可能會(huì)受很多外在的情況影響，不太好預(yù)估，尤其是網(wǎng)絡(luò)i/o也算在里面，我們可以借用第三方的profile工具，比如xhprof, 這類工具可以統(tǒng)計(jì)cpu的耗時(shí)，通過這個(gè)時(shí)間來計(jì)算真正的worker數(shù)量，比總時(shí)間來計(jì)算要合理很多，其實(shí)這里有一個(gè)捷徑，來配置你的max_children數(shù)， 就是你前期先把max_childnren設(shè)置成一個(gè)比較大的值，穩(wěn)定運(yùn)行一段時(shí)間后，觀察fpm的status里的 max active processes 是多少，然后把max_children配置比他大一些就ok了。
