phpfpmmaxchildren

⑴ 啟動php-fpm時是怎麼載入php.ini

php.ini：決定php語言運行的環境，支持擴展的模塊,開發環境的配置

php-fpm.conf：進程式控制制管理器配置文件，控制php-cgi的進程數，常駐內存，提高web服務的響應速率，php-cgi運行時會載入這兩個配置文件。

⑵ 遠程伺服器返回錯誤：（502）錯誤的網關 是什麼原因、

502錯誤原因分析：

1、這類錯誤常見於Nginx+PHP的Web架構，Nginx將請求提交給網關PHP-FPM執行，但是由於某些原因請求沒有執行完畢導致PHP-FPM進程終止執行。說到此，這個問題就很明了了，與網關服務如PHP-FPM的配置有關了。

2、php-fpm.conf配置文件中有兩個參數就需要你考慮到，分別是max_children和request_terminate_timeout。

3、max_children最大子進程數，在高並發請求下，達到php-fpm最大響應數，後續的請求就會出現502錯誤的。可以通過netstat命令來查看當前連接數。

4、request_terminate_timeout設置單個請求的超時終止時間。還應該注意到php.ini中的max_execution_time參數。當請求終止時，也會出現502錯誤的。

5、當積累了大量的php請求，你重啟php-fpm釋放資源，但一兩分鍾不到，502又再次呈現， 這時還應該考慮到資料庫，查看下資料庫進程是否有大量的locked進程，資料庫死鎖導致超時，前端終止了繼續請求，但是SQL語句還在等待釋放鎖，這時就要重啟資料庫服務了或kill掉死鎖SQL進程了。

6、所以在調整max_children和request_terminate_timeout、max_execution_time也需要考慮到伺服器資源使用情況及應用代碼sql執行效率情況，需要綜合衡量。502 Bad Gateway：伺服器作為網關或者代理時，為了完成請求訪問下一個伺服器，但該伺服器返回了非法的應答。 亦說Web伺服器用作網關或代理伺服器時收到了無效響應。

⑶ 512m內存的vps的php-fpm.conf的max-children開多少比較合理

這個視伺服器系統配置而定，生產環境下，你512M內存，設置在15-20個左右吧。滲爛
按衡喊陸每個進程20M計算的話，15-20個大約在300-400M以內。加上你mysql以及系統進程所佔用的內存，這個值是相對合理的。不然很可能內存不足報咐頃502錯誤。

⑷ 502 bad gateway nginx怎麼解決

在http協議中，502 狀態碼（Bad Gateway）是指錯誤網關或者無效網關。在nginx中，出現 502 bad gateway則表示nginx代理的upstream模塊發生錯誤或者upstream模塊不可達。

例如，nginx的後端配置的是php作為fastcgi，則當php沒有啟動的時候，訪問時則會出現

502 bad gateway的提示，具體的錯誤信息如下圖所示：

因此，當出現該提示時，應該去檢查nginx的upstream模塊是否正常（例如檢查php是否啟動），如果upstream模塊沒有啟動，則啟動upstream模塊就可以解決。

⑸ php-fpm怎麼連接的mysql

