(譯) IBM WAS 6.1 Web container problem determination

05-13

聲明

本文為IBM官方WebSphere問題診斷系列文檔翻譯，旨在為自己增加知識和方便國人查看。本翻譯遵循實用原則，原文過於拖沓啰嗦的地方就略過。有興趣的可以繼續閱讀，沒興趣的請路過。歡迎留言吐槽，謝謝。

本文為翻譯plugin問題診斷文檔：redp4045-WebSphere Application Server V6 Web Server Plug-in Problem Determination.pdf，次文檔可以從這裡下載：文檔下載

下面進入正題：

WebSphere Application Server V6.1: Web container problem determination

Web組件的運行時環境叫做Web容器（Web Container）。當用戶無法正常訪問系統時，可能就是Web Container的問題。

對於Web container來說，可能出現的問題有：

用戶無法訪問Web組件
運行Web組件的時候反應不正常
啟動Web組件時報錯
JSP進行編譯的時候有錯
運行Web組件時拋出錯誤或異常
收到以SRVE（Web container）、JSPG（JSP）、JSFG（JSF頁面）開頭的信息

本文教你如何在分散式系統和IBM i5/OS系統上診斷IBM WAS V6.1的Web container的問題。

Web容器介紹

Web容器是運行Web應用的運行時環境，它處理servlet，JSP文件，和其他種類的伺服器端組件。每個應用程序伺服器運行時都有有一個單獨的邏輯Web容器，你可以修改它，但是不能創建或刪除。

Web容器概述

Figure 1圖解了Web容器，以及它在應用伺服器中的位置。

Web容器提供：

Web容器傳輸鏈（transport chains）

Web容器inbound傳輸鏈用來處理請求。它由下列組件組成：用來提供容器和網路之間的鏈接的TCP inbound channel，用來為HTTP 1.0和1.1提供服務的HTTP inbound channel，還有用來把servlet和JSP請求發送到Web容器的Web container channel。

Servlet處理進程

當Web容器處理servlet請求時，Web容器會創建請求對象和響應對象，然後調用servlet的service方法。當時機合適，Web容器也會調用servlet的destroy方法，之後JVM會執行垃圾回收（GC）。

HTML和其他靜態內容的處理進程

當Web容器接受到HTML或其他靜態內容請求時，Web容器inbound傳輸鏈會提供服務。然而，在生產環境下，使用外部Web伺服器並且使用plugin作為介面在大多數情況下是更為合適的選擇。

會話管理

Web容器支持API中定義的javax.servlet.http.HttpSession介面規範。

Web應用程序

Servlet和JSP文件就是所說的Web組件。靜態內容文件（比如HTML頁面，圖片，XML文件）在進行應用封裝創建Web模塊的時候會跟Web組件捆綁在一起。Web模塊是一種遵循指定的格式規範去組織和打包的，可以被單獨拿出來部署和使用的一個單元，它會被打包成Web archive（WAR）文件。J2EE Web模塊符合Java servlet規範。

Web模塊最頂層的目錄是應用程序的document root，也就是放置JSP頁面和靜態Web資源的位置。document root有個名為/WEB-INF/的子目錄，其中放置Web應用部署描述符（web.xml）和Web模塊需要用到的伺服器端的類文件。如Figure 2：

確認Web容器的問題類型

Web容器出問題的時候會給用戶返回很多種類的標識符，比如HTTP 404錯誤，500錯誤，或者頁面上顯示不正確的信息，例如由HTTP錯誤引發的一個錯誤頁面，或者頁面上顯示的內容不正確，或者頁面顯示不完整。

當發生HTTP錯誤的時候，Web瀏覽器會顯示一個包含錯誤碼的錯誤頁面。如果在Web模塊中自定義了錯誤頁面，那你需要檢查Web伺服器日誌以確定真實的HTTP錯誤碼是什麼，因為那些錯誤碼很可能並不會顯示在你自定的頁面上。

收集分析Web伺服器日誌

從Web伺服器上手機access日誌，然後搜索日誌中的404或500錯誤。下面是一些IHS（IBM HTTP Server）的例子：

