php-fpm 高併發 參數調整

         工做中常常會遇到會給客戶配置服務器，其中有的客戶還會有併發量要求，其中也會必需要用負載均衡承載壓力的。增長服務器數量確定能有效的提高服務器承載能力，但只有根據目前已有配置設置好單臺服務器才能更好的發揮出服務器的性能。調整好一臺服務器後剩下的就更簡單了  拿着快照複製n多臺。

        今天就說一下php服務器的配置，以前說過opcache 今天說一下lnmp下基本配置（我的經驗總結，若有不妥之處望大神提示一下）。

       服務器中找到php-fpm.conf配置（有的會在引入的www.conf中）

      

[global]
pid = /usr/local/php/var/run/php-fpm.pid
error_log = /usr/local/php/var/log/php-fpm.log
log_level = notice

[www]
listen = /tmp/php-cgi.sock
listen.backlog = -1
listen.allowed_clients = 127.0.0.1
listen.owner = www
listen.group = www
listen.mode = 0666
user = www
group = www
pm = static
pm.max_children = 200
pm.start_servers = 40
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests=1000
request_terminate_timeout = 100
request_slowlog_timeout = 0
slowlog = var/log/slow.log

一. pm= static

首先說一下pm這個值   pm = dynamic 這個是php的進程數是動態的  會根據訪問量來肯定來回增長

而在高負載的php環境下我推薦設置  pm= static php-fpm進程數固定

二.  pm.max_children=???

當用靜態模式下 進程數肯定根據 pm.max_children來進進行肯定    那麼問題來了個人服務器應該設定多少php-fpm呢 ?

 

    從理論的角度上說php-fpm進程數越多越好，至關於一個酒店有不少個充足的服務員來爲你服務確定會比較爽啊 ，你也不須要等待。

     可是。。。。現實上老是殘酷的   php-fpm的進程數會受到你的內存大小的限制。通常狀況下咱們    進程數 =用機器內存（M）除以2  再除以20(M);

     固然這個也不是絕對的   你須要知道:

1.  你能夠分配給php多大內存 ：你的服務器上是否是單純的php服務器  有沒有比較耗費內存的其餘程序（mysql）。
2.  你的每一個php-fpm內存佔多大 ：內存佔用多大要根據你的php代碼質量和處理的相關業務。固然你能夠用命令去統計你的php-fpm平均佔用內存大小。

        有人會問我若是設置不恰當會有什麼情況出現呢？

 　  　當數值偏小時請求到nginx會沒法分配到php-fpm進程 致使502錯誤

　　   

   　　當數值偏大若是沒有大訪問量還好  若是訪問量較大的話 內存都會被php佔光了。致使系統響應緩慢   cpu-system  升高 系統不斷的去調整內存分配

          嚴重時會致使較高的 cup-wait 較高   內存不夠用了  直接寫磁盤  磁盤io直線增長 。cpu使用率也開始爆滿。（如圖所示）

　　　　

    三.request_terminate_timeout

 　　計算方式以下：若是你的服務器性能足夠好，且寬帶資源足夠充足，PHP腳本沒有循環或BUG的話你能夠直接將」request_terminate_timeout」設 置成0s。0s的含義是讓PHP-CGI一直執行下去而沒有時間限制。

　　 而若是你作不到這一點，也就是說你的PHP-CGI可能出現某個BUG，或者你的寬帶不夠充足或者其餘的緣由致使你的PHP-CGI可以假死那麼就建議你給」request_terminate_timeout」賦一個值，這個值能夠根 據你服務器的性能進行設定。

通常來講性能越好你能夠設置越高，20分鐘-30分鐘均可以。因爲個人服務器PHP腳本須要長時間運行，有的可能會超過10分鐘所以我設置了900秒，這樣不會致使PHP-CGI死掉而出現502 Bad gateway這個錯誤。

 

四.pm.max_requests

        這個參數的含義是php-fpm工做進程處理完多少請求後自動重啓，主要目的就是爲了控制請求處理過程當中的內存溢出，使得內存佔用在一個可接受的範圍內。比較適用於服務器搭載項目比較雜亂，有點請求會比較佔用內存

        致使php-fpm佔用比較大。在通過必定次數請求後會結束掉進程，釋放本身的內存。若是這個值過小就會致使全部的工做進程幾乎同時達到這個值而且進入須要重啓的狀態，當全部的工做進程都在同一時刻重啓就會發生在

　　數秒內甚至更長的時間PHP將中止響應直到全部的進程均重啓完爲止。這是不能接受的，因此我通常會把這個值設置爲PHP啓動後第一批工做進程達到此值須要重啓時，第一個進程重啓與最後一個進程重啓之間的時間相差

　　1分鐘以上，通常在壓力比較大的晚上這個差值將會擴大到5分鐘左右，此時對進程重啓對服務器的負面影響就能夠忽略了。

 

　　下面補充幾個命令統計相關php-fpm 相關數據  

  

 

一、查看php-fpm的進程個數

ps -ef |grep "php-fpm"|grep "pool"|wc -l

二、查看每一個php-fpm佔用的內存大小

ps -ylC php-fpm --sort:rss

3.查看PHP-FPM在你的機器上的平均內存佔用

ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'

4.查看單個php-fpm進程消耗內存的明細

pmap $(pgrep php-fpm) | less

 

 　　補充一下與技術無關的：

　　不少技術人員認爲我把一臺服務器性能壓榨到極限，別人四臺服務器承載的壓力我一臺服務器就承載住了，認爲本身很厲害

       其實這種思惟是不對的。客戶要的是作活動時服務的穩定，用戶要的是流暢的體驗。 該增長機器的時候增長機器，最重要的

　　是活動能正常穩定的進行。

 

 今天就這樣吧  之後再有進行補充  後面再完善一下nginx 和內核方面的