們都知道，php是不能直接操作 mysql的，他需要通過擴展提供介面調用，php的mysql擴展也好幾個，只支持面向過程的mysql，既支持面向過程也支持面向對象的mysqli，只支持面向對象的PDO，當然無論是那個擴展，也只是php語法寫法上的區別而已，底層其實是一樣的。
今天我們不講語法這些老掉牙的東西，我們隨便找一個擴展，來分析一下 php底層 和 mysql 之間的通信原理。
首先我們來理解一下 php-fpm 的工作原理，php-fpm 是一個 php-cgi 進程管理器，其實就是一個連接池，它和nginx配合的工作原理如下。
我們先從最簡單的靜態方式入手觀察他的工作原理
vim php-fpm.ini
[www]
pm = static
pm.max_children = 5
pm.max_requests = 2
上面三句話的含義是什麼呢:
1、static 表示靜態以靜態方式生成 php-fpm 進程
2、pm.max_children = 5 表示當 php-fpm 啟動時就啟動 5 個 php-fpm 子進程 等待處理 nginx 發過來的請求
3、pm.max_requests = 2 表示每個 php-fpm 子進程處理 2 個請求就銷毀，當然父進程每次看到有銷毀的自然也就會生成新的子進程
我們來簡單驗證一下這個說法：
首先重啟 php-fpm，讓它復位一下
接下來寫一條簡單的語句輸出當前進程ID
echo "當前 php-fpm 進程ID：".posix_getpid();
不斷刷新瀏覽器觀察輸出變化
當前 php-fpm 進程ID：24548
當前 php-fpm 進程ID：24549
當前 php-fpm 進程ID：24550
當前 php-fpm 進程ID：24547
當前 php-fpm 進程ID：24551
當前 php-fpm 進程ID：24548
當前 php-fpm 進程ID：24549
當前 php-fpm 進程ID：24550
當前 php-fpm 進程ID：24547
當前 php-fpm 進程ID：24551
當前 php-fpm 進程ID：24563
當前 php-fpm 進程ID：24564
當前 php-fpm 進程ID：24565
當前 php-fpm 進程ID：24566
當前 php-fpm 進程ID：24567
當前 php-fpm 進程ID：24563
當前 php-fpm 進程ID：24564
當前 php-fpm 進程ID：24565
當前 php-fpm 進程ID：24566
當前 php-fpm 進程ID：24567
當前 php-fpm 進程ID：24568
當前 php-fpm 進程ID：24569
當前 php-fpm 進程ID：24570
當前 php-fpm 進程ID：24571
當前 php-fpm 進程ID：24572
當前 php-fpm 進程ID：24568
當前 php-fpm 進程ID：24569
當前 php-fpm 進程ID：24570
當前 php-fpm 進程ID：24571
當前 php-fpm 進程ID：24572
可以看得出，第一批id不是按照順序執行的，進程id為24547的進程是在第四位處理的，然後從下面開始，所有id都是順序執行的而且每次生成的一批id都是遞增，是不是有種mysql自增主鍵的趕腳呢？
這里需要注意的是，無論是靜態還是下面的動態配置方式，只要沒有設置 max_requests ，那麼進程是不會銷毀的，也就是說當一個進程裡面出現死循環或者內存溢出等導致進程僵死的情況出現的時候，處理的進程就會少一個了
好吧理解了靜態的處理方式，我們其實也很容易知道這個方式的弊端了，當然我們平時伺服器不可能就開5個進程每個進程處理2個請求，我們來做一個簡單的加減乘除，看看一個伺服器應該開多少個 php-fpm 合適
首先我們來看看一個簡單的echo需要多少內存：
$size = memory_get_usage();
$unit = array('b','kb','mb','gb','tb','pb');
$memory = @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i];
echo "當前 php-cgi 進程所使用內存：".$memory;
觀察瀏覽器我們可以得到一下數據：
當前 php-cgi 進程所使用內存：227.17 kb
也就是說一個簡單的什麼都不幹的php就已經佔用了200多K的內存，當然這也不算多。
不過進程多了cpu切換進程速度就會變慢，所以這個數還是需要通過ab等測試工具才能測試出具體應該開多少比較合理
我們先從200開始，不斷的增加，架設增加到800的時候，效率和400一樣，那我們就沒必要開800那麼多進程浪費內存了。
那麼問題就來了，如果同一時間請求出超過400呢？有人說會排隊等待，真的會排隊等待嗎？答案明顯是 php-fpm 是沒能力排隊了，因為處理請求的php-fpm子進程都用完了，那麼等待也就只能是在 nginx 等待，通常一個 nginx 也不只是轉發請求給 php-fpm 就完事了，他還要處理靜態文件呢？如果這些php請求導致nginx的請求數過多一直在等待，那麼訪問靜態文件自然也會卡了，這時候我們就需要配置成下面的動態處理方式。
[www]
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 8
;pm.max_requests = 2
上面五句話的含義是什麼呢:
1、dynamic 表示靜態以動態方式生成 php-fpm 進程
2、pm.max_children = 10 同時活動的進程數 10個
3、pm.start_servers = 5 表示當 php-fpm 主進程啟動時就啟動 5 個 php-fpm 子進程
4、pm.min_spare_servers = 2 表示最小備用進程數
5、pm.max_spare_servers = 8 表示最大備用進程數
6、pm.max_requests = 2 上面說過就不說了
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274

