Tomcat崩潰事件

文章目錄

• 二.簡單分析
• 三.效果

 http://hi.baidu.com/chaletlilh/blog/item/9e4cba194edb27b24aedbc9b.html

 

 

 

 

 

tomcat IOException while saving persisted sessions java.io.FileNotFoundException2008-10-28 15:43

Tomcat崩潰事件今天一大早產品一部專案經理就來找我，他們的一台伺服器昨天晚上tomcat服務崩潰，還不能重啟服務，最後將伺服器重啟才OK。 我將事件程序和分析過程記錄如下： 伺服器：win 2000 sp4，apache 2 + tomcat 5.0 採用mod_jk級聯。記憶體2G，硬碟剩餘空間充足，CPU基本空閑。 主要應用：J2EE 1.4，JDBC（串連另一台mysql伺服器） 崩潰時間： 2008-6-3 18：37：50 一.各種日誌綜合如下：    1.37分45秒，作業系統事件中諾頓殺毒軟體報記憶體過低警報    2.37分45秒，web應用拋出JDBC串連異常： 2008-06-03 18:37:45 cn.*.db.DBManager.getConnection(DBManager.java:157) ERROR swim.db.DBManager    com.mysql.jdbc.CommunicationsException: Communications link failure due to underlying exception: ** BEGIN NESTED EXCEPTION ** java.net.SocketException MESSAGE: java.net.SocketException: No buffer space available (maximum connections reached?): JVM_Bind    3.37分50秒，tomcat拋出session無法save異常： 2008-06-03 18:37:50 ERROR- IOException while saving persisted sessions: java.io.FileNotFoundException: /izzs/SESSIONS.ser (系統資源不足，無法完成請求的服務。) java.io.FileNotFoundException: /izzs/SESSIONS.ser (系統資源不足，無法完成請求的服務。)      at java.io.FileOutputStream.open(Native Method)      at java.io.FileOutputStream.<init>(FileOutputStream.java:179)      at java.io.FileOutputStream.<init>(FileOutputStream.java:70)      at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:511)      at org.apache.catalina.session.StandardManager.unload(StandardManager.java:485)      at org.apache.catalina.session.StandardManager.stop(StandardManager.java:687)      at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4496)      at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3037)      at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4658)      at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1619)      at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)      at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)      at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1608)      at java.lang.Thread.run(Thread.java:534) 二.簡單分析 崩潰原因：記憶體不足導致資源不足，引起Tomcat的session崩潰。 這台伺服器上運行著很多應用，是什麼原因引起記憶體不足還無法確定。 初步判斷罪魁禍首可能是apache，該進程平常佔用500MB記憶體，經常會飆到1G以上。 Apache2的設定檔中：KeepAlive=On，MaxKeepAliveRequests=100，KeepAliveTimeout=15，分析aceess.log檔案可以發現每個頁面觸發的request數量在10個以下，點擊率較低，可能使串連過多。 我建議將keepAlive設為off，增加CPU負載，降低記憶體消耗。 三.效果 有待觀察...... 參考資料： http://www.withend.com/post/78.html 四.結局 時隔一天，晚上九點再次崩潰，黑暗事件重演。 這一次，我才得知原來該apache還配置有其他網域名稱，於是調出該網域名稱下的access.log。專案經理去了機房，在轟轟地風扇聲中打電話給我，讓我分析分析。 仔細看訪問日誌，發現原來有N多Connect 443串連，443是什嗎？是SSL連接埠！HTTPS！，Connect命令則顯然是代理功能！ 而且這些connect的IP來自全球各地，加拿大、美國、澳洲、新西蘭、北京、上海、英國、哪都有。 看來這台伺服器是被人當Proxy 伺服器用了。 怪不得半夜會死機，人家西半球那時正大白天撒歡兒呢。 問題就出在apache的配置上，由於應用眾多，並且這台伺服器還是其他幾台web伺服器的對外出口，因此apache中配置了反向 Proxy，不過不小心把正向 Proxy（mod_proxy模組的ProxyRequests指令）也開啟了。 看看apache2.0的官方文檔中mod_proxy部分，裡面明明白白寫著：警告 在您沒有對伺服器採取安全措施之前，請不要用ProxyRequests啟用您的代理。一個開放的Proxy 伺服器不僅對您的網路有威脅，對整個網際網路來說也同樣如此。 真的是很有威脅！大量代理請求急劇消耗記憶體，最終造成死機！ 解決辦法就是把正向 Proxy關掉：ProxyRequests Off