2020-07-17：線上一個服務有4個實例突然變得訪問很慢，你會從什么地方入手找原因？

福哥答案2020-07-17：

聲明：該總結為網友朋友總結，本人是歸納成文，方便各網友學習交流。

在一個高并發系統中 如果突然出現一個應用或者說一個服務突然變得很慢，應該怎么排查？

這個是考線上排查問題能力，沒有標準答案，作為開發，假設這種情景出現你怎么診斷問題？

首先：想知道，在實際情況下，怎么知道【一個應用或者說一個服務突然變得很慢】？調用訪問的時候會發現的，對于業務流程比較熟悉很重要，先能夠初步圈出，可能出現問題的地方，服務監控是必須的，做業務必須要知道自己服務的狀態。

1、首先就是想看日志，后來想想看日志確實不太可行，并發量太大的情況下，查日志會很慢，（看日志，pstack strace gdb）。

2、應該從上到下看。----網絡，系統，應用。任何一個環節都有可能有問題,首先看網絡監控情況，然后看系統（內存，cpu,負載 ）情況。

3、把線程dump出來，用jstack dump 線程調用鏈，看線程卡到哪里了。然后定位代碼，看看賭在哪個函數，是不是調用了重函數。當然先定位到具體應用，再dump。

4、看接口故障率，然后看數據庫有沒有鎖。

5、先看日志，排除了磁盤滿了，網絡慢，然后看進程，具體到當時幾個線程，堵在哪兒。

6、分布式服務一般都是服務治理的，可以看整個調用鏈的時間圖。

7、看監控，監控只是能找到問題 但是不能找到問題原因，什么請求、返回、錯誤、慢速，這些都是要監控的，告警也要配置好，有問題第一時間知道。

8、假如是網絡問題那就找臨近的防火墻看對應服務器的并發連接數是否新建連接/半開連接超高，或者有突發流量擠占了資源。同時查對應服務器的磁盤I/O情況和對應那個應用的進程內存占用曲線是否有突發。高并發應用我理解上日志肯定是沒法去看的，因為日志量太巨大了。

9、集群或多主機的系統，需要根據監控 看各個主機的CPU 內存 接口IO等，這些能分析一些，如果能得出具體的主機 再分析哪個應用的CPU 內存 異常dump 等。如果涉及到接口機 可以看接口的失敗率，應用的話需要排查log了，有時候主機空間不足 內存不足、硬件故障也會導致問題。

10、例子：在銀行做安全運維時候，那幫服務器的和網銀的一天到晚就說這是網絡問題，這絕對網絡癱了。。然后查一圈發現他們一個什么java的問題，說是有個印度小哥把java runtime裝了最高版本。但是系統不支持，必須重新裝回低版本，就好了。

11、如果是分布式部署多臺機器，別的機器沒問題，但這臺機器有問題。那么更有可能是因為網絡或者磁盤導致的，一般這些資源都有zabbox這樣的監控。看日志是肯定要的。

12、如果這些機器都是虛擬機的話也有可能是控制器系統的問題。

13、擴展：

阿里，負載均衡和流量清洗系統強大，每年網購高峰期和那幾個“節”一過0點的突發流量，很考驗負載均衡系統的部署策略。高峰限流是關鍵，不能沖垮系統，但高峰一限流。。購物車就無法結賬了。（異步結帳）

京東，雙12 的時候。負載均衡也會出問題。有時候，負載不均衡的情況出現，有針對應用的限流和熔斷的，也有針對URL的限流和熔斷機制。

另外：DDOS攻擊、負載均衡算法沒設計好、CDN、DNS等都有可能。

網絡 任務調度

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。