WebSphere Application Server 常見問題及解答：故障診斷

CloudSpace發表於2008-07-11
WebAPPServer
1. 應用伺服器當機後，為了方便分析問題，需要收集哪些日誌？

答：
當應用伺服器發生掛起、或者發生out-of-menmory的現象時，為了更好的全面分析問題，則需要收集一定的日誌資訊，一般情況下我們需要收集以下這些日誌：
  • 如果可能在問題重新出現之前開啟垃圾回收開關，收集垃圾回收日誌一般儲存在native_stderr.log或者native_stdout.log。
  • 收集Web server伺服器，外掛Plug-in（plugin-cfg.xml and http_plugin.log）的日誌及配置檔案。以及應用伺服器（install_root/profiles/profile_name/logs/server_name）下所有的日誌。
  • 在install_root/profiles/profile_name/目錄下的JavaCore檔案和Heapdump檔案，如果沒有這些檔案，可以在伺服器沒有響應的時候，執行命令來生成這些檔案，對於IBM JDK中可以執行kill -3 PID_Java_jvm，然後每隔兩分鐘，重複執行該命令，至少3次，通過該命令生成的JavaCore檔案會在install_root/ profiles目錄下。
  • FFDC目錄下的日誌，install_root/profiles/profile_name/logs/ffdc。
  • 如果應用程式具有自身的日誌檔案，也應收集對應的日誌檔案。
2. 如何開啟詳細垃圾回收的開關？

答：
如果您的應用程式頻繁出現記憶體溢位（out-of-memory）的錯誤現象，那麼為了找出問題的所在，我們必須瞭解記憶體的分配情況和使用情況，那麼這時候我們就需要詳細垃圾回收的資訊和日誌，為了得到這些資訊，我們必須開啟詳細垃圾回收的開關。開啟的步驟如下：在管理控制檯中點選伺服器 > 應用伺服器 > server1（或者是您自己定義伺服器名） > JAVA和程式管理 > 程式定義 > Java虛擬機器 > 選中詳細垃圾回收選項，重啟應用伺服器，即可生效。開啟垃圾回收開關後，關於記憶體的使用情況的日誌會儲存到相應的日誌目錄中的native_stdout.log檔案中，並且可以通過分析該檔案中的資訊快速的找到產生問題的根源。
3. WAS 故障診斷的常用工具有哪些？

答：
故障診斷是查詢併除去問題的起因的過程。一旦您發現 WebSphere 執行環境有問題，故障診斷過程就開始。WebSphere 的基本故障診斷策略包括：
(1). 記錄症狀
根據您的應用程式、伺服器或是工具中出現的問題的型別，您可能接收到表明出現問題的訊息。通過記錄每條訊息的詳細資訊，您就會對定位問題的所在瞭解更多。
(2). 重新建立問題
如果您一直有可重複的測試用例，則您可以很方便地確定哪些解決方案是必需的。
(3). 除去可能的起因
通過排除那些不是導致問題的元件以縮小問題的範圍，您可以使問題簡單化，並且避免浪費時間。
(4). 使用診斷工具
WebSphere Application Server 提供了一些幫助管理員以及開發者進行故障診斷的工具和資源，合理的利用這些工具和資源，當 WebSphere Application Server 出現故障的時候，可以幫助我們準確的定位問題的所在。
以下介紹瞭如何收集故障診斷的資源：
確定 WebSphere 產品安裝資訊： 可以執行 versionInfo 命令。
確定 JDK 的版本資訊： 通過從命令列執行 java -fullversion
確定 Web 伺服器的版本資訊： 檢查 Windows 平臺上的IBM HTTP Server的版本資訊，可以執行 apache.exe -v。檢查 Unxi 和 Linux 平臺上的 IBM HTTP Server 的版本資訊，可以執行 httpd -v。

管理控制檯訊息： 管理控制檯提供了一些重要的關於 WAS 執行時事件以及配置問題的資訊。在管理控制檯中的故障診斷中顯示了執行狀態的訊息，您可以檢視配置問題的訊息以及執行時訊息。通常執行時事件的錯誤資訊頁包含了重要資訊。

