閱讀目錄
最近有個用戶量 5W-10W 的 web 應用，頻繁導致 weblogic 崩潰，讓運維組很難受。
通過幾天跟蹤系統(tǒng)日志和 weblogic 運行狀況，發(fā)現報錯的姿勢有很多，其中對定位問題比較關鍵的報錯：
ExecuteThread: '496' for queue: 'weblogic.kernel.Default (self-tuning)' has beenbusy for "712" seconds working on the request "XXXX", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.
weblogic 分配給 web 應用使用的線程響應返回周期最大為10分鐘，線程遲遲無法返回結果導致阻塞，并且這樣的刺頭線程越來越多。
運行一段時間后達到 weblogic 阻塞線程的閥值，weblogic 自然就崩潰了。
剛開始也試著調大 weblogic 響應周期/阻塞線程的閥值，但是阻塞線程還是會存在并且很快達到閥值。
仔細比對奔潰前后日志，查看 weblogic 阻塞線程詳情，導致阻塞開始罪魁禍首是數據庫查詢需要很長時間。
該系統(tǒng)與內外圍很多廠商系統(tǒng)有進行數據交互，數據庫里面旁根錯雜的 db_link/synonyms/view/procedure。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉無線電——不安全的藍牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現JSON轉Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應用分析 2017-07-26
- 集合結合數據結構來看看(二) 2017-07-26
學習是年輕人改變自己的最好方式