access.log日誌：

127.0.0.1 - - [28/Mar/2007:19:52:31 -0400] "GET url HTTP/1.1" 404 304

127.0.0.1 - - [28/Mar/2007:20:03:48 -0400] "GET url HTTP/1.1"500 5348

重點注意一下跟出問題的URL相關的錯誤碼。

如果正常情況下從Web伺服器應該可以訪問某個URL（這個請求需要到達應用伺服器進行處理），然後出現了類似這樣的信息：從xxx地方無法找到指定的文件。這時需要查看error日誌，找一下文件無法訪問的日誌：

- [Wed Mar 28 19:52:31 2007] [error] [client 127.0.0.1] File does not exist: file_location

HTTP 404錯誤

HTTP 404錯誤有多重成因，下面是一些例子：

外部因素，比如Web伺服器有問題
配置問題，比如plugin或者virtual host配置不正確
運行時環境的問題，比如應用或應用伺服器沒有啟動
用戶或應用問題，比如輸錯了URL

驗證系統的完整性

如果用戶得到404錯誤並且你比較了解出問題的應用程序，那麼首先應該檢查一下系統的完整性，需要檢查的組件包括：

Web伺服器
應用伺服器
應用程序

如果這些組件都工作正常，或者你不是很清楚哪台應用服務或哪個應用受到了影響，請繼續往下看。

確認Web伺服器是否正常響應

如何檢查？取決於Web伺服器的種類和它的配置。

如果是IHS，簡捷的方法是從瀏覽器訪問對應的URL：http://server_name。如果可以看到歡迎頁面，說明Web伺服器可以工作。如果無法顯示，出現了「page cannot be displayed」這類的信息，說明問題可能處在Web伺服器。

解決Web伺服器問題

參閱另一篇文章：http://blog.dellyqiao.com/middleware/translation/2015/04/11/web-server-plug-in-/

確認應用伺服器是否啟動

確認應用程序是否部署在了伺服器或集群上
確認應用伺服器的狀態
如果沒啟動，嘗試啟動一下

如果你不知道這些步驟怎麼做，查看這裡：「Managing servers and applications」

確認應用程序是否啟動

從管理控制台查看，Applications → Enterprise Applications。

如果應用狀態是啟動，說明應用在運行，但是它無法檢測應用在啟動過程中是否有任何錯誤。

收集診斷相關的數據

如果你無法看到錯誤的類型或者無法得知出問題的URL信息，你需要手機以下數據：

用戶瀏覽器顯示的錯誤以及失敗的URL
應用伺服器的日誌（如果應用部署在集群上，需要手機每台集群成員的日誌）
Web伺服器access和error日誌
TRCTCPAPP trace（i5/OS）

i5/OS系統上的HTTP伺服器是集成到系統里的，還有一種額外的跟蹤日誌可以提供有用的信息。查看這裡：「Trace Web server requests to WebSphere (i5/OS)」

分析數據

從診斷數據里能得到的信息主要是這兩種：

出問題的URL
問題出在哪兒（Web伺服器，plugin，應用伺服器）

可以以下面的順序做問題診斷：

Web瀏覽器顯示的錯誤信息

這些信息可以幫助你得知問題的類型和出問題的URL。這些信息有可能已經足夠解決你的問題。

SystemOut日誌

如果是Web容器出問題，SystemOut日誌是最能提供有用信息的文件。日誌中的信息也有可能會顯示到瀏覽器中，取決於應用程序如何處理錯誤。如果這個JVM日誌中沒有任何錯誤信息，多數可能是因為請求沒有到達應用伺服器。

TRCTCPAPP trace（只針對i5/OS系統）

這個trace可以幫你i安測問題是否出在plugin上。

Web伺服器日誌

如果沒有發現其他的錯誤跡象，查看一下Web伺服器日誌，卡伊找到錯誤的類型（404、500）和錯問題的URL。

分析瀏覽器輸出的錯誤信息

一般來說，404錯誤會伴隨有一些描述性的問題說明信息一起出現，如果用戶報告的問題屬於下面列表中的任何一條，我們就可以直接定位問題原因：