使用日誌檔案： WebSphere Application Server 可以將系統訊息寫到幾個通用日誌中，包括 JVM 日誌、程式日誌和 IBM 服務日誌。

使用跟蹤： 跟蹤檔案顯示 WebSphere Application Server 基本類呼叫的方法的時間和順序，您可使用這些檔案來查明故障。
WebSphere Application Server 中的故障診斷工具包括：日誌分析器、收集器工具、首個故障資料捕捉（First Failure Data Capture,FFDC）、IBM Support Assistant 等。

日誌分析器： Log Analyzer是一個圖形化的工具，用來幫助使用者檢視、分析日誌。

收集器工具： 收集器工具收集 WebSphere Application Server 安裝資訊，並將它打包後放在 Java 歸檔（JAR）檔案中,您可將該檔案傳送給 IBM 客戶支援人員以輔助確定和分析您的問題。JAR 檔案的資訊包括日誌、屬性檔案、配置檔案、作業系統和 Java 資料以及存在的每個必備軟體及其級別。

首個故障資料捕捉（First Failure Data Capture,FFDC）： 首個故障資料捕捉工具儲存由處理故障生成的資訊，並將控制權返回受影響的引擎。捕捉到的資料儲存在日誌檔案中，以供分析問題時使用。

IBM Support Assistant： IBM Support Assistant 是一個工具，它可幫助您使用 WebSphere Application Server 管理控制檯中的各種 IBM Support 資源。

有關具體如何使用這些工具的更多資源，請參閱 developerWorks 中國站點的文章《WebSphere Application Server 故障診斷的資源以及相關工具的介紹》與《權威支援: 用於實際故障診斷的功能和工具》。
 
4.問題：我應該使用資料庫還是使用記憶體到記憶體複製來進行會話故障轉移？

答：
資料庫持久化和記憶體到記憶體複製之間的效能差異並不大。這是因為 95% 的複製或持久化會話開銷是在會話物件的序列化/反序列化中產生的——不論會話儲存在哪裡，這種開銷都必定會產生。另外，當會話物件的大小增加時，效能就會下降——再強調一遍，兩種會話分佈方式的效能大致相同。

在 IBM WebSphere: Deployment and Advanced Configuration 中，我這樣寫道：

相反，決定選擇哪種技術將部分基於這兩種技術之間的差異： 通過使用資料庫，您實際上持久化了資料（儲存到磁碟中），這樣高可用性的資料庫伺服器就可以在級聯故障中倖免於難，而將應用伺服器用作會話儲存和複製器則無法達到此目的。 對於“黃金標準”（兩個相同的單元/域），高可用性的資料庫完全可以確保兩個域之間的會話故障轉移，而對於記憶體到記憶體複製，兩個單元只能有一個通用複製器；因此，它就變為單點故障 (SPOF)。 因此，對於必須進行交叉單元會話故障轉移的配置，只能選擇高可用性資料庫來消除 SPOF。請注意，此時跨單元共享會話是得到支援的，但不建議這樣做，因為在單元間共享狀態將使得在兩個單元中獨立升級元件（應用程式和 WAS）異常困難。最後，您的決定要基於您最喜歡使用的技術以及哪種技術可以提供所需的服務質量來滿足可用性要求。

在此，我想談一下我的另一個觀點。利用記憶體到記憶體複製，您可以儲存的會話資訊的數量受應用伺服器的 JVM 堆大小的限制。即使在 WebSphere Application Server V6.01 中支援 64 位的 JVM，最大應用伺服器堆大小也大大小於資料庫伺服器（用作會話儲存）上可用的磁碟空間數量。因此，儘管我知道在許多組織中，使用記憶體到記憶體複製對避免系統管理員和資料庫管理員之間的角色和職責衝突更有利，但我仍持這樣一種觀點，即資料庫持久化仍是最佳選擇。

本答案，來自 IBM WebSphere 開發者技術期刊中的來自 Tom Alcott 的評論:欲言又止的 WebSphere Application Server 的相關問題

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-375007/，如需轉載，請註明出處，否則將追究法律責任。

相關文章