WebService之nginx+(php-fpm)結構模型剖析及最佳化

標籤：nginx php-fpm webservice php架構 5xx

  隨著php指令碼語言使用的普及，目前webserice服務大部分都在用nginx+(php-fpm)的結構，瞭解了其工作過程後才可以在各個方面想辦法做調整最佳化和故障排查，從以下幾點總結一下這種模型。

一、nginx和php-fpm的關係和分工

nginx是web伺服器，php-fpm是一個PHPFastCGI進程管理器，兩者遵循fastcgi的協議進行通訊，nginx負責靜態類似html檔案的處理，php-fpm負責php指令碼語言的執行，這麼設計的目的是為瞭解耦前端nginx和後端的php，不至於讓容易出問題的php指令碼堵塞整個nginx的業務處理，影響使用者體驗，因為php指令碼語言的執行是會比較容易出問題的。nginx之所以能處理成千上萬高並發業務，除其本身的非同步非阻塞模式，在與和其他模組的耦合擴充方法也是分不開的，在nginx的設計裡不能接受的就是阻塞，不過並非完全沒有梗，比如說用到的最多的多進程單線程的模式，由於nginx日誌沒有單獨的處理進程，如果收集日誌時處理不當就會把worker進程堵死。

  對應nginx+php-fpm的模型結構圖如下：

650) this.width=650;" src="http://s2.51cto.com/wyfs02/M00/86/E5/wKioL1fOU-fiLC8nAAEc-FGrRjo932.png" title="nginx+php-fpm結構模型.png" alt="wKioL1fOU-fiLC8nAAEc-FGrRjo932.png" />

（圖 1）

1、nginx的工作簡介（對應圖1看）

在接到php的指令碼請求後，nginx通過fastcgi_pass指令將請求傳遞給後端php-fpm的worker進程處理，在此過程中，nginx做了各種逾時機制、緩衝機制、buffer機制和長串連機制等來保障與後端的php-fpm能夠良性高效的合作。

在逾時機制方面控制nginx對後端php的等待時間，通過各種timeout指令進行控制，例如：

fastcgi_connect_timeout   後端連結時間

fastcgi_send_timeout    資料發送時間，兩次成功發送時間差，不是整個發送時間

fastcgi_read_timeout    資料接收時間，兩次成功接收時間差，不是整個接收時間

  當逾時後會返回504逾時的狀態代碼，在buffer機制指令也有很多，例如：

fastcgi_buffer_size 存放fastcgi傳過來的回應標頭，一般設定為分頁大小

fastcgi_buffers 存放fastcgi傳過來的相應內容，一般設定分頁的倍數，格式例如 8  4k|8k

  另外還有一些其它的緩衝、長串連機制不做介紹，當設定不合理時也會出現5XX錯誤，nginx的文章介紹寫了有很多的，不再做過多的說明。

 

2、php-fpm工作介紹（對應圖1看）

Php-fpm是一個PHPfastcgi進程管理器，在啟動後會有master和worker兩種進程，master負責接收外部訊號和管理worker進程，worker進程是負責幹活的，處理nginx傳過來的任務。

master進程只有一個，負責監聽連接埠和管理worker進程，每次傳來任務，與前端的nginx建立3次握手後放入串連隊列，供worker進程進行accept，當worker進程出現錯誤或執行逾時時，負責將worker進程重啟或者殺掉，是php-fpm模型中的大內總管。

Worker進程是背景工作處理序，每個worker進程都獨立的執行php程式指令碼，然後把執行的結果通過fastcgi協議交給nginx，執行過程中受master的管理。在工作中，worker進程去競爭accept管理進程master的連結隊列，accept函數將從串連請求隊列中獲得串連資訊，建立新的socket，並返回該通訊端的fd，新建立的socket用於伺服器與nginx的通訊，而原來的通訊端仍然處於監聽狀態。

php-fpm可以配置多個pool，所有pool由master統一管理監聽不同連接埠並分配不同worker進程池，worker進程池支援動態prefork同時也支援靜態開啟，伺服器記憶體較大時建議直接計算後配置靜態資源池，可以減少頻繁prefork進程所帶來的開銷，提高服務品質，由於進程模型越跑程式耗費越大，因為每個worker進程可以配置執行多少個請求後進行重啟，對應的池子的指令和執行多少個請求的指令如下：

pm = static | dynamic | ondemand 靜態池、服務優先、記憶體優先