The page cannot be displayed
JSP error or JSF error
Failed to find resource
File not found
WebGroup/virtual host not defined

The page cannot be displayed or found

Figure 3 展示了一個典型的例子。這種錯誤頁面的顯示效果是多種多樣的，取決於瀏覽器。比如，有的瀏覽器會顯示「The page cannot be found.」。

這種情況的原因可能是：輸入的URL錯誤，也可能是需要訪問頁面的組件不可用（比如Web伺服器，應用伺服器）。特別注意發生錯誤時候瀏覽器地址欄上的URL。

如果訪問出錯的是JSP或servlet，查看「Page cannot be displayed or JSP/JSF error」。

JSP和JSF錯誤

JSP和JSF錯誤通常伴隨著從應用伺服器發過來的跟問題檢測相關的信息，Figure 4展示的就是一個帶著"JSPG0036E: Failed to find resource」信息的頁面：

Figure 5展示了一個帶有"SRVE0190E: File not found」信息的頁面：

出現這種錯誤信息的原因可能是URL錯誤，或者在server上的這個頁面不可用，或者是plugin配置的問題。特別注意出錯的URL。更多信息查看「Page cannot be displayed or JSP/JSF error」。

WebGroup/Virtual Host has not been defined

這個錯誤很有可能是因為virtual host配置錯誤，或者輸入的URL不正確。一般錯誤信息會是這樣：

SRVE0255E: WebGroup/Virtual Host has not been defined (V6.1) ??
SRVE0017W: WebGroup/Virtual Host has not been defined (V6.0)

如下圖：

記住出問題的URL，然後查看這個連接「WebGroup/virtual host not defined」。

分析SystemOut日誌

你需要查找這些關鍵欄位：

Web容器信息：SRVExxxxE or SRVExxxxW
JSP信息：JSPGxxxxE or JSPGxxxxW
JSF信息：JSFGxxxxE or JSFGxxxxW
跟應用程序啟動相關的錯誤信息

檢查應用程序是否成功啟動

Example 1中的信息是一個Web模塊正常啟動的日誌信息。

Example 1 Normal application startup messages

ApplicationMg A WSVR0200I: Starting application: [application_name] WebContainer A SRVE0161I: IBM WebSphere Application Server - Web Container.Copyright IBM Corp. 1998-2004WebContainer A SRVE0162I: Servlet Specification Level: 2.4?????WebContainer A SRVE0163I: Supported JSP Specification Level: 2.0WebGroup A SRVE0169I: Loading Web Module: [web_module_name] ApplicationMg A WSVR0221I: Application started: [application_name]

如果應用啟動時出現了錯誤或警告信息，你需要從應用程序方面檢測問題的原因。

Web group / Virtual host 錯誤

如果出現了下面的錯誤，可能是virtual host配置有問題

SRVE0255E: A WebGroup/Virtual Host to handle url has not been defined. (V6.1)
SRVE0017W: A WebGroup/Virtual Host to handle url has not been defined. (V6.0)

查看這個連接獲得更多信息：「WebGroup/virtual host not defined」

其他錯誤信息

有JSPG，JSFG，或者SRVE前綴並且包含出錯的URL的錯誤信息，點擊此鏈接獲取檢查方法：「Page cannot be displayed or JSP/JSF error」。

如果沒有找到任何錯誤，查看後面的「Web伺服器日誌分析」章節。

Web伺服器日誌分析

嘗試從Web伺服器日誌中查找下面的標誌符並且分析它們。

在access日誌中查找404狀態嗎

NCSA格式的日誌如下：

Remote_host- - date_time "request" status_code bytes

對於404錯誤來說：

從status_code的位置查找「404」
著重關注remote_host地址，date_time時間戳，以及請求的URL

在error日誌中查找錯誤

Error日誌會像下面的例子：

[date_time] [error] [client Remote_host] error_message

對於error日誌來說：

查找「error」
通過remote_host地址和date_time時間戳把對應的access日誌和error日誌關聯起來
注意error_message的具體內容

