TOMCAT崩潰事件
http://www.blogjava.net/tedeyang/archive/2008/06/04/205740.html
今天一大早產品一部項目經理就來找我,他們的一臺服務器昨天晚上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連接異常:
** ? 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異常:
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來自全球各地,加拿大、美國、澳洲、新西蘭、北京、上海、英國、哪都有。
看來這臺服務器是被人當代理服務器用了。
怪不得半夜會死機,人家西半球那時正大白天撒歡兒呢。
問題就出在apache的配置上,由于應用眾多,并且這臺服務器還是其他幾臺web服務器的對外出口,因此apache中配置了反向代理,不過不小心把正向代理(mod_proxy模塊的
ProxyRequests
指令
)也打開了。
看看
apache2.0的官方文檔中mod_proxy部分
,里面明明白白寫著:



解決辦法就是把正向代理關掉: ProxyRequests Off
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
