轉載was當機處理：WAS7叢集上傳下載問題分析及動靜分離

下文是網上看到的一位朋友處理was當機的記錄，和我專案上一般遇到的was當機問題差別較大（我們專案是上一般was當機主要是oom、執行緒池滿、非常少量的連線池滿，另外我們的專案上基本上都用ihs或者硬體分發裝置如F5或redware等），他這裡處理問題分析的過程還是記錄蠻詳細的，最後關於監控和針對其問題對IHS外掛配置這也說了下，如果遇到類似問題沒準可以借鑑一下，呵呵。

http://www.webspherechina.net/home/space.php?uid=201&do=blog&id=56444

http://www.webspherechina.net/home/space.php?uid=201&do=blog&id=54852

繼續去年沒寫完的文件，由於時間比較忙一直沒來得及總結。雖然系統已經上線執行快4個月了。中間出了一些大大小小的問題，下面就一一說明。

上次是寫到第3點：附件上傳資料流量測試

檔案上傳的測試，透過測試工具進行測試基本上沒發現太大的問題，不過由於測試環境的網路比較好，所以也很難發現問題。正式上線之後檔案的上傳這塊也沒太大的問題，因為有問題也最多是上傳不了資料。J

但是對於附件的下載這塊卻沒有進行比較好的測試，導致上線的2個星期都出現了一個大問題。

問題主要出現在網站這塊， 由於網站上有提供不少幫助文件、安裝包程式的下載，同時網站的訪問量也非常大，導致網站頻繁當機。 最多的一天死8次機，最短時間是在啟動之後5分鐘就down 機了。

先說網站服務環境：

作業系統： RHEL 5.5

應用伺服器： WAS 7 單節點 。部署了3個應用分別是： cms 是網站， fileStorage_war 是附件目錄及下載應用，qyww 是資料查詢應用

資料庫：Orcale 11g

從環境的配置上來說，也可以看出比較大的問題，網站這種面向公眾的服務，其壓力可能比內網的業務系統的服務壓力還要大，這點由於我們設計上的疏忽導致了頻繁當機的重要原因之一。

其實一開始為什麼會這種設計，是因為我們做過網站的壓力測試，可以支援到4000的併發訪問，而且這個測試結果是由專門的測試公司做的，有了這個資料，我們專案組上對於網站這塊才沒太多的關注，在伺服器配置上也沒做叢集。而且這個網站又是一個政府事業部門的網站，按照慣例我們認為訪問的人不會太多。誰知道結果真是出人意料，內網的業務系統沒怎麼當機，反而外網的網站卻是頻繁當機。客戶因為這個，都打電話投訴到北京總部去了。

真是血的教訓啊。。。廢話不說了，直接說怎麼解決問題吧。

解決方案一：

由於時間比較緊，為了增加網站的穩定性和訪問量支援，就需要對網站的部署架構進行調整，增加伺服器配置，同時採用叢集的方式來支援網站應用。目前的單節點一旦出現問題，就會導致整個服務都停掉，如果採用叢集的話再加上IHS做動靜分離，起碼從穩定性上能夠得到很大的保證。

這種方式應該是比較好的解決辦法，但是我們一提出來就遭到客戶痛罵。為啥呢？伺服器的裝置採購早就做完了，沒有伺服器用了。因為客戶的預算也是要審批的，而且客戶也不會為了這個再去採購新的伺服器，客戶對於我們以增加裝置來解決問題的辦法也很反感，罵完一頓之後，連舊裝置都不給一臺，要求我們在現有裝置基礎上解決問題，。

沒辦法這個方案就此無疾而終了，誰要我們一開始沒設計好呢，事後要再追加裝置是沒這麼簡單的事情了。

解決方案二：

巧婦難為無米之炊，看來短時間無法解決down機的問題了。只能先找到具體出問題的地方了。再針對性最佳化網站了。整個最佳化過程走了不少彎路，有些地方是改了之後又改回來。

以下是監控和分析處理和最佳化過程：

第1天：白天做壓力，100個時開始監控到洩漏，但之後幾千併發沒未當機！（說明網頁訪問的壓力還能承受住）

