線上事故復盤

前言

• 前一次上線，當時正常，第二天發現有部分超時報警，最終發現應為Dubbo接口一次傳輸數據量太大導致線程虛擬內存占用

線上問題排查過程

• 報警郵件中查詢到有一部分接口超時量激增，查詢定位到某個Dubbo接口，從服務器中top名查詢如下：

• 如上圖顯示dubbo項目進程CPU占用已經飆高到128%，并且不斷在波動，一直維持在130%左右，初步推算是調用量激增導致Dubbo接口請求量變大，導致線程數量消耗，使用Arthas查詢消耗CPU資源最多的前面幾個線程如下圖：
  圖不見了： 反正CPU前幾名都指向同一個Dubbo接口，命令 Thread -n 5, 查詢CPU資源消耗最多的前五名

• 查詢對應Dubbo接口的請求數量，用Awk命令統計今天的請求量看是否增多如下：
  

• 量居然這么小，因為是新的接口，只有部分功能使用，那么上面估計的請求量的問題應該不存在，但是CPU消耗的卻很大，估計是因為耗時太長，在通過TOP命令查詢，問題發現Men區域內核緩沖使用量很高39562828，比之空閑的物理內存379888高兩個數量級
  

• 量這么小的Dubbo接口能把交換區的資源耗盡，那問題就比較明顯了，應該是每次處理的數據體量太大，內存不夠，導致處理數據變慢，接口響應時間變慢，那之后就好查詢了，繼續更這個接口，看那部分信息有問題，發現在sql查詢中查了一個這個字段，text類型，超級大，并且一次查出來的數據條數也比較大，導致最終Dubbo接口需要返回的數據量太多

`detail` text COMMENT '摘要',

• 因dubbo協議采用單一長連接，如果每次請求的數據包大小為500KByte，假設網絡為千兆網卡(1024Mbit=128MByte)，每條連接最大7MByte(不同的環境可能不一樣，供參考)，單個服務提專供者的TPS(每秒處理事務數)最大為：128MByte / 500KByte = 262，單個消費者調用單個服務提供者的TPS(每秒處理事務數)最大為：7MByte / 500KByte = 14。
• 如上名計算如果我數據量繼續變得更大，但是沒有超過Dubbo限制情況下，其實每次處理數據是非常消耗內存與IO的。
• 最終修改將不必要字段去除，上線發布，耗時下降，內存信息，cpu都恢復正常，如下圖：
  

總結

以上是生活随笔為你收集整理的记录一次线上超时异常查询的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。