成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

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

zhangfaliang / 1956人閱讀

摘要：周三晚加上了對阿波羅超時(shí)的監(jiān)控，周四觀察上線期間阿波羅超時(shí)指標(biāo)的變化，時(shí)間也吻合。月日下午又報(bào)了一次警與此同時(shí)的阿波羅超時(shí)監(jiān)控這里同時(shí)列出機(jī)器指標(biāo)的目的是為了說明，盡管沒有報(bào)警，但機(jī)器的指標(biāo)變化和是統(tǒng)一的。

順風(fēng)車運(yùn)營研發(fā)團(tuán)隊(duì) 熊浩含

問題現(xiàn)象

線上報(bào)警群里時(shí)而有php-fpm-idle的零星報(bào)警，持續(xù)時(shí)間很短（幾秒甚至一秒），見下圖

問題分析

發(fā)生故障時(shí)，我們可以通過觀察相關(guān)指標(biāo)在故障時(shí)間的前后異常變化，找出故障原因。常用的指標(biāo)如下：

cpu_idle

php-fpm-idle

io

nginx.status.flow

opcachereset

指標(biāo)截圖如下：

io.read

nginx.status

opcachereset

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

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

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

nginx_499:部分請求長時(shí)間占用了php-fpm進(jìn)程（死循環(huán)或者超時(shí)），導(dǎo)致了新請求的排隊(duì)，php-fpm-idle下降。

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

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

查看報(bào)警機(jī)器的nginx的access.log

取前幾處請求的traceid，在業(yè)務(wù)日志中查看，發(fā)現(xiàn)大量的apollo（一個(gè)內(nèi)部服務(wù)）請求超時(shí)，proc_time時(shí)間過長

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

查到這里，我的猜想是：因?yàn)樯暇€操作觸發(fā)了阿波羅(一個(gè)內(nèi)部服務(wù))的某種異常，導(dǎo)致阿波羅鏈接在這一瞬間全部超時(shí)，引起nginx的大量499，也引起了php-fpm-idle的掉底。

驗(yàn)證這個(gè)猜想需要解決以下兩個(gè)問題：

(一) 上線和阿波羅超時(shí)是否有必然的聯(lián)系？需要多找?guī)讉€(gè)例子驗(yàn)證

(二）既然只要上線就會觸發(fā)這個(gè)問題，為啥不是每臺機(jī)器都報(bào)警，而只有零星的報(bào)警？

先看問題（一），結(jié)果是振奮人心的，找了幾臺機(jī)器驗(yàn)證，上線時(shí)間和業(yè)務(wù)日志中大量出現(xiàn)”call apollo too long“的時(shí)間重合。周三晚加上了對阿波羅超時(shí)的監(jiān)控，周四觀察上線期間阿波羅超時(shí)指標(biāo)的變化，時(shí)間也吻合。

8月9日下午15：22又報(bào)了一次警

與此同時(shí)的阿波羅超時(shí)監(jiān)控:

*.16.gz01

.17.gz01

.17.gz01

這里同時(shí)列出17.gz01機(jī)器指標(biāo)的目的是為了說明，盡管17.gz01沒有報(bào)警，但17機(jī)器的指標(biāo)變化和16是統(tǒng)一的。

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

結(jié)論

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

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/29252.html

相關(guān)文章

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

    摘要：順風(fēng)車運(yùn)營研發(fā)團(tuán)隊(duì)黃桃問題現(xiàn)象某機(jī)器這段時(shí)間出現(xiàn)掉地的報(bào)警如圖原因分析查看當(dāng)時(shí)的監(jiān)控，等今天出現(xiàn)兩次突降，一次是點(diǎn)左右，一次是左右，查看整周也經(jīng)常出現(xiàn)突降，如圖在分時(shí)突然升高也在時(shí)出現(xiàn)大量寫當(dāng)時(shí)短暫出現(xiàn)降低，之后出現(xiàn)徒 順風(fēng)車運(yùn)營研發(fā)團(tuán)隊(duì) 黃桃 問題現(xiàn)象某機(jī)器這段時(shí)間出現(xiàn)cpu-idle掉地的報(bào)警 如圖： showImg(https://segmentfault.com/img/bVb...

    Code4App 評論0 收藏0

  • php-fpm進(jìn)程數(shù)管理

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

    hlcfan 評論0 收藏0

  • PHP-FPM 調(diào)優(yōu)：使用 ‘pm static’ 來最大化你的服務(wù)器負(fù)載能力

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

    CNZPH 評論0 收藏0

  • PHP超時(shí)處理全面總結(jié)

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

    I_Am 評論0 收藏0

  • PHP-FPM設(shè)置max_chindren、max_requests

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

    hedge_hog 評論0 收藏0

發(fā)表評論

0條評論

閱讀需要支付1元查看
<