第2,3天週六日：經過討論，有人認為首頁的太多的iframe 或導致併發太高而且重複引用JS，影響效能。因此由設計人員檢視程式碼，實現去iframe和採用頁面快取oscache技術改寫首頁。（走了彎路...）

同時考慮啟用IHS進行請求轉發，靜態化檔案處理。

第4天：在前次的修改中，由於作業系統內碼問題和程式需要變化，沒有來及啟用IHS，加上積壓的訪問下載需要，導致今天更為嚴重的當機現象（5次）。

(走了彎路的結果就是離目標越來越遠，情況更加嚴重！)

不得已，晚上先把IHS裝上，以便監控請求日誌。

第5天：上午監控，網站正常，was正常且記憶體幾乎不變化，下載快,netstat監控約1500連結;Http程式20個，每個佔280M記憶體，逐漸佔滿OS記憶體。17點當機。（19點鐘reboot，到21:22分，分析IHS日誌，共有2702個附件下載。預計白天比這要多）(說明網站存在大量的下載，而且很多都是下載工具產生的連線，例如迅雷。這種下載會產生大量連線，並且長期暫用！)

第6天：下午17點前當機（今天1次）。應該是was堆滿。有jc和dump，分析jc有log 寫鎖或等待。發現Downloadservlet（下載的處理程式）有未關閉連線等問題，修改為不用流而直接跳轉到HTTP靜態直接下載。

(說明下載的程式有問題，經過分析，需要將下載的工作交給IHS來處理，走WAS的話容易導致死鎖，執行緒等待。)

第7天：未當機。監控系統記憶體滿，WAS JVM的heap滿，有當機的徵兆。人為重啟。

第8天：白天正常。18點多系統當機崩潰，產生jc和dump。

第8天以後的當機，確定是OSCache元件不穩定，在WAS環境下出現了記憶體洩露，最後去掉OSCache，但頁面速度比較慢，需要5秒才能開啟。專案組最後解決方法是：將首頁靜態化，目錄選單靜態化。

（從彎路上饒了回來）

總結最終的解決辦法：

網站的網頁的壓力基本上還是能承受住，雖然可能首頁人多的是會慢一些，問題主要出在檔案的下載這塊。下載的程式是透過WAS直接處理的，導致大檔案下載長期暫有連線和資料庫連線，最終導致系統崩潰。

解決措施：

1、網站首頁靜態化，所有的選單欄等資料庫訪問量較多的地方也靜態化處理。

2、安裝IHS， 透過IHS轉發請求到 WAS上的網站服務。因為IHS對於長連線的請求會有中斷處理，有些超時沒有響應的請求會自動關閉，這點WAS好像就比較難處理。

3、將檔案下載的工作透過IHS靜態化檔案進行處理。幸好我們的所有附件都是放在檔案伺服器上，可以透過配置靜態化目錄，來實現對這些檔案的訪問，同時遮蔽掉WAS下面的檔案下載程式應用包。

4、調低應用中的日誌級別，因為日誌級別和除錯輸出的大量資料，導致WAS可能會忙於進行檔案IO操作，反應降低，然後迴圈惡性發展，使系統處於假崩潰狀態！

最終網站伺服器的部署環境如下：

作業系統： RHEL 5.5

應用伺服器： WAS 7 單節點+ IHS

WAS引數：

資料來源連線池：200

       JVM堆大小： 256M到1024M

       啟用 servlet 快取記憶體 

       會話最大1000，允許溢位，會話超時2分鐘。 因為網站基本上沒什麼會話資料需要儲存，所以設短一點，避免暫用大量記憶體。

       執行緒池50到100，允許溢位

HIS配置檔案httpd.conf關鍵引數：

LogLevel error (調整日誌級別)

#CustomLog logs/access_log common  (遮蔽該日誌)

Alias /fileStorage       "/nfs/datafile/"  （指定靜態化檔案目錄）

  （調整IHS的最大併發數）

ServerLimit      16

StartServers      5

MinSpareServers   5

MaxSpareServers   15

MaxClients          600

MaxRequestsPerChild  3000

KeepAlive On （調整IHS的請求的最長連線時間以及超時時間，由於網站的特殊性，所以連線不能太長，不然佔用資源不釋放，就會容易導致當機或者無法訪問）

MaxKeepAliveRequests 500