評估access日誌本文主要根據IBM紅皮書的介紹和自己的理解，做一些性能調優的總結。

應用程序的結構，基礎設施，和這個系統需要承受的負載量是影響到性能參數配置的三個因素。不可能有任何一個固定的值是適用於所有系統的。我們需要系統容納能力的規劃，壓力測試，收集信息，最後分析結果來確定對我們自己的系統來說最佳的配置。

要進行性能調優，我們需要有一套跟自己的生產環境環境相同的性能測試環境。為了讓測試結果真的有意義，我們要確保測試環境中的軟體和硬體跟生產環境上的完全相同。

為了讓我們的測試成功，我們需要生成符合以下特徵的負載：

可計量的：使用可以量化的計量單位，比如吞吐量和響應時間。
可重現的：確保多次同樣的測試可以重現同樣的結果。每次只更改一個參數，然後其他條件不變，這樣就可以知道那個參數對系統真實的影響。
靜態的：要確定是否一樣的測試不論執行多久，都能得到一樣的效果。
典型性：確保生成的負載可以真實地代表正常操作一個系統的壓力。

要想確定性能的目標，首先我們必須清楚地理解我們系統的架構和需求。查看架構文檔，用例圖，以及功能性和非功能性的各種需求，從而確定對自己的系統來說，性能好的標準是什麼。

確定一個好壞性能的標準。沒有一個標準或目標，我們無法確定性能調整是否成功。要避免使用那些非指向性的標準，比如儘可能地調試為性能「最好」的狀態。時刻記住如果沒有一個標準線，性能測試可能無窮無盡，因為每次測試都有可能發現一個新的瓶頸，不同的瓶頸又有不同的解決方案，這樣的話到最後我們無法確定我們的性能調試到底是成功了還是失敗了。

不要嘗試在有真實負載的生產環境上做性能調試，這麼做的話，伺服器有很大幾率會做資源回收以使新的參數生肖，這些回收進程可能引發宕機時間。

使用隊列類推法去調試WebSphere資源池

WAS的功能非常類似於一個由互通的代表各種各樣不同資源的隊列組成的隊列網路。這些資源池包括網路，Web伺服器，Web容器，EJB容器，ORB（Object Request Broker），數據源，還可能會有連接到自定義的後端系統的連接管理器。每種資源都代表著等待使用那些資源的一個請求的隊列，這些隊列都是容易受負載影響的資源，也就是說，平均響應速度取決於客戶機請求的數量。這樣的話，性能調優實際上就是對這些隊列的調優。

舉例來說，某個應用程序包含servlet和需要訪問資料庫的EJB beans。每個部分都被放置在了適當的WebSphere組件上（例如servlet在Web容器里），在確定的時間段內，每個組件可以處理確定的數量的請求。

客戶機的請求會通過Web伺服器，穿過WebSphere的幾個組件之後WebSphere組件會給客戶機提供響應。下面圖解了這個應用程序通過WebSphere組件處理客戶請求的路徑，我們把這個路徑類比成一些連接在一起的互通的管道。

圖中管道的寬度代表了在給定的時間裡可以處理的請求數量。管道的長度代表了從收到請求到提供響應需要的處理事件。

上圖展示了在一個確定的時間內，一台Web伺服器可以處理50個請求，一個Web容器可以處理18個請求，這就意味著在最大負載的情況下，請求會在Web伺服器上排隊以等待空閑的Web容器。EJB容器可以處理9個請求，因此一半的Web容器的請求需要排隊等待可用的ORB線程池。而資料庫看起來有足夠的處理能力，因此EJB容器里的請求不需要等待資料庫連接。

假設我們的WAS系統中有足夠的CPU和內存資源，這時，我們可以增加ORB資源池的大小來最大化地利用資料庫連接。由於Web伺服器在一個確定的時間內可以處理50個請求，我們也可以增加Web容器的線程池來獲得更多的Web容器線程從而跟ORB的增長相匹配。

然而，如何確定線程和資料庫連接的最大值呢？如果我們的系統採用隊列處理的方式，要想獲得最佳的性能，我們到底應該從數據層開始調整呢還是應該從客戶端開始調整？下面的章節提供了答案。

