TOMCAT崩潰事件
http://www.blogjava.net/tedeyang/archive/2008/06/04/205740.html
今天一大早產(chǎn)品一部項(xiàng)目經(jīng)理就來找我,他們的一臺服務(wù)器昨天晚上tomcat服務(wù)崩潰,還不能重啟服務(wù),最后將服務(wù)器重啟才OK。
我將事件過程和分析過程記錄如下:
服務(wù)器:win 2000 sp4,apache 2 + tomcat 5.0 采用mod_jk級聯(lián)。內(nèi)存2G,硬盤剩余空間充足,CPU基本空閑。
主要應(yīng)用:J2EE 1.4,JDBC(連接另一臺mysql服務(wù)器)
崩潰時(shí)間: 2008-6-3 18:37:50
一. 各種日志綜合如下:
??
?
1.
37分45秒,操作系統(tǒng)事件中諾頓殺毒軟件報(bào)內(nèi)存過低警報(bào)
??
?
2.
37分45秒,web應(yīng)用拋出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?(系統(tǒng)資源不足,無法完成請求的服務(wù)。)
????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 )
?
二.簡單分析
崩潰原因:內(nèi)存不足導(dǎo)致資源不足,引起Tomcat的session崩潰。
? 這臺服務(wù)器上運(yùn)行著很多應(yīng)用,是什么原因引起內(nèi)存不足還無法確定。
初步判斷罪魁禍?zhǔn)卓赡苁莂pache,該進(jìn)程平常占用500MB內(nèi)存,經(jīng)常會飚到1G以上。
Apache2的配置文件中:
KeepAlive=On,MaxKeepAliveRequests=100,KeepAliveTimeout=15
,分析aceess.log文件可以發(fā)現(xiàn)每個(gè)頁面觸發(fā)的request數(shù)量在10個(gè)以下,點(diǎn)擊率較低,可能使連接過多。
我建議將keepAlive設(shè)為off,增加CPU負(fù)載,降低內(nèi)存消耗。
三.效果
?有待觀察......
參考資料:
http://www.withend.com/post/78.html
四.結(jié)局
?
時(shí)隔一天,晚上九點(diǎn)再次崩潰,黑暗事件重演。
這一次,我才得知原來該apache還配置有其他域名,于是調(diào)出該域名下的access.log。項(xiàng)目經(jīng)理去了機(jī)房,在轟轟地風(fēng)扇聲中打電話給我,讓我分析分析。
仔細(xì)看訪問日志,發(fā)現(xiàn)原來有N多Connect 443連接,443是什么?是SSL端口!HTTPS!,Connect命令則顯然是代理功能!
而且這些connect的IP來自全球各地,加拿大、美國、澳洲、新西蘭、北京、上海、英國、哪都有。
看來這臺服務(wù)器是被人當(dāng)代理服務(wù)器用了。
怪不得半夜會死機(jī),人家西半球那時(shí)正大白天撒歡兒呢。
問題就出在apache的配置上,由于應(yīng)用眾多,并且這臺服務(wù)器還是其他幾臺web服務(wù)器的對外出口,因此apache中配置了反向代理,不過不小心把正向代理(mod_proxy模塊的
ProxyRequests
指令
)也打開了。
看看
apache2.0的官方文檔中mod_proxy部分
,里面明明白白寫著:



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

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