一次排錯調(diào)優(yōu)的方法步驟

本篇內(nèi)容主要講解“一次排錯調(diào)優(yōu)的方法步驟”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“一次排錯調(diào)優(yōu)的方法步驟”吧!

（一）前言

最近發(fā)生了一件很讓人頭疼的事情，已經(jīng)上線半年且平穩(wěn)運行半年系統(tǒng)在年后早高峰的使用時發(fā)生了瀕臨宕機的情況。訪問速度特別慢，后臺查到大量time_wait的連接，從代碼層面到架構(gòu)層面到網(wǎng)絡(luò)層面排查了幾天幾夜，總算是有了結(jié)果。

（二）架構(gòu)、問題描述

先簡單描述一下這個系統(tǒng)的架構(gòu)，公網(wǎng)域名對應(yīng)的公網(wǎng)IP連接著華為云的ELB彈性負載均衡服務(wù)，ELB下是兩臺Nginx服務(wù)器多活，Nginx下連接著四臺內(nèi)網(wǎng)應(yīng)用集群服務(wù)器（通過專線），Mysql服務(wù)器讀寫分離、Redis服務(wù)器主從配置。

發(fā)生宕機問題時，四臺集群服務(wù)器的Load Average飆到了200，要知道8核的服務(wù)器Load average超過40就需要注意了。同時Nginx的tcp連接數(shù)也異常，有大量的TIME_WAIT連接。

（三）問題排查

這個問題主要原因還是系統(tǒng)擋不住突然間的高并發(fā)，根據(jù)上面的這些報錯數(shù)據(jù)，首先是想辦法把load average降下去。請求大于當前的處理能力，會出現(xiàn)等待，引起load average升高。因此主要從下面幾個方面進行了排查：

3.1 檢查Nginx配置

首先是運維人員檢查Nginx配置，看看是否是配置不對造成大量time_wait連接，檢查結(jié)果是沒有問題。

3.2 抓網(wǎng)絡(luò)請求

運維人員幫忙抓取了應(yīng)用服務(wù)器在高并發(fā)時的網(wǎng)絡(luò)包，最后分析下來有一個接口的請求次數(shù)是所有請求的40%。這是一個疑問點，這個請求為什么會被調(diào)用如此多的次數(shù)。

3.3 檢查線程堆棧信息

因為請求數(shù)量如此多，因此需要檢查占用CPU最高的線程堆棧信息，最后發(fā)現(xiàn)垃圾回收線程竟然占用了30%+資源，說明垃圾回收應(yīng)該是存在一些問題的。

3.4 檢查數(shù)據(jù)庫連接池

檢查數(shù)據(jù)庫連接池是否正常，看看有無死鎖或者資源耗盡等問題，查出來是一切正常的。

3.5 檢查垃圾回收情況

通過jstat -gcutil 命令抓取垃圾回收情況，發(fā)現(xiàn)YGC很頻繁，大概一秒一次，下圖是高峰期過了之后的垃圾回收情況，YGC大概在一分鐘8次左右。因此也是懷疑業(yè)務(wù)代碼存在問題。

（四）定位業(yè)務(wù)代碼

通過上面的信息，我們初步懷疑那個被頻繁調(diào)用的接口存在問題。查到代碼后，發(fā)現(xiàn)每次刷新頁面的時候，都會調(diào)用這個接口7次，這種調(diào)用太頻繁了。同時代碼中發(fā)現(xiàn)了大量JSON轉(zhuǎn)換、序列化的情況，查了一些資料后發(fā)現(xiàn)這種行為確實會導(dǎo)致YGC頻繁操作。

于是優(yōu)化代碼邏輯，刷新頁面的時候調(diào)用一次接口就行，數(shù)據(jù)一次性傳給前端，而不是多次調(diào)用。同時將沒有必要的JSON轉(zhuǎn)換代碼優(yōu)化掉。按理說現(xiàn)在的性能應(yīng)該可以提升不少。打包、上傳、重新觀察。

（五）問題還是存在

平穩(wěn)了4天，在周五早晨高峰的時候，運行緩慢、負載高的情況又發(fā)生了。這下傻眼了，難道是有其他地方?jīng)]有檢查到嗎。

這時想到一個問題，明明一直沒有動這些服務(wù)器，為什么平穩(wěn)運行了半年后突然出現(xiàn)問題，于是往其他方面去想，懷疑是從公網(wǎng)IP進來到應(yīng)用服務(wù)器中的某條鏈路存在問題。于是嘗試著斷掉公網(wǎng)鏈路，去壓測放在內(nèi)網(wǎng)的這些應(yīng)用，竟然不會出現(xiàn)之前的問題。

于是檢查公網(wǎng)到內(nèi)網(wǎng)的專線網(wǎng)絡(luò)請求情況，發(fā)現(xiàn)出口帶寬最高就只能到200M，就是早高峰的時候，而當時買的專線帶寬是可以到500M的。因此懷疑是帶寬滿了導(dǎo)致請求進不來堵塞在公網(wǎng)的Nginx服務(wù)器上，而用戶發(fā)現(xiàn)運行緩慢后頻繁去刷新，導(dǎo)致大量的Tcp連接time_wait。于是趕緊聯(lián)系相關(guān)服務(wù)商對網(wǎng)絡(luò)帶寬情況進行檢測，果然500M的帶寬直接打了折扣，聯(lián)系相關(guān)人員處理這方面的問題。

同時一些靜態(tài)資源放在私有云的服務(wù)器上也會導(dǎo)致網(wǎng)絡(luò)流量大，將這些靜態(tài)資源分離到公有云的Nginx服務(wù)器上，來降低這條專線的網(wǎng)絡(luò)壓力。

到此，相信大家對“一次排錯調(diào)優(yōu)的方法步驟”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！