新聞中心
近年來,我們專注于提供全系列企業級性能管理方案和相關的IT服務,在幫助用戶提高業務效率和整體生產力的同時,降低運營和運維成本。
返回列表
首頁 / 新聞資訊 / 公司動態
干貨 | OOM的故事之DEBUG實戰
來源:   日期:2018-12-29


OOM本質是程序程序申請內存過大,虛擬機無法滿足我們,然后自殺了。OOM經常伴隨Full GC,高JDBC, Pending User Request等一系列的問題內存溢出的案例數不勝數, 所以日常運維中我們需要盡量避免OOM的發生。

 

DEBUG日志在日常的開發和運維可以用來排查和定位問題。為排查問題,很多時候,應用需要啟用DEBUG日志。


而這次的故事主角就是DEBUG日志。


某客戶的一個應用不可用告警,經查看應用進程丟失,日志中有明顯的OOM報錯,由于我們已經優化了生產環境參數,所以,在OOM的同時,應用也生成了對應的內存快照文件。

 

我們首選是打開內存快照文件進行問題定位,從分析工具自動生成的報告文件中得知,存在一個疑似內存泄漏點a


OOM的故事之DEBUG373.png


可見406個WebLogic Execute Thread占用了89.95%的內存。


OOM的故事之DEBUG389.png


看到這里,我們的第一個反應是,我們的線程在異常發生時間點是否正常?

有沒有STUCK線程?

為什么會積攢406個執行線程?

是不是本身觸發了WebLogic本身的Bug呢?


為了解答這些困惑,OLM工程師查看執行線程的信息來確認問題發生時間點執行線程在做什么(截取線程關鍵信息如下):

 

OOM的故事之DEBUG572.png

OOM的故事之DEBUG574.png

OOM的故事之DEBUG576.png

OOM的故事之DEBUG578.png


這部分代碼

org.apache.http.impl.conn.Wire.wire

屬于Apache Http Client


參考鏈接

http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/conn/Wire.html


從官方的說明看這部分代碼是控制報文日志記錄。這一點,在dominator_tree結構圖中得到了證實。


OOM的故事之DEBUG918.png



從展開的日志內容看,我們可以確認應用的log4j的日志級別為DEBUG(為確保客戶信息,進行了脫敏處理)。


從Dump文件中,我們確認了出問題報文對應的URL請求

http://XXXXXXX:XXXXXX/XXXXGeneralHttpTask/GeneralService/CallxxxxxxResultDealReplace


確認了出現問題的應用包位置,并最終確認應用日志級別確實設置為Debug。


OOM的故事之DEBUG1223.png


也說明填滿內存的主要對象確實是DEBUG日志。


溫馨提示:

Debug日志可以協調我們定位問題,但是在生產環境中還是需要謹慎開啟,對于業務大的環境,我們每一個細微的參數,都有可能導致生產環境的崩潰。





|  北京    |    上海    |   廣州    |   成都    |


4008-906-960



4008-906-960

全國免費咨詢電話
  • 官方微博
  • 官方微信
Copyright 1998-2016 版權所有 北京東方龍馬軟件發展有限公司 京ICP備14000200號-1
bet365体育备用器 广西快三今天开奖结果 3d试机号结果今天晚上 福建31选7开奖结果查询 大乐透后区和值走势图新浪网 足彩混合过关的胜其它 北京多乐彩合法吗 重庆欢乐生肖是正规彩票吗 开心棋牌游戏975 069香港赛马会 杰克棋牌手机端