<del id="nnjnj"></del><track id="nnjnj"></track>

<p id="nnjnj"></p>

<address id="nnjnj"></address>

    <pre id="nnjnj"><pre id="nnjnj"></pre></pre>

      <noframes id="nnjnj"><ruby id="nnjnj"><ruby id="nnjnj"></ruby></ruby>

      • 自動秒收錄
      • 軟件:1973
      • 資訊:57811|
      • 收錄網站:279872|

      IT精英團

      記錄在線超時的分析和故障排除過程

      記錄在線超時的分析和故障排除過程

      瀏覽次數:
      評論次數:
      編輯: 陽煦
      信息來源: ITPUB
      更新日期: 2022-09-20 00:45:10
      摘要

      .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align

      • 正文開始
      • 相關閱讀
      • 推薦作品
      Card-title.two-line{line-height:20px;display:-webkit-box;text-overflow:ellipsis;overflow:hidden;-webkit-box-orient:vertical;-webkit-line-clamp:2;}.css-1wr1m8 .LinkCard.new .LinkCard-title.loading{margin-bottom:8px;width:80%;}.css-1wr1m8 .LinkCard.new .LinkCard-title.loading.withTitle{margin-bottom:6px;}.css-1wr1m8 .LinkCard.new .LinkCard-title.loadingTitle{margin-bottom:5px;}.css-1wr1m8 .LinkCard.new .LinkCard-excerpt{display:-webkit-box;text-overflow:ellipsis;font-size:13px;line-height:18px;color:#999999;margin-bottom:4px;overflow:hidden;-webkit-box-orient:vertical;-webkit-line-clamp:1;}.css-1wr1m8 .LinkCard.new .LinkCard-excerpt .LinkCard-author{color:#444444;}.css-1wr1m8 .LinkCard.new .LinkCard-desc{display:-webkit-box;font-size:13px;height:18px;line-height:18px;color:#999999;word-break:break-all;text-overflow:ellipsis;overflow:hidden;-webkit-box-orient:vertical;-webkit-line-clamp:1;}.css-1wr1m8 .LinkCard.new .LinkCard-desc .LinkCard-tag,.css-1wr1m8 .LinkCard.new .LinkCard-desc .tag{display:inline-block;font-size:11px;margin-left:8px;padding:0 4px;border-radius:3px;background:rgba(211,211,211,0.3);}.css-1wr1m8 .LinkCard.new .LinkCard-desc.loading{width:40%;}.css-1wr1m8 .LinkCard.new .LinkCard-desc svg{margin-right:2px;}.css-1wr1m8 .LinkCard.new .LinkCard-image{-webkit-flex:0 0 auto;-ms-flex:0 0 auto;flex:0 0 auto;background-color:#EBEBEB;background-size:cover;background-position:center;position:relative;display:block;width:60px;height:60px;margin-left:20px;object-fit:cover;border-radius:inherit;overflow:hidden;}.css-1wr1m8 .LinkCard.new .LinkCard-image.LinkCard-image--default{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-webkit-justify-content:center;-ms-flex-pack:center;justify-content:center;background-color:#EBEBEB;color:#D3D3D3;}.css-1wr1m8 .LinkCard.new .LinkCard-image.LinkCard-image--default svg{color:#999999;}.css-1wr1m8 .LinkCard.new .LinkCard-image img{width:100%;height:100%;object-fit:cover;}.css-1wr1m8 .LinkCard.new .LinkCard-image .LinkCard-image--video{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-webkit-justify-content:center;-ms-flex-pack:center;justify-content:center;position:absolute;top:50%;left:50%;-webkit-transform:translateX(-50%) translateY(-50%);-ms-transform:translateX(-50%) translateY(-50%);transform:translateX(-50%) translateY(-50%);width:24px;height:24px;border-radius:12px;background:rgba(255,255,255,0.9);pointer-events:none;}.css-1wr1m8 .LinkCard.new .LinkCard-image .LinkCard-image--video svg{color:#444444;}.css-1wr1m8 .LinkCard.new .LinkCard-richText .text{color:#444444;}.css-1wr1m8 .LinkCard.new .LinkCard-richText .bold{font-weight:600;}.css-1wr1m8 .LinkCard.new .LinkCard-richText .tag{margin-left:4px;}.css-1wr1m8 .LinkCard.old{position:relative;display:block;margin:1em auto;width:390px;box-sizing:border-box;border-radius:12px;max-width:100%;overflow:hidden;}.css-1wr1m8 .LinkCard.old,.css-1wr1m8 .LinkCard.old:hover{-webkit-text-decoration:none;text-decoration:none;border:none !important;color:inherit !important;}.css-1wr1m8 .LinkCard-ecommerceLoadingCard{position:relative;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:justify;-webkit-justify-content:space-between;-ms-flex-pack:justify;justify-content:space-between;padding:12px;border-radius:inherit;height:80px;box-sizing:border-box;background:rgba(246,246,246,0.88);color:#D3D3D3;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardAvatarWrapper{width:60px;height:60px;background:#EBEBEB;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-box-pack:center;-webkit-justify-content:center;-ms-flex-pack:center;justify-content:center;border-radius:6px;margin-right:10px;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardNetwork{width:20px;height:20px;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardLoadingbar{height:60px;-webkit-flex:1;-ms-flex:1;flex:1;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-flex-direction:column;-ms-flex-direction:column;flex-direction:column;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardLoadingbar span{height:16px;display:inline-block;background:#EBEBEB;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardLoadingbar span:nth-of-type(1){width:60px;margin-bottom:4px;}.css-1wr1m8 .LinkCard-ecommerceLoadingCardLoadingbar span:nth-of-type(2){width:127px;}


      在上一篇文章問題解決了,我卻不知道原因中提到,最近從性能、監控方面對引擎進行優化,這不,監控剛上了,就發現了一個很嚴重的問題--超時。

      今天,借助此文,分享下該問題的發現、排查以及解決過程!

      業務背景

      在廣告業務中,分為效果廣告、KA廣告以及三方廣告等。效果廣告和KA廣告一般都僅限于內網,也就是說在內網中通過RPC進行訪問,而三方廣告,則需要訪問外網,因為外網環境以及每家三方廣告主的處理能力不同,導致性能不同。本次的超時就是針對的某個三方廣告主。

      本次針對三方的業務監控中,包括對三方廣告主的請求數、返回數、qps、rt等指標。

      收到報警

      增加了監控的業務上線后,根據引擎監控系統來查看三方的基礎數據監控,如下:

      通過上述圖表,看了下平均rt等業務指標,一切正常。開始著手配置超時等監控報警指標。鑒于業務的重要性,配置了郵件告警和短信告警兩種,配置完成后,一鍵生效。結果,過了沒幾分鐘,就收到了告警。

      看到超時這么多,第一時間先ping下,看看網絡間耗時咋樣,結果如下:

      64 bytes from 114.67.237.131: icmp_seq=1 ttl=49 time=7.13 ms64 bytes from 114.67.237.131: icmp_seq=2 ttl=49 time=6.37 ms64 bytes from 114.67.237.131: icmp_seq=3 ttl=49 time=6.10 ms64 bytes from 114.67.237.131: icmp_seq=4 ttl=49 time=6.07 ms64 bytes from 114.67.237.131: icmp_seq=5 ttl=49 time=6.04 ms64 bytes from 114.67.237.131: icmp_seq=6 ttl=49 time=6.07 ms64 bytes from 114.67.237.131: icmp_seq=7 ttl=49 time=6.03 ms64 bytes from 114.67.237.131: icmp_seq=8 ttl=49 time=6.09 ms64 bytes from 114.67.237.131: icmp_seq=9 ttl=49 time=6.11 ms64 bytes from 114.67.237.131: icmp_seq=10 ttl=49 time=6.03 ms64 bytes from 114.67.237.131: icmp_seq=11 ttl=49 time=6.07 ms

      網絡很穩定,看來跟網絡沒關系,只能通知對方。

      雙方溝通

      跟對方反饋其rt超時很嚴重后,對方第一反應是內部有些廣告主太耗時,于是其關閉了超時嚴重的廣告主,然后讓我這邊繼續觀察。

      待對方關閉耗時長的廣告主后,重新打開監控報警(之前因為報警太頻繁,暫時關閉了報警),然后沒有幾分鐘,報警又又又來了。

      趕緊在群里跟對方反饋,對方也是一臉懵逼,雙方開始一起排查問題,畢竟沒人跟錢過不去

      為了便于盡快發現,在測試環境嘗試將超時時間設置為2s,然后模擬發送請求,果不其然,超時。。。

      看了對方的反饋,對方在服務內部也設置了超時,如果200ms內沒有得到有效廣告,則返回,也就是說對方也做了200ms的超時控制,很奇怪。。。

      在測試環境將超時時間設置為50s,仍然有超時現象。。。

      對接群溝通多少有點影響到別人,于是勾搭了對方的技術,開始私聊(此處開始甩鍋模式)

      不過,甩鍋歸甩鍋,問題還得解決。開始嘗試使用curl來分析各個階段的耗時:

      curl  -o /dev/null -s -w %{time_namelookup}::%{time_connect}::%{time_starttransfer}::%{time_total}::%{speed_download}"\n" --data-binary @req.dat https://www.baidu.com

      輸出結果如下:

      從上述結構可以看出,在time_starttransfe階段也就是說對方業務處理結果偶現2s耗時,問題復現。

      業務代碼

      雖然該模塊的核心代碼在線上穩定運行了5年多,但是為了保險起見,還是得再分析下,免得再遺漏了某個分支條件,導致這種現象發生。

      一般情況下,log是最直接也是最有效的方式,于是在每個步驟每個運行函數中加了日志,然后編譯、運行,使用之前的測試case重新發送請求。分析日志,一切都在預期內,看來業務代碼沒問題,只能通過其它方式進行排查了。



      前段時間整理了工作這么多年讀過的書,推薦下(可以免費獲取)




      線上抓包

      既然業務代碼沒問題,那就只能通過tcpdump抓包來分析了,然后經過wireshark解析后,結果如下:

      從上面抓包結果來看,在序號為6的位置,對方返回了http 204,然后又重新手動發了一次curl請求,在序號10的時候,對方又返回了http 204(從發送請求到收到對方響應耗時38ms),但是奇怪的時候,在后面50s后,client端(發送方)開發發送FIN請求關閉連接,從代碼邏輯來分析,是因為超時導致的關閉連接。

      從抓包現象只能得出上述結論,沒什么有用的結論,看來只能通過其它方式繼續分析。

      同類對比

      既然抓包都不能得到有用的結論,那就只能通過與其它家正常返回的做對比,看看能不能得到有用結論。

      通過修改業務代碼,輸出http相關信息,如下:

      curl_easy_setopt(handle_, CURLOPT_VERBOSE, 1L);

      編譯,運行,發起curl請求。

      正常三方返回如下:

      而超時的該家返回如下:

      通過對比上述兩家的區別,發現超時的該家較正常的三方返回,多了Content-Length、Content-Type等字段,那么有沒有可能跟這幾個字段的返回有關呢?

      問題解決

      讓對方在其測試環境,在沒有廣告返回的時候,將這幾個字段去掉。然后我這邊重新發起curl請求。。。

      然后發起curl請求,一切正常,在超時范圍內返回。wrk壓測,平均rt符合預期,看來問題就在這。

      跟對方溝通后,對方修改代碼,然后著手上線,上線后結果如下:

      效果很明顯,看來就是這個原因導致,超時問題解決了,收入也就蹭蹭地往上漲了 。

      分析原因

      既然問題已經解決了,多少得知道原因吧,于是在搜索引擎上輸入http 204 Content-Length hang,找到了有用信息,如下:

      看來wget之前也存在此類問題,于是繼續搜索標準,輸出如下:

      The presence of a message body in a response depends on both the request method to which it is responding and the response status code (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 of [RFC7231]) never include a message body because the associated response header fields (e.g., Transfer-Encoding, Content-Length, etc.), if present, indicate only what their values would have been if the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx (Successful) responses to a CONNECT request method (Section 4.3.6 of [RFC7231]) switch to tunnel mode instead of having a message body. All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include a message body. All other responses do include a message body, although the body might be of zero length.

      深入源碼

      從上節標準可以看出,在http 204、304的時候,不允許返回Content-Length,那么如果返回了,libcurl又是如何處理的呢?

      于是在curl的issue上進行了關鍵字搜索,得到了如下結果:

      看來已經有人提過這個問題了,于是看了下當前線上libcurl的源碼:

      switch(k->httpcode) {        case 204:           /* (quote from RFC2616, section 10.2.5): The server has            * fulfilled the request but does not need to return an            * entity-body ... The 204 response MUST NOT include a            * message-body, and thus is always terminated by the first            * empty line after the header fields. */           /* FALLTHROUGH */    case 304:           /* (quote from RFC2616, section 10.3.5): The 304 response            * MUST NOT contain a message-body, and thus is always            * terminated by the first empty line after the header            * fields.  */           if(data->set.timecondition)             data->info.timecond = TRUE;           k->size=0;           k->maxdownload=0;           k->ignorecl = TRUE; /* ignore Content-Length headers */           break;

      線上使用的版本果然沒有處理此種情況,再跟線上做對比,改動如下:

      好了,問題已經解決,原因也已經找到,畢竟不是大bug,為了穩妥起見,還是不升級了,以穩定為主,誰知道升級后又會出現什么意想不到的問題呢

      結語

      該問題從發現到解決,大概用了2天的時間。其實,從文章的目錄結構就能發現,整個問題發現以及解決過程跟文章目錄結構一致:收到報警->雙方溝通->業務代碼->線上抓包->同類對比->問題解決->原因分析->深入源碼。

      好了,今天的文章就到這,我們下期見!

      標簽:對方 問題 廣告
      Linux環境程序如何運行?
      ? 上一篇 2022-09-20
      內存泄漏——原因、避免和位置
      下一篇 ? 2022-09-20
      • 如何在Ubuntu中保留文件系統并備份當前開發板鏡像
        0閱讀 0條評論 個贊
        在Ubuntu保留文件系統或者說備份當前開發板鏡像的需求在不斷增加。比如Ubuntu文件系統需要安裝庫文件的話直接使用apt-get工具就可以下載,但由于需要下載的核心板較多,比較費時間,這時需要將安……
      • 國產核心板全志T507助力消防系統升級
        0閱讀 0條評論 個贊
        9月16日下午,位于湖南長沙市區內的中國電信大樓發生火災,建筑高度218米,現場濃煙滾滾,數十層樓體燃燒劇烈。消防救援人員趕到現場后很快將火勢控制住,目前大樓火勢已被撲滅,所幸未發現人員傷亡。湖南電信……
      • 教大家如何處理Spring Boot易流中的用戶和群體!
        0閱讀 0條評論 個贊
        1.準備工作2.用戶操作2.1添加用戶2.2修改用戶2.3刪除用戶2.4查詢用戶3.組操作3.1添加組3.2修改組3.3刪除組3.4查詢組4.查看表詳情雖然說我們在實際開發中,……
      • 從PG15開始WAL壓縮優化
        0閱讀 0條評論 個贊
        PG15傳聞中的超級令人激動的功能大多數跳票了,年初我也寫過一個關于PG15新功能跳票的文章。PG15BETA已經發出幾個月了,似乎PG15里令人激動人心的功能不多,不過從長長的新功能列表里,……
      • 深入了解美團葉子發射器開源方案
        0閱讀 0條評論 個贊
        大家好,我是樹哥。之前我們有聊過「如何設計一個分布式ID發號器」,其中有講過4種解決方案,分別是:UUID類雪花算法數據庫自增主鍵Redis原子自增美團以第2、3種解決方案為基礎,開發出……
      發表評論 共有條評論
      用戶名: 密碼:
      驗證碼: 匿名發表
      • Java可以重新鎖定的那些東西(1)
        0閱讀 0條評論 個贊
        本文主要包含的內容:可重入鎖(ReedtrantLock)、公平鎖、非公平鎖、可重入性、同步隊列、CAS等概念的理解顯式鎖……
      • 金牛座入門 MVC微服務框架開發教程
        0閱讀 0條評論 個贊
        前言:對于Taurus.MVC的微服務的注冊中心而言:什么樣的應用中心,有權利注冊服務?什么樣的網關中心,有權利調取服務列表?在默認沒有進行相關配置時,只要引用Taurus.MVC的框架,都擁有該權限……
      • 如何使用spark或hive sql將Excel文件加載到hive表中
        0閱讀 0條評論 個贊
        .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align……
      • 教你如何構建JAVA分布式爬蟲
        0閱讀 0條評論 個贊
        在工作中,我們經常需要去獲取一些數據,但是這些數據可能需要從第三方平臺才可以獲取到。這個時候,爬蟲系統就可以幫助我們來完成這些事情。提到爬蟲系統,很多人都會想到使用python。但實際上,語言只……
      • 數據庫發展史1-傳統數據庫
        0閱讀 0條評論 個贊
        1946年,美國賓夕法尼亞大學誕生了人類第一臺電子計算機--ENIAC(ElectronicNumericalIntegratorAndComputer,即電子數字積分計算機),這個占地170……
      • 舉例說明庫伯內特公司的豆莢核心資源
        3閱讀 0條評論 個贊
        目錄一、Pod定義二、Pod入門yaml描述文件三、共享NetworkNamespace四、共享PID五、容器生命周期六、初始化容器6.1、簡介6.2、與普通容器的區別6.3、實驗七、Pod探針7.1……
      • Sql Server連接池及其用法
        0閱讀 0條評論 個贊
        其實我們一直在使用SqlServer的連接池。在連接字符串中,Pooling為是否啟用連接池,默認值為true,表示啟用。與連接池相關的兩個重要參數是MinPoolSize和MaxPoo……
      • SQL Server備份和還原攻略
        0閱讀 0條評論 個贊
        一、知識點完全備份:備份全部選中的文件夾,并不依賴文件的存檔屬性來確定備份那些文件。(在備份過程中,任何現有的標記都被清除,每個文件都被標記為已備份,換言之,清除存檔屬性)。完全備份也叫完整備份。差異……
      • 在一本書中閱讀所有的Hive Sql(20 000字的最完整解釋)
        0閱讀 0條評論 個贊
        HiveSql大全本文基本涵蓋了Hive日常使用的所有SQL,因為SQL太多,所以將SQL進行了如下分類:一、DDL語句(數據定義語句):對數據庫的操作:包含創建、修改數據庫對數據表的操作:分……
      • 能夠在JAVA中自定義和擴展Swagger 自動生成參數值的含義 提高開發效率
        0閱讀 0條評論 個贊
        大家好,又見面了。在JAVA做前后端分離的項目開發的時候,服務端需要提供接口文檔供周邊人員做接口的對接指導。越來越多的項目都在嘗試使用一些基于代碼自動生成接口文檔的工具來替代由開發人員手動編寫接口文檔……
      • 開發者如何在應用后臺直接控制用戶的運動狀態?
        18閱讀 0條評論 個贊
        酷暑終于過去,很多人伴著涼爽的秋風開啟了新一輪的健身計劃。當用戶進行戶外運動或使用跑步機、橢圓機等器械時,他們會希望在運動健康類App里點擊即可開啟運動并記錄運動數據。而對于開發者自己開發的應用來說,……
      • 卡夫卡數據丟失問題優化總結及重復消費原因分析(二)
        0閱讀 0條評論 個贊
        .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align……
      • 多線程技術的歷史發展和簡單使用
        0閱讀 0條評論 個贊
        進程與線程進程是應用的執行實例,可狹義理解為一個應用程序就是一個進程。啟用一個應用程序時就是啟動了一個進程。該應用運行所需的所有地址空間,代碼,數據及系統資源都屬于此進程。進程所使用的所有資源會在進程……
      • 網純原生實現時間單位定時任務執行,未依賴第三方組件
        0閱讀 0條評論 個贊
        常用的定時任務組件有Quartz.Net和Hangfire兩種,這兩種是使用人數比較多的定時任務組件,個人以前也是使用的Hangfire,慢慢的發現自己想要的其實只是一個能夠根據Cron……
      • 《2022 分布式數據庫發展趨勢研究報告》的解釋
        9閱讀 0條評論 個贊
        分布式數據庫近年來廣受關注,目前,對分布式數據庫的討論,已經從什么是分布式數據庫,為什么要用分布式數據庫,轉變為怎樣規劃應用分布式數據庫。但分布式數據庫有3條不同的技術路線,這無疑增加了選型難度,到底……
      • SQL Server合并(刪除)分區的歧義消除
        4閱讀 0條評論 個贊
        一、準備在SQLServer2005版本之后就有了表分區的概念與應用,在分區操作里面有一個叫做合并分區的功能,也被稱為刪除分區。分區所處的文件組和文件是不會被刪除的,只會對數據進行轉移合并。合并分……
      • 1 Docker安裝Nexus3
        0閱讀 0條評論 個贊
        1.1創建目錄在硬盤上創建Nexus3的主目錄:mkdir-p/Users/yygnb/dockerMe/nexus3為該目錄添加權限:chmod777-R/Users/yygnb/d……
      • 一個沒有寫代碼的案例 讓我們看看Flowable為我們提供了哪些功能
        3閱讀 0條評論 個贊
        其實松哥之前已經寫過文章和大家介紹了flowable-ui的玩法了,這是官方提供的一個工具,這個工具不僅可以用來繪制流程圖,還可以用來部署一個流程應用,通過這個流程應用我們可以體驗一把flowa……
      • 大促銷活動如何抵御高流量DDoS攻擊?
        0閱讀 0條評論 個贊
        大促活動如何抵御大流量DDoS攻擊?每一次活動大促帶來的迅猛流量,對技術人而言都是一次嚴峻考驗。如果在活動期間遭受黑產惡意DDoS攻擊,無疑是雪上加霜。電商的特性是業務常態下通常不會遭受大流量DD……
      • springboot集成docsify實現可移植文檔
        0閱讀 0條評論 個贊
        需求分析文檔可以和項目一起進行版本管理文檔可以在線訪問文檔可以與springboot項目集成,不需要分開部署MarkDown支持文檔跟隨,打包jar也可以訪問技術選型對于網上已有的方案,大致分為如下幾……
      最近發布資訊
      更多
      警花高潮嗷嗷叫
      <del id="nnjnj"></del><track id="nnjnj"></track>

      <p id="nnjnj"></p>

      <address id="nnjnj"></address>

        <pre id="nnjnj"><pre id="nnjnj"></pre></pre>

          <noframes id="nnjnj"><ruby id="nnjnj"><ruby id="nnjnj"></ruby></ruby>