⑹ PHP進程管理三種模式

ondemand：按請示創建進程數；

dynamic:初始化啟動number進程數；

static：固定啟動進程數；

php-fpm進程管理一共有三種模式： ondemand、static、dynamic ，我們可以在同一個fpm的master配置三種模式，看下圖1。php-fpm的工作模式和nginx類似，都是一個master，多個worker模型。每個worker都在accept本pool內的監聽套接字（linux已不存在驚群現象）。

ondemand

在php-fpm啟動的時候，不會給這個pool啟動任何一個worker，是按需啟動，當有連接過來才會啟動。

配置文件（我的配置文件地址為：/usr/local/php/etc/php-fpm.conf）

當前pool的名字為test

原理

 ondemand原理圖

1. 從上圖可以看出，新建worker的觸發條件是連接的到來，而不是實際的請求（例如，只進行連接比如telnet，不發請求數據也會新建worker）

2. worker的數量受限於pm.max_children配置，同時受限全局配置process.max（准確的說，三種模式都受限於全局配置）

3.1秒定時器作用

找到空閑worker，如果空閑時間超過pm.process_idle_timeout大小，關閉。這個機制可能會關閉所有的worker。

配置項要求

1. pm.max_children> 0

2. pm.process_idle_timeout> 0，如果不設置，默認10s

優缺點

優點：按流量需求創建，不浪費系統資源（在硬體如此便宜的時代，這個優點略顯雞肋）

缺點：由於php-fpm是短連接的，所以每次請求都會先建立連接，建立連接的過程必然會觸發上圖的執行步驟，所以，在大流量的系統上master進程會變得繁忙，佔用系統cpu資源，不適合大流量環境的部署

dynamic

在php-fpm啟動時，會初始啟動一些worker，在運行過程中動態調整worker數量，worker的數量受限於pm.max_children配置，同時受限全局配置process.max

當前pool的名字為test

原理

dynamic原理圖

1. 1秒定時器作用

檢查空閑worker數量，按照一定策略動態調整worker數量，增加或減少。增加時，worker最大數量<=max_children· <=全局process.max；減少時，只有idle >pm.max_spare_servers時才會關閉一個空閑worker。

idle > pm.max_spare_servers，關閉啟動時間最長的一個worker，結束本次處理

idle >= pm.max_children，列印WARNING日誌，結束本次處理

idle < pm.max_children，計算一個num值，然後啟動num個worker，結束本次處理

配置項要求

1. pm.min_spare_servers/pm.max_spare_servers有效范圍(0,pm.max_children]

2. pm.max_children> 0

3. pm.min_spare_servers<=pm.max_spare_servers

4. pm.start_servers有效范圍[pm.min_spare_servers,pm.max_spare_servers]如果沒有配置，默認pm.min_spare_servers + (pm.max_spare_servers - pm.min_spare_servers) / 2

優缺點

優點：動態擴容，不浪費系統資源，master進程設置的1秒定時器對系統的影響忽略不計；

缺點：如果所有worker都在工作，新的請求到來只能等待master在1秒定時器內再新建一個worker，這時可能最長等待1s；

static

php-fpm啟動採用固定大小數量的worker， 在運行期間也不會擴容，雖然也有1秒的定時器，僅限於統計一些狀態信息，例如空閑worker個數，活動worker個數，網路連接隊列長度等信息。

當前pool的名字為test

原理

配置項要求

1、pm.max_children> 0 必須配置，且只有這一個參數生效

優缺點

如果配置成static，只需要考慮max_children的數量，數量取決於cpu的個數和應用的響應時間，我司配置的是50。

我司不考慮動態的增加減少那麼十幾個或者幾十個worker，我們的內存沒有緊張到這個程度，所以，我們一步到位，把worker數配置到支持最大流量，（哈哈，50也是隨便定的，足矣足矣呢）

最後我們再介紹下worker的工作流程

fastcgi與php-fpm的關系一句話解讀：fastcgi只是通信應用協議，php-fpm就是實現了fastcig協議，並嵌入了一個 PHP 解釋器。