国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

【PHP問題定位】php-fpm的idle掉底分析

zhangfaliang / 1867人閱讀

摘要：周三晚加上了對阿波羅超時的監控，周四觀察上線期間阿波羅超時指標的變化，時間也吻合。月日下午又報了一次警與此同時的阿波羅超時監控這里同時列出機器指標的目的是為了說明，盡管沒有報警，但機器的指標變化和是統一的。

順風車運營研發團隊 熊浩含

問題現象

線上報警群里時而有php-fpm-idle的零星報警，持續時間很短（幾秒甚至一秒），見下圖

問題分析

發生故障時，我們可以通過觀察相關指標在故障時間的前后異常變化，找出故障原因。常用的指標如下：

cpu_idle

php-fpm-idle

io

nginx.status.flow

opcachereset

指標截圖如下：

io.read

nginx.status

opcachereset

在故障發生時（php-fpm-idle掉底），除了nginx的499明顯增多，io增大外，其余性能指標并無明顯變化。值得注意的是，故障時間與opcachereset時間高度重合，opcachereset是上線時的操作，會清除服務器上的phpopcache。故有兩種可能：

故障單純是清除opcache導致的，php需要重新解析php文件，耗時增加，php-fpm-idle下降;

上線時進行的某些操作，影響了某些url請求的效率，導致超時(nginx出現大量499)，也引起了php-fpm-idle下降;

nginx_499:部分請求長時間占用了php-fpm進程（死循環或者超時），導致了新請求的排隊，php-fpm-idle下降。

cpu-idle:cpu-idle和php-fpm-idle其實并沒有直接關系，但會相互影響。當請求增多，php-fpm啟動了更多的進程處理請求，自然也會增加cpu的消耗，cpu_idle降低;而當cpu_idle降低時（cpu更忙），php處理請求比平時要花費更多的時間，導致請求堆積，php-fpm-idle下降。

io:磁盤io會直接影響fpm進程讀寫文件，io過高，導致讀寫文件慢；同時過高的io也會影響cpu-idle，進而間接影響php-fpm。
日志采集系統對采集的性能指標數據有聚合操作。例如指標A10s采集一次，當天可以按10s的粒度查看數據。但對于歷史數據，例如7天前，數據粒度不再是10s,而變成了15分鐘，odin對數據做了聚合。這意味著一些”尖峰數據“隨著時間推移，其尖峰不再，曲線會變得平滑。
問題定位

查看報警機器的nginx的access.log

取前幾處請求的traceid，在業務日志中查看，發現大量的apollo（一個內部服務）請求超時，proc_time時間過長

在看nginx日志的時候發現，499的log中，request_time是以客戶端斷開連接的時間計算的。例如api的請求超時時間是0.08s，超時后請求方主動斷開，此時nginx即打印了499的log（比0.08s稍長）。但實際上php-fpm的處理仍在繼續，過了更長的時間后，在trace日志中打印了真正的執行時間（proc_time）。

查到這里，我的猜想是：因為上線操作觸發了阿波羅(一個內部服務)的某種異常，導致阿波羅鏈接在這一瞬間全部超時，引起nginx的大量499，也引起了php-fpm-idle的掉底。

驗證這個猜想需要解決以下兩個問題：

(一) 上線和阿波羅超時是否有必然的聯系？需要多找幾個例子驗證

(二）既然只要上線就會觸發這個問題，為啥不是每臺機器都報警，而只有零星的報警？

先看問題（一），結果是振奮人心的，找了幾臺機器驗證，上線時間和業務日志中大量出現”call apollo too long“的時間重合。周三晚加上了對阿波羅超時的監控，周四觀察上線期間阿波羅超時指標的變化，時間也吻合。

8月9日下午15：22又報了一次警

與此同時的阿波羅超時監控:

*.16.gz01

.17.gz01

.17.gz01

這里同時列出17.gz01機器指標的目的是為了說明，盡管17.gz01沒有報警，但17機器的指標變化和16是統一的。

再看問題（二）：我的猜想是，由于故障時間很短（看機器日志只有100ms左右）,而odin最短10s采集一次指標，大部分機器php-fpm-idle掉底的數據并沒有被采集到。

結論

上線過程中清除了php的opcache，導致下一時刻的請求到來時，代碼中的阿波羅會讀取本地配置文件，io增加，而php需要重新解析文件，io進一步增大，耗時增加，導致php-fpm-idle有一瞬間的掉底。

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/29252.html

相關文章

  • 【PHP問題定位】2018-07-02 fpm掉底分析

    摘要：順風車運營研發團隊黃桃問題現象某機器這段時間出現掉地的報警如圖原因分析查看當時的監控，等今天出現兩次突降，一次是點左右，一次是左右，查看整周也經常出現突降，如圖在分時突然升高也在時出現大量寫當時短暫出現降低，之后出現徒 順風車運營研發團隊 黃桃 問題現象某機器這段時間出現cpu-idle掉地的報警 如圖： showImg(https://segmentfault.com/img/bVb...

    Code4App 評論0 收藏0

  • php-fpm進程數管理

    摘要：是實現的進程管理器用于替換的大部分附加功能，適用于高負載網站。能夠創建的最大子進程數量，它在使用多個配置的進程池的時候，控制全局的子進程數量。同時根據進程池的數量來看一個進程管理器的子進程數量限制。 PHP-FPM 先來了解一些名詞概念： CGI是Common Gateway Interface（通用網管協議），用于讓交互程序和Web服務器通信的協議。它負責處理URL的請求，啟動一個進...

    hlcfan 評論0 收藏0

  • PHP-FPM 調優：使用 ‘pm static’ 來最大化你的服務器負載能力

    摘要：進程管理器和的相似之處現在，我們要說些偏離主題，但我覺得和調優有關的事情。但是，一旦你有可用的閑置內存，那么把設置成的最大值將減少許多進程管理器所帶來的開銷。 showImg(https://segmentfault.com/img/remote/1460000016435381);讓我們來迅速了解一下怎樣設置 PHP-FPM，以便達到高吞吐，低延遲以及穩定的使用 CPU 和內存的完美...

    CNZPH 評論0 收藏0

  • PHP超時處理全面總結

    摘要：的毫秒級超時也有問題。。中超時實現一初級最簡單的超時實現秒級超時思路很簡單鏈接一個后端，然后設置為非阻塞模式，如果沒有連接上就一直循環，判斷當前時間和超時時間之間的差異。實際處理這個調用的部件在完成后，通過狀態通知和回調來通知調用者。 概述 在PHP開發中工作里非常多使用到超時處理到超時的場合，我說幾個場景： 異步獲取數據如果某個后端數據源獲取不成功則跳過，不影響整個頁面展現 為了保...

    I_Am 評論0 收藏0

  • PHP-FPM設置max_chindren、max_requests

    摘要：首先，我們關注下的運行方式模式始終保持一個固定數量的子進程，這個數由定義，這種方式很不靈活，也通常不是默認的。指的是每個子進程在處理了多少個請求數量之后就重啟。 首先，我們關注下 PHP-FPM 的運行方式：pm = static模式： 始終保持一個固定數量的子進程，這個數由pm.max_children定義，這種方式很不靈活，也通常不是默認的。優點是不用動態的判斷負載情況，提升性能；...

    hedge_hog 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<