生產服務記憶體洩露排查

生產環境，我們使用rancher k8s部署我們的服務，有個服務（具體我這裡就不說了），在晚上8點左右，因為這個服務的記憶體溢位導致了其他服務出現了異常，在8點的時候，客戶頻繁投訴，後面排查發現是有個服務記憶體洩露。通過grafana圖形觀察，可以明顯看到其實這個服務在早市11點左右其實已經記憶體洩露，只是當時客戶並沒有發現。

因為生產已經掛了，當時我們進入服務的pod中簡單執行如下命令。不要問為什麼這麼做，其實這個記憶體洩露問題已經出現過幾次了，但是不知道問題點在哪，剛好這次復現，就趕緊找到罪魁禍首

jps -lm
jmap -histo 6|
head -20

先找到占用記憶體最大的實體類

有

還好，當時這個服務用到的finebiequipmentfeign比較集中，這個是提供資料給報表服務用的。

找到**如下

/***
* type:1.裝置歷史引數查詢報表 2.裝置歷史引數查詢趨勢圖
* @return
*/(value =
"/selectitem"
public responseentity selectitem
(@requestbody finebiequipmentquery finebiquery)
"+ finebiquery.
getendtime()
);log.
info
("getbegintime*****===={}"
+ finebiquery.
getbegintime()
);long period =
(long.
parselong
(finebiquery.
getendtime()
)- long.
parselong
(finebiquery.
getbegintime()
))/1000
;            log.
info
("period*****===={}"
+ period)
;            map
maps =
newhashmap
<
>(16
);******dateformat sf =
new******dateformat
("yyyy-mm-dd hh:mm:ss");
log.
info
("finebiquery*****===={}"
+ jsonutil.
tojsonstr
(finebiquery));
list
list = finebiservice.
selectalltype
(finebiquery)
;            log.
info
("list**********={}"
+ list.
tostring()
);list
maplist =
newarraylist
<
>(16
);list
synchronizedlist = collections.
synchronizedlist
(maplist)
;long starttime = system.
nanotime()
;            list.
parallelstream()
.foreach
(infolist -
>
;                map.
put(
"paramids"
, deviceparmaids)
;                map.
put(
"deviceid"
, infolist.
getdevice_id()
);map.
put(
"period"
, period)
;                map.
put(
"endts"
, long.
parselong
(finebiquery.
getendtime()
));                jsonarray.
add(map)
;//第三方api介面(本場景為外調介面，根據公司框架和業務自行修改)
("查詢耗時："
+(endtime - starttime)
/1000
/1000);
log.
info
("總共:"
+ result.
size()
+"條資料*************************==>");
log.
info
("result:{}"
, jsonutil.
tojsonstr
(result));
maps.
put(
"records"
, result)
;return
successresult
(maps);}
catch
(exception e)
", e)
;return
errorresult();}}

最開始肉眼看**，沒有看出什麼問題

後面實在沒有辦法，最開始在sit環境測試想復現這個問題，後面發現還是不行。因為sit沒有資料上報的資料，資料量不夠，所以在直接在uat環境上測試。經過測試只要報表查詢資料量足夠大，就會導致堆疊溢位。

在記憶體溢位後，在檢視堆疊中物件大小排名，明細看到物件已經被釋放掉，所以說明**是沒有問題的。真正的問題，是資料量大，導致一直往synchronizedlist集合存放資料，導致的記憶體溢位

生產服務記憶體洩露排查

Redis 生產事件排查

記一次Pytorch記憶體洩露的排查與處理

記憶體洩露檢測

生產服務記憶體洩露排查

Redis 生產事件排查

記一次Pytorch記憶體洩露的排查與處理

記憶體洩露檢測

相關推薦