一次排錯調優的方法步驟

本篇內容主要講解“一次排錯調優的方法步驟”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“一次排錯調優的方法步驟”吧!

（一）前言

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

（二）架構、問題描述

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

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

（三）問題排查

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

3.1 檢查Nginx配置

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

3.2 抓網絡請求

運維人員幫忙抓取了應用服務器在高并發時的網絡包，最后分析下來有一個接口的請求次數是所有請求的40%。這是一個疑問點，這個請求為什么會被調用如此多的次數。

3.3 檢查線程堆棧信息

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

3.4 檢查數據庫連接池

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

3.5 檢查垃圾回收情況

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

（四）定位業務代碼

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

于是優化代碼邏輯，刷新頁面的時候調用一次接口就行，數據一次性傳給前端，而不是多次調用。同時將沒有必要的JSON轉換代碼優化掉。按理說現在的性能應該可以提升不少。打包、上傳、重新觀察。

（五）問題還是存在

平穩了4天，在周五早晨高峰的時候，運行緩慢、負載高的情況又發生了。這下傻眼了，難道是有其他地方沒有檢查到嗎。

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

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

同時一些靜態資源放在私有云的服務器上也會導致網絡流量大，將這些靜態資源分離到公有云的Nginx服務器上，來降低這條專線的網絡壓力。

到此，相信大家對“一次排錯調優的方法步驟”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！