感謝同事[空濛]投遞此稿
mtop是移動接入網關平台，對客戶端暴露api，後端接api實際的應用服務，有hsf，也有http的服務端。
之前進行了機房從杭州搬遷到上海，在搬遷的過程中，其中乙個api的rt突然大漲，(之前平均的約210ms)
分析具體的原因了，當時正機房搬遷，首先考慮的就是是否此影響，是否發生了跨機房呼叫的導致，當時把整個杭州的後端服務全部乾掉，確認沒有跨機房呼叫，但rt還是沒有降低，仍舊很高。
還是要整體性的分析，當前的情況，不存在跨機房的呼叫，暫僅發現此api存在rt大漲的情況，其他的api都已經實現搬遷，且rt沒有存在這種異常的大漲情況。那後續就是重點分析這個api的請求從mtop到後端的每個鏈路是否存在問題。
此api是http的接入方式，mtop對http的接入服務，採用 vipserver(軟負載均衡)分配具體機器+httpasyncclient非同步callback呼叫模式。其他的模組與hsf服務呼叫是共用的，因此排查的範圍縮減，此時查問題神器btrace出場。同事去寫腳步監控分析對vipserver以及http呼叫鏈路上的耗時情況。
而我則在各種資料包表上分析檢視（事實證明，完善的監控報表資料是非常有效的）
mtop有個機器效能的監控報表資料（之前出現過單機問題，但整體資料上無大幅波動。雖然按機器分析報表資料量比較大浪費儲存，關鍵時刻顯作用）
排查首先發現，發現上海包間1的速度快於包間2的速度，（乙個2s，乙個低於1s），那就先找pe把流量全部導到rt稍微好一點的機房，但結果rt也**了。
再分析發現此api杭州的呼叫才約550ms（跨機房呼叫到上海的服務端,為什麼已經完全且流量到上海，可杭州機房還有流量呢？主要是客戶端上有dns快取防攔截技術），可上海的直接機房間呼叫需要1.4s以上。這非常不符合常規。
首先考慮是使用者體驗，550ms總比秒級的rt好，因此先把流量導到杭州，完成一半後，rt就降低到900多ms。此時網路那塊排查說交換機存在一定錯誤，正在處理。後續rt又出現波動。
btrace此時分析結果是rt一切正常，同時排查這個api後端應用服務確認沒有存在問題，直接在機器上curl 也是快速的。那就先考慮把此api流量全部且回杭州，切換完成後，rt降低到了450ms。這樣對使用者體驗會好很多，但問題還要繼續排查。
現在情況：
nginx（上海）===》mtop（上海）===》應用（上海）rt約1.4s
nginx（上海）===》mtop（杭州）===》應用（上海）rt約450ms
竟然繞道杭州比上海機房直接呼叫快，btrace分析方法的呼叫時間是正常的，mtop框架是基於servlet3非同步+hsfcallback/http callbcak模式的（後端業務如果發生異常，rt耗時大漲，不會對mtop效能產生特別大的影響），因此剩下就要分析http的結果為什麼慢了，此刻另一神器tcpdump登場
一抓包分析就發現好幾個問題：
1、連線握手時候協商的視窗只有1460，報文都是1個視窗在傳送，協商mss是1460，可實際都是834在傳送資料
2、api結果資料比較大，發生的報文非常多，因為問題1，每次都只能乙個報文傳送應答後才接著發生，如果資料有40k，那差不多要傳輸50次，要50個rtt。
擷取部分資料
3、上海機房的請求中經常看到超時重傳，一超時重傳最小+200ms（rto雖然會由rtt計算確定，但當前核心限制了最小rto是200ms，個人感覺在tcp協議設計是為防止網路擁塞，但內網環境完全可以減少這個值，由rtt計算，畢竟相對內網丟包概率低，rtt非常小）
問題1浪費了頻寬，同時引起問題2狂發生報文，問題3會增加rt，但問題2又加劇了乙個請求在問題3出現超時重傳的概率。因此很多請求從發起到結束耗時超過1s，同時發現杭州機房也有問題1和2，但丟包比較少，因此rt情況比上海的好很多。而且上海到杭州多月5ms時延，問題2多次rtt傳送，50次約導致250ms浪費，看上去和之前210ms的rt比較接近。
可為什麼機器上直接curl速度正常，可程式呼叫就出現了上述報文的情況呢？分析tcp的引數，沒有什麼特別情況，那很大可能是應用上的問題，再看httpasyncclient的配置
httpasyncclient在初始化時候，有對socket的sosndbuf和sorcvbuf設定，我們設定是1024，是否此值有關聯呢？那就進行測試，把此值去掉取預設
果然協商的視窗變為5840，再換個機器，又成14600了。原來是不同版本的核心，對接收視窗的演算法有些不同，具體大家有興趣，可以檢視對應版本核心的原始碼
linux3核心的視窗演算法
初始的接收視窗的取值(mss的整數倍)：
（1）先考慮路由快取中的rtaxinitrwnd
（2）在考慮系統預設的tcpdefaultinitrcvwnd(10)
（3）最後考慮min(3/4 * skrcvbuf, windowclamp)，如果這個值很低
測試有效了，馬上就進行發布，mtop發布完成後，rt就降低到200ms，經過杭州繞一圈還比之前快了一點，再把流量全部切回上海，最終api的rt降低到約160ms。相比之前210ms，有50ms的rt降低。
同時因為這個引數小，如果revbuf滿了，應用沒有去取，那再有包過來，會直接丟棄，這樣引起問題3加劇，更加導致rt增長。
至於網路上，為什麼同樣情況下上海機房http呼叫出現超時重傳反而比杭州還多，網路的人正進一步分析排查
主要http接入的api不多，而且此api的資料比較大，進一步導致這問題，在處理完畢後其他http服務端的api也會帶來rt的降低
嘮叨那麼，詳細的介紹了整個問題的處理過程，rt也如第一張圖曲線波動，回過頭去分析總結這次排查的過程，主要一點點感受
1、排查問題的時候，一定要整體性的去思考，再每個節點的去分析。
2、對核心引數，要去深入的理解測試，對tcp引數的調整，要對不同版本核心對應測試分析效果
乙個api的 rt 大漲問題排查
mtop是移動接入網關平台，對客戶端暴露api，後端接api實際的應用服務，有hsf，也有http的服務端。之前進行了機房從杭州搬遷到上海，在搬遷的過程中，其中乙個api的rt突然大漲，之前平均的約210ms 分析具體的原因了，當時正機房搬遷，首先考慮的就是是否此影響，是否發生了跨機房呼叫的導致，當...
乙個api的 rt 大漲問題排查
mtop是移動接入網關平台，對客戶端暴露api，後端接api實際的應用服務，有hsf，也有http的服務端。之前進行了機房從杭州搬遷到上海，在搬遷的過程中，其中乙個api的rt突然大漲，之前平均的約210ms 分析具體的原因了，當時正機房搬遷，首先考慮的就是是否此影響，是否發生了跨機房呼叫的導致，當...
乙個記憶體洩漏問題的排查
監控的mem一直居高不下 使用jstat命令檢視gc的情況，發現ygc已經停止，一直在fgc，懷疑記憶體已經洩漏，堆記憶體中有大量無法 的物件。然後檢視gc日誌，發現年輕代和老年代使用率達到99 且full gc後記憶體沒有被 確定肯定是有物件無法被 需要解密的資料 這是加解密的功能，每次執行加解密...