Tomcat假死排查方案

  使用Tomcat做爲Web服務器的時候偶爾會遇到Tomcat中止響應的狀況,經過netstat查看端口狀況會發現tomcat的端口出現大量的CLOSE_WAIT,此時Tomcat會中止響應前端請求,同時服務端的日誌,操做等將所有中止,並且沒有出現任何異常,此時就須要排查是哪方面的緣由,此案以之前的解決爲例總結排查方案前端

  

  一、首先確認頁面端正常時請求沒有問題數據庫

  二、對於使用Nginx做爲前端負載均衡Tomcat集羣,經過Nginx的訪問日誌(access.log)確認頁面到Nginx沒有問題tomcat

  三、查看Tomcat的訪問日誌(localhost_access_log.txt)查看前端請求是否訪問到Tomcat服務器

    

 

  四、查看Tomcat的狀態控制檯,查看Tomcat的請求和內存佔用狀況負載均衡

    

    查看那些請求處於等待狀態,排查這些請求的服務是否存在問題(長事務、頻繁事務)框架

  五、查看數據庫進程查看當前數據庫實例是否出現死鎖日誌

    

    若是出現死鎖,排查代碼中出現死鎖的緣由,解決死鎖問題blog

  六、若是以上都沒有問題,排查代碼中的定時任務進程

    查看定時任務事務是否存在問題(長事務、頻繁事務)事務

  七、檢查是不是頻繁的寫日誌形成Tomcat阻塞

    對於訪問量比較大的系統,若是項目採用Info或者Debug日誌級別的話會形成Tomcat頻繁的讀寫幾百兆甚至上G的日誌文件,形成Tomcat阻塞

 

曾經遇到的一次Tomcat出現CLOSE_WAIT時,經過排查發現是一位同事在經過定時任務作其餘系統的數據同步時時出現的問題形成的,問題總結以下:  一、同步其餘系統的數據是耗時較長,其採用Spring的切面事務,形成同步時事務時間長達幾分鐘時間,存在死鎖風險  二、同步數據完須要處理數據,此時的處理數據邏輯會存在多達幾萬次的數據庫變動,當前操做沒有采用切面事務,而是採用框架的AutoCommit自動提交事務,這樣就會形成處理數據時出現幾萬次的建立事務,提交事務,關閉事務,此時形成事務阻塞解決方案:  一、處理時間較長的操做,若是當前操做中間出現問題對業務沒有影響下次操做時會修正當前業務,這樣的話能夠不適用切面事務而是使用框架的AutoCommit提交事務,若是當前操做確實須要保證原子性時,請手動回覆數據裝填  二、不要頻繁的開啓、提交事務,採用批量的方式提交事務

相關文章
相關標籤/搜索