問題描述

超影網站系統經常莫名奇妙的就不響應，特別是當釋出一些活動後訪問數量比平時多的時候這種情況尤為突出，表現為使用者不能訪問網站，需要重新啟動服務才能夠解決。

[編輯]問題解決步驟

[編輯]初步把脈

1. 登入線上伺服器後發現tomcat例項並沒有死掉，依然還存在，cpu、記憶體耗費的也不大，80埠依然被佔用，通過瀏覽器輸入http://localhost 不響應，但telnet localhost 80會返回資訊。
2. 試圖去尋找相關日誌，tomcat_home/logs下沒有任何日誌，試圖使用jvisualvm檢視tomcat記憶體和執行緒狀況，但在jdk目錄下卻找不到這個工具。試圖使用jps和jstat工具，但不能發現java程序id。
3. 猜測是記憶體配置太小或者執行緒死鎖問題，但沒有證據支援。試圖修改catalina.bat配置新的虛擬機器記憶體，配置重啟後，依然會出現宕機問題，通過工作管理員發現tomcat程序記憶體不超過150m，也沒有記錄下jvm gc日誌。配置為

   -Xms1024m -Xmx1024m -Xmn512m -XX:PermSize=64M -Xmn=400m -XX:MaxPermSize=128m  -XX:+PrintGCDetails  -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps  -Xloggc:D:\gclog\gc.log 

4. 百思不得其解，仔細觀察系統的部署方式，發現和官方推薦的方法不同，是通過自己寫的bat指令碼實現，指令碼中自行呼叫java -jar的模式啟動，其配置的最大記憶體值是100m，這就解釋了為什麼工作管理員裡tomcat只佔不到150m了和在catalina.bat裡配置的java引數完全不起作用了。接下來通過在install-bos.bat指令碼中指定jvm引數配置大記憶體：

   -Xms900m -Xmx900m -Xmn500m -XX:PermSize=64M -XX:MaxPermSize=128m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps  -Xloggc:D:\gclog\gc.log

   這樣終於可以看到gc日誌了。通過日誌分析，發現目前線上jdk的版本比較低，沒有server版本，gc採用序列化方式。
5. 通過初步配置大記憶體，系統穩定了許多，但是司機現象依然存在，只是出現的頻率小了，懷疑有資料庫慢查詢，通過開啟資料庫的慢查詢日誌，發現大量慢查詢語句，這些語1句基本都處理影片遮蔽功能的，需要解決這些慢查詢。
6. 分析這些慢查詢語句，發現有兩個問題：
   1. select處理過多的欄位，特別是影片簡介欄位，很長但在頁面顯示時卻並不這些資料，佔很多記憶體空間，這樣可能造成年輕代gc頻繁，當用戶量大時，年輕代頻繁gc造成老領代暴增，最終造成full gc，但大量頁面請求還沒有完成，記憶體資料依然在不能被gc，所以頻繁full gc。
   2. 頻繁select，多個方法其實使用大致相同的資料，完全可以一次讀取所有資料，在多個方法中傳遞使用，降低select和資料物件構造的頻率，從而降低gc頻率。

[編輯]深度研究

1. 為了徹底解決這個問題，特地部署測試機，採用jdk64位最新版+tomcat6 64位版本，採用官方推薦模式部署，然後通過loadrunner做壓力測試
   1. 首次測試，併發50人，壓10分鐘即崩潰，分析發現，這次測試時使用windows service模式部署tomcat，造成catalina.bat的jvm配置引數無效，研究發現，以windows service模式部署時，jvm引數配置需要在service.bat中配置：

      set Jvm_Options="-XX:NewSize=512m;-XX:MaxPermSize=128m;-XX:+PrintGCDateStamps;-XX:+PrintGCTimeStamps;-XX:+PrintGCDetails;-XX:+PrintTenuringDistribution;-Xloggc:e:/gclog/gc.log"

      "%EXECUTABLE%" //US//%SERVICE_NAME% ++JvmOptions %Jvm_Options% %Debug_Options%  "-DRootPath=%CATALINA_HOME%\webapps";-Duser.dir=%CATALINA_HOME%;-Djava.io.tmpdir=%CATALINA_BASE%\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=%CATALINA_BASE%\conf\logging.properties" --JvmMs 1024 --JvmMx 1024

      "-DRootPath=%CATALINA_HOME%\webapps";-Duser.dir=%CATALINA_HOME%是目前系統初始化需要的目錄配置

      --JvmMs 1024 --JvmMx 1024是jvm記憶體配置

   2. 再次壓測，50人10分鐘即崩潰，分析gc日誌，年輕代的gc頻繁，老齡代上漲迅速，有一段時間持續full gc，每次都不能釋放記憶體，持續full gc造成程式不響應，猜測記憶體洩漏，查詢程式碼檢視發現有洩漏的靜態變數，但未發現洩漏點，通過jstat分析tomcat程序記憶體，發現1小時內不再訪問系統，記憶體會逐漸降下來，所以分析，沒有記憶體洩漏點，是gc頻率造成。
   3. 慢查詢解決後壓測，本次測試使用50併發，壓測1小時，系統響應響應，但會出現資料庫連線失敗異常。分析應該系統訪問資料庫沒有使用連線池，而是直接使用jdbc連線造成的。
   4. 到此為止，需要解決的問題就只剩下資料庫連線池問題了。試圖使用jndi來實現連線池：
      1. 亂碼問題，曾經試圖使用過jndi連線池，但發現數據亂碼，不能解決，一般google的結果是在資料庫url中增加characterEncoding=utf-8即可解決，如果有問題，把'&'修改為'&',即可，但我們的卻不行，分析發現系統使用的jdbc驅動是3.x.x版本，但資料庫是5.0版本，猜測是jdbc驅動不匹配，換成5.0.8解決亂碼問題。
      2. 日期型資料問題，亂碼問題解決後，發了日期型資料處理有問題，當資料庫datetime欄位為0時，系統報不能把'0000-00-00 00:00:00'轉化為datetime異常，但在jdbc3.x.x下沒有問題，應該是換jdbc驅動造成的，經過google發現，在url上增加zeroDateTimeBehavior=convertToNull即可解決。
   5. 再次壓力測試還沒有開始，5月14號後需要再次測試。

[編輯]反思

1. 日誌問題。日誌是系統出現故障時，程式設計師分析、解決問題的利器。監控、轉儲程序記憶體堆疊並記錄成檔案應該是每個程式設計師必備的技能，開發新系統時定義結構良好的日誌子系統更是架構師必須的責任。日誌是如此的重要，但我們的系統無論是tomcat的日誌還是系統的日誌都沒有記錄，或者記錄的是沒有價值的。程式中到處可見捕獲異常後沒有輸入堆疊而直接定義一個新的異常丟擲的程式碼，這種程式碼拋棄了系統異常的第一手資料。
2. 部署問題，系統的部署完全無視tomcat官方推薦的部署方案，純粹的自定義，增加了解決問題的難度
3. 程式碼精煉問題，程式碼基於的資料庫訪問框架有很多程式碼與我們的業務沒有關係，應該剔除

[編輯]其他

配置某一應用為tomcat的預設應用：

• 刪除webapps下原來的所有應用
• 刪除conf/catalina下所有
• server.xml中Host元素下新增

  <Context>path="" docBase="/WebApp" reloadable="true" crossContext="true" </Context>