KeepAliveTimeout 5

資料庫：Orcale 11g

整個最佳化到這裡基本上就完了。 下面是一些配置上面的心得，希望對大家有用。

1、分析網站連線問題的指令碼和工具：

1）分析哪種tcp狀態數量異常：

netstat -nat|awk '{print awk $NF}'|sort|uniq -c|sort –n

在網站訪問量壓力較大情況性下，如果發現time_wait、Fin_wait1等較多，考慮修改linux系統etc/sysctl.conf檔案。

可參考文件：

2）將請求80服務的client ip按照連線數排序：

netstat -nat|grep ":80"|awk '{print $5}' |awk -F: '{print $1}' | sort| uniq -c|sort –n

用於查詢惡意連線IP。

3）使用HttpWatch軟體

在需要分析網頁下載效率時使用。避免網站頁面中（特別是首頁）出現較大圖片、JS等物件。透過該軟體可以看到各個URL的訪問時間，便於針對性最佳化。

2、動靜分離的配置：

WAS+ IHS動靜分離的配置在網上查了下，有個幾個方法:

1)        一個比較麻煩的方法就是遮蔽靜態內容透過 WebSphere Application Server 中的 File Serving 功能從 WAR 檔案返回的功能。需要修改一堆配置檔案，然後要重新產生外掛等等。 比較麻煩，而且容易出錯，這裡就不講了。大家有興趣可以參考：

http://space.itpub.net/14789789/viewspace-628556

2)        第二種比較簡單的就是把靜態化的檔案直接放到 IHS 伺服器，透過ＩＨＳ直接處理，不走WAS。本專案就是採用的這種。

3)        第三種就是購買  WebSphere Edge Server（簡稱 Edge Server）產品來實現了。

下面主要講第二種的配置：

前面講到專案中專門有一個下載的程式，處理附件的下載，但是最終產生了問題，從而透過IHS來代替該功能，而直接處理靜態檔案的下載。

處理步驟：

a)        修改： /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin-cfg.xml  檔案，

將其中的：

中的高亮部分刪除，改成如下：

表示，遮蔽所有針對fileStorage目錄訪問的請求，都不會轉發到ＷＡＳ伺服器上，而是直接透過ＩＨＳ伺服器進行處理。

這裡需注意：如果WAS應用中有 /* 的應用這種配置，則該項修改會無效，因為 /* 表示所有的路徑都必須走WAS應用伺服器，就會導致無法配置動靜分離。

b)        修改： /opt/IBM/HTTPServer/conf/ httpd.conf  檔案，在該檔案的最後加上：

Alias /fileStorage       "/nfs/datafile/"

表示，所有針對 fileStorage 目錄訪問的請求，都會透過 IHS伺服器轉發到 伺服器的 /nfs/datafile/ 目錄下去訪問。 而 /nfs/datafile/ 目錄下的檔案就是我們所有的附件、靜態檔案的存放目錄。

大家仔細研究/plugin-cfg.xml 可能會發現，只要是我們在WAS下部署了的應用，都會在這個檔案中出現一個訪問目錄。 如果大家用第一種方式配置動靜分離，可能會發現，這個檔案會變化非常大，裡面只要是涉及到動態需要Java處理的路徑，在這個裡面都會重新生成一個Uri。 例如 *.jsp ，XXservlet 等。

所以，我們有個簡單的方法來實現動靜分離， 那就是直接修改plugin-cfg.xml 這個檔案， 把必須要WAS處理的 路徑都加入到這個檔案中。 然後把靜態的檔案型別以及檔案路徑都剔除出去。 例如 *.jpg , *.js 這種，然後把這些檔案全部放到IHS 的靜態化目錄下。這樣IHS 就會把靜態化的檔案先處理了，然後動態的請求URL再轉發給WAS處理。

比較好的一個設計思路就是，把所有的靜態檔案，例如圖片，JS等，都放到一個統一的目錄下，各個應用中要用的話，就統一引用這個目錄下的檔案，這樣，靜態化的時候，只需要對這個應用目錄進行靜態化，其他的應用配置就基本上不用改了，否則的話你把所有的需要動態處理的路徑都列出來也是非常麻煩的一個事情，萬一列少了一個，就會導致請求處理不了。