TOMCAT崩潰事件
http://www.aygfsteel.com/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連接異常：
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來自全球各地，加拿大、美國、澳洲、新西蘭、北京、上海、英國、哪都有。
看來這臺服務器是被人當代理服務器用了。
怪不得半夜會死機，人家西半球那時正大白天撒歡兒呢。
問題就出在apache的配置上，由于應用眾多，并且這臺服務器還是其他幾臺web服務器的對外出口，因此apache中配置了反向代理，不過不小心把正向代理（mod_proxy模塊的ProxyRequests指令）也打開了。
看看apache2.0的官方文檔中mod_proxy部分，里面明明白白寫著：
警告
在您沒有對服務器采取安全措施之前，請不要用ProxyRequests啟用您的代理。一個開放的代理服務器不僅對您的網絡有威脅，對整個因特網來說也同樣如此。
真的是很有威脅！大量代理請求急劇消耗內存，最終造成死機！
解決辦法就是把正向代理關掉：
ProxyRequests Off