Upstream queuing (上游隊列）

資源池調優的黃金法則是：盡量減少在WAS隊列中等待的請求數，根據Web伺服器前等待的資源來調節資源池。這樣的配置使得只有準備好被處理的那些請求能夠進入相應的隊列。想要達到這種配置，需要讓上游的隊列（靠近客戶端）配置得稍微大一些，二下游的隊列（遠離客戶端的）要逐漸的變小。這樣的方式叫做「Upstream queuing」。

下圖13-2展示了這種配置。當200個客戶請求到達Web伺服器時，125個請求依然在網路中等待，因為Web伺服器設置為只能同時處理75個客戶請求。當這75個請求從Web伺服器傳送到Web容器的時候，25個請求被留在Web伺服器中等待，50個請求進入到Web容器中被處理。當25個用戶請求到達最終的目的地——資料庫伺服器時，這個處理的過程才會出現進展。由於在每個節點的上游都有一些請求等待進入被處理，所以這個系統中的每個組件都沒有處於閑置狀態等待請求進入。大量的請求在WAS之外的網路中進行等待，這樣的配置增強了系統的穩定性，因為沒有任何一個組件是過載的。

由於我們的系統不可能有無限的物理資源，所以不要使用等體積的隊列。如果你有無限的資源，你可以調整你的系統使得每個Web伺服器的請求都能得到一個Web容器的線程去處理，每個線程都能得到可用的資料庫連接。然而在現實世界中，這樣的配置是不可能出現的。

另一個精確調節資源池的重要法則是必須對我們的基礎設施、應用程序架構和需求有一個清晰的認識。不同的系統會有不一樣的訪問和使用的方式。

比如說，在多數情況下，只有少部分的請求需要不斷向下通過各個隊列進行處理。然而，在一個靜態頁面居多的網站，大量的請求都被填充到Web伺服器，不必進入Web容器進行處理。在這種情況下，Web伺服器隊列可以明顯地大於Web容器隊列。在上個例子中，Web伺服器隊列設置為75，而不是接近應用程序的最大並發數。當不同的組件處理請求的時間不同時，我們也需要做一下累死的調整。當靜態內容的比重減少時，Web伺服器隊列跟和應用伺服器隊列之間的巨大的空隙將有可能造成站點整體性能的下降。所以說，在進行任何性能調優之前，一定要理解基礎設施、應用程序架構和需求。

另一個例子，在一個應用程序中，90%的時間都會用來處理複雜的servlet，10%的時間會用來進行快速的JDBC查詢，這個10%是一個平均值，servlet可能會在任何時候訪問數據連接。這時，資料庫連接池就可以明顯小雨Web容器的隊列。反過來說，如果處理servlet的大部分時間都花費在複雜的資料庫查詢上了，可以考慮同時增加Web容器線程池和數據連接池的數量。永遠記得監控WAS伺服器和資料庫伺服器的CPU和內存使用率，確保伺服器沒有過載。

下面的章節我們介紹如何調整每個資源池，由最下游的資源池開始，向上介紹。

數據源調試

調整數據源隊列時，要考慮下面的設定：

連接池的大小
Prepared Statement Cache size

連接池大小

訪問任何資料庫的時候，資料庫連接的初始化都是一個非常昂貴的操作。WAS提供了連接池和連接重用的功能。連接池使應用程序和使用資料庫的企業Bean可以進行直接的JDBC調用。

IBM Tivoli Performance Viewr可以幫助我們確定連接池的最大值。模擬正常情況下的客戶訪問量，使用固定的迭代測試次數，使用標準的配置。觀察JDBC Connection Pool模塊下的Pool Size，Percent Used，和Concurrent Waiters counters這些項目。最合適的數值應該是比監控到的數值稍大一點（The optimal value for the pool size is the value that reduces the values for these monitored counters.個人理解，意思就是說最合適的值就是一個可以減掉監控到的那些數值的值，也就是說要稍大一點）如果Percent Used使用的百分比的數值始終很低，請考慮減少連接池中的連接數。