pm.max_children = 256  開啟的最大php進程數

pm.max_requests = 1024   在執行了1024個請求後重啟worker進程

   這也是我們線上伺服器的配置，我們線上用的web服務的機器是12核cpu、16G記憶體，nginx開啟12個worker進程，php開啟256個進程，跑起來後每個進程大概佔用30M記憶體，也就是（256+12）*30=8G ，另外還跑了一些配管、監控、統計、日誌收集等七七八八的軟體，整體業務是比較輕鬆的，這種靜態池的配置大大減少了prefork進程帶來的開銷，RT時間100ms以內的佔到85%（這個與程式寫的如何有關），運行一段時間後的開銷如下：

650) this.width=650;" src="http://s4.51cto.com/wyfs02/M02/86/E6/wKiom1fOVyGwRrByAAB0HEoKVdw112.png" title="QQ20160906134111.png" alt="wKiom1fOVyGwRrByAAB0HEoKVdw112.png" />

 

二、此模型結構常見的5XX伺服器端錯誤及最佳化（對應圖1看） 

1、nginx日誌裡產生502錯誤

  第一種情況，php-fpm的worker進程執行php程式指令碼時，超過了配置的最長執行時間，master進程將worker進程殺掉，直接返回502。

返回502後nginx對應的error日誌是104: Connection reset by peer

對應的php執行時間的配置如下，一些版本中php-fpm的配置會覆蓋php.ini的配置，使php.ini的配置不起作用：

php.ini中預設30s：max_execution_time =

php-fpm中：request_terminate_timeout =

  第二種情況，串連請求數（accpet之前）超出了連接埠所能監聽的tcp串連的最大值（backlog的值），進不了fpm等待accept的連結隊列，直接返回502，這裡可能會產生tcp重傳；

返回502後nginx對應的error日誌是111: Connection refused

   backlog的值是半串連和全串連的總和，他的存在也有短時間緩衝解耦nginx請求與fpm處理的作用，半串連指收到了syn請求，3次握手尚未建立，全串連指的是3次握手已經成功，不過尚未被accpet的請求，fpm裡面有調節的參數，如果fpm的參數設定為-1，則預設走的是系統核心參數net.core.somaxconn的設定值，如果不設定可以在/proc/sys/net/core/somaxconn裡查看，預設值是128，所以在串連請求較高的業務裡要增大這個值。

  

• 減少避免502報錯最佳化建議

502主要從php-fpm的配置方考慮，根據伺服器情況，適量增大php-fpm的背景工作處理序數，適當增加php的執行時間，適當增加backlog值。

php的背景工作處理序數也不是越大越好，這種進程模型已耗用時間長了占的記憶體會增大，一般一個php進程是佔到30M左右的記憶體，開多少合適自己算吧，nginx的worker進程一般也能跑到30M的記憶體，綜合計算一下；php的執行時間可以根據你的服務標準來設定，超過服務時間瀏覽器返回的是502錯誤，這個按照實際的情況處理吧，反正我是覺得執行的慢有返回結果總比直接返回502錯誤的強；至於backlog值，當程式寫的比較好時，建議設定其數量為php背景工作處理序的1到2倍。

  

2、nginx日誌裡產生504錯誤

  第一種情況，php的worker進程池處理慢，無法儘快處理等待accept的連結隊列，導致3次握手後的連結隊列長時間沒有被accept，nginx連結等待逾時；

返回504後nginx對應的error日誌是110: Connection timed out

  第二種情況，後端php-fpm執行指令碼的時間太長，超過了nginx配置的逾時機制，這個時候也是會報出504錯誤的。

• 減少避免504報錯的最佳化建議

504主要從nginx的配置方考慮，根據業務情況配置好逾時的各種機制，包含但不限於下屬參數：

fastcgi_connect_timeout

fastcgi_send_timeout 

fastcgi_read_timeout 

。。。。。。。。

另外：在配置過程中，比如遇到大並發或者是特殊業務的情境，不合理的fd、buffer等設定也會帶來5XX錯誤，比如說大並發串連的業務要增大系統和單個程式的fd數量，如果是上傳業務要增大頭buffer等，這些要視情況而做最佳化，正所謂道法自然，術變萬千，要以不變應萬變。

本文出自 “奔跑的linux” 部落格，請務必保留此出處http://benpaozhe.blog.51cto.com/10239098/1846784

WebService之nginx+(php-fpm)結構模型剖析及最佳化