WAS 常見問題及解答(六)

性能

1. WAS 的重要優化參數有哪些？

2. 性能調優的基本步驟是怎樣的？

3. 如何合理的使用緩存機制？

4. WAS 性能差的幾種表現和解決方法？

5. 我應該怎樣去判斷應用程式伺服器的性能是否滿足要求，都有哪些名額？

6. 系統中産生大對象對性能的影響怎洋？

7. 如何解決記憶體洩漏問題？

8. 如何解決系統當機問題？

9. WAS 運作在什麼平台上性能最好？是Intel、UNIX、pSeries/AIX、Sun/Solaris，還是 zSeries/zOS？

10. 運作應用程式所需 CPU 的最小數量和最大數量是多少？

1. WAS 的重要優化參數有哪些？

答：

在着手進行應用程式伺服器的優化之前，首先進行應用程式和作業系統的優化是一個更好的選擇。尤其是應用程式的優化，通過對應用程式中影響性能的部分進行重新的設計和調整，往往能夠帶來比單純的參數調優更為巨大的性能提升。對于一般的J2EE應用程式而言，WAS中最重要的優化參數包括針對JVM、Web Container和Data Source等的。

· JVM

Heapsize（-Xms和-Xmx）：heapsize的大小依賴于系統平台和具體的應用等多種因素。最大heapsize需要小于機器的實體記憶體，一般來說，設定最大heapsize為512m是一個常見的起點。同時，在生産環境中，最好将Xms設定為小于Xmx的值。

GC（Garbage Collection）：一般來說，良好的GC狀态需要保證相鄰兩次垃圾回收的平均間隔時間應當是單次垃圾回收所需時間的至少5-6倍。GC的調優是通過在模拟壓力的情況下不斷調整最大最小heapsize來實作的。

Heap Fragmentation：heap碎片的問題在JVM中存在大對象的情況下尤為突出。減少碎片的方法包括調整pCluster（-Xp）和kCluster（-Xk）參數。更多的JVM調優參數内容，參考JDK diagnostic Guide。

以及WAS V6.1資訊中心的相關内容：

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunejvm_v61.html

· Web Container

對Web Container的調優是通過對Web Container傳輸鍊中各個通道（TCP、HTTP、WebContainer）的參數調整進行的。這些參數包括諸如ThreadPool的最大最小值，buffer大小，timeout時間的大小，keep-alive的值等等。各個參數的含義及具體調整方法參見WAS V6.1資訊中心：

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunechain.html

· Data Source

對Data Source的優化包括兩個方面。一是JDBC Driver的選取，盡可能應使用Type 4的JDBC driver，這種driver是純java的，适用于client/server模式，并提供比type2和legacy/CLI的driver更好的性能。另一方面是Database連接配接池的參數設定，主要包括最大和最小連接配接以及timeout的設定。具體的設定于應用程式的特性和并發使用者量相關，一般來說，可設定最小連接配接為1且最大連接配接為30，作為一個繼續調優的起點。除了JVM，Web Container和Data Source之外，WAS的性能調優還包括很多其他方面的内容，如JMS、EJB、Session、Dynamic Cache等等。關于性能優化的更多内容，可參見WAS V6.1資訊中心：

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc6toptuning.html

另外，WAS 提供了若幹工具，可以用于幫助衡量其性能。WAS 中免費提供的 Tivoli® Performance Viewer（TPV）允許客戶對關鍵資源（如 JVM、Web 容器和 EJB 容器以及遠端連接配接池）進行監視。這款工具使用非常友善，可以用于确定應用程式使用可用資源的方式，還可以提供針對行為不正常的遠端資源的資訊。例如，如果資料庫連接配接池顯示為了獲得連接配接進行了多次嘗試，則可能表示遠端資料過載，或者需要優化資料庫，或者需要向不夠大的池中添加更多的連接配接。與此類似， WAS還提供了 Runtime Performance Advisor 功能，可以就系統中的潛在優化問題向管理者提供回報。

WAS Information Center （http://www.ibm.com/software/webservers/appserv/was/library/）包含了一個優化參數清單，還包括一個優化參數“熱點清單”，其中描述最常用的經過調整的參數。這是一份不錯的參考資料，有助于您了解在該産品内調整記憶體和資源的基本知識。其他的不錯的參考資料包括 IBM® 紅皮書，如 WebSphere Application Server V6 Scalability and Performance Handbook》。

2. 性能調優的基本步驟是怎樣的？

答：

部署在WAS上的J2EE應用程式，其性能是由多個因素決定的。例如網絡、資料庫、記憶體配置設定、WAS伺服器的配置以及應用程式的設計。對于一個标準的J2EE應用，一個請求到來時，往往需要經過多次轉發：網絡 > Web伺服器Web容器 > EJB容器 > 資料庫。而每一次轉發，都可能造成請求處理的瓶頸，使得應用程式整體性能下降。如果我們把每一次轉發的待處理資源都看成一個隊列，如圖3：

圖3 待處理資源隊列

對于WAS調優，要記住的一個基本原則就是，使得在隊列中等待的請求的數量最小化。在實踐中我們發現，為了達到這個目的，最有效的配置方式就是使得隊列成為一個“漏鬥”。也就是說，越靠近用戶端的隊列，其容量越大，而後面的隊列，其容量要略小于或等于前面的隊列。按照這個原則，調優的基本步驟如下：

· 設定的是Web Server的最大并發使用者：

o 這個設定是在conf/httpd.conf這個檔案裡面配置的。在Unix系統中，對應的屬性是MaxClient；在Windows系統中，對應的屬性是ThreadsPerChild。

· 設定Web Container的最大、最小并發使用者：

o 在管理控制台中點選應用程式伺服器 > server1 > 線程池 >WebContainer，根據觀察的性能情況和應用情況輸入合适的最小、最大程序數。

· 對象請求代理（ORB）的線程池大小：

o 在管理控制台中點選應用程式伺服器 > server1 > ORB 服務 > 線程池，根據觀察的性能情況和應用情況輸入合适的最小、最大程序數。

· 設定資料庫的連接配接池屬性：

o JDBC 提供者 >資料庫JDBC驅動名稱 > 資料源 > 資料源名稱> 連接配接池，根據觀察的性能情況和應用情況輸入合适的最小、最大連接配接數。

· JVM堆參數設定的性能調優：

o 應用程式伺服器 > server1 > 程序定義 > Java 虛拟機，根據硬體實體記憶體和應用情況輸入合适的初始堆大小、最大堆大小。

· ORB參數調用方式的性能調優：

o 應用程式伺服器 > server1 > ORB 服務>選中按引用傳遞。

· 關閉動态加載開關：

o 企業應用程式 > 應用名稱 > 關閉啟動類重新裝入開關。

o 關閉會話序列化，應用程式伺服器 > server1 > 會話管理 > 分布式環境設定 > 分布式會話選擇無即可。

這個調優的步驟隻是涉及了利用WAS伺服器參數的調整來優化應用程式的性能，實際上性能的好壞很大部分是取決于應用的設計。好的性能源自好的代碼設計。一般說來，性能調優大概可以提高10％－40％效率，而糟糕的代碼設計卻會使得性能幾倍的下降。

3. 如何合理的使用緩存機制？

答：

WAS 中可以用很多種手段實作緩存。其中最常見的一種，就是在應用中使用開發的手段緩存一些中間結果。但這種緩存是一把雙刃劍。用好了可以很好地提高性能，如果掌握不好，使用過度了，則會對底層 JVM 的 Heap 造成很大的威脅。一般 JVM Heap 出現OutOfMemery（記憶體洩漏）的問題，都是應用中直接或者間接的緩存技術濫用的後果。是以緩存技術拿捏得當非常重要，也比較不容易。 下面主要談談 WAS 産品本身提供的緩存功能。

WAS 提供動态緩存機制，可以對 Web 指令、 Servlet 輸出和 JavaServer Pages（JSP）檔案進行高速緩存，進而提高應用程式的性能。動态高速緩存服務在應用伺服器 JVM 中工作，攔截對可高速緩存對象的調用。例如，它通過 servlet 的 service 方法或指令執行方法攔截調用，以及将對象的輸出存儲到高速緩存，或者對來自于動态高速緩存的對象内容進行處理。

在 WAS 中可以通過配置實作常用的高速緩存對象、功能和子產品有：

· Servlet 高速緩存

· Portlet 片段高速緩存

· Edge Side Include 高速緩存

· Web 指令高速緩存

· Web Service 高速緩存

· Web Service 客戶機高速緩存

關于WAS的緩存功能，詳細資訊請參見：

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/welc6tech_dyn.html

對于WAS中的緩存機制，和應用開發中的緩存類似，也要掌握好緩存的“度”，避免濫用，即題目中問的“如何合理的使用”？原則有如下幾點：

1. 不是緩存用得越多越好。隻要是 WAS 中提供了緩存機制的環節，統統都用上。這是錯誤的。

對于這一原則，有一個非常簡單的方法可以确定是否采用緩存，采用哪些緩存技術：如果實作緩存本身相對于您的拓撲結構或者您所掌握的技術來說，顯得非常的複雜，那麼完全可以不用。舉例來說，雖然 Edge Component 中提供了很好的緩存技術，但您的生産環境中，原本就沒有考慮 Edge Component，現在為了緩存而緩存，非要把 Edge Component 加進去，使得拓撲偏離了原先的設計，變得更複雜化，就很沒有必要了。

2. 确認您想緩存的對象是否真的需要緩存。這一點事先比較難以判斷。因為生産環境真實的使用情況是千變萬化的。最佳的方法就是在真實環境中對緩存進行監控，檢視被緩存對象的命中率。如果某些緩存環節使用率極低，或者某個對象命中緩存的機率非常小，則完全可以取消這樣的緩存。對于使用率高的緩存，可以在記憶體使用比較平穩的前提下适當增大力度。 關于緩存監控的方法，請參考WAS的InfoCenter，利用高速緩存螢幕器對動态高速緩存進行适當調整。網址如下：

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/cdyn_cachemonitor.html

4. WAS 性能差的幾種表現和解決方法？

答：

系統性能差一般的情況下有以下表現：

1. CPU使用不高， 使用者感覺交易響應時間很長。

2. CPU使用很高，使用者感覺交易響應時間很長。對于第一種情況，可以斷定是由于系統的某一小部分造成了瓶頸，導緻了所有的請求都在等待。簡單舉例來說，線程池的數量開的太小，導緻所有的請求都在排隊等待進入線程池，因為沒有可用的線程使用，是以這個交易請求一直在排隊，導緻交易響應時間很長。如果資料庫連接配接池開的太小，也會有同樣的表現。

對于第二種情況，比較複雜。可能的根源之一是硬體資源不夠。根源之二是應用系統中産生了多個大對象。根源之三是程式算法有問題。解決思路如下：用性能分析器，如RAD或JProfiler, 對運作環境進行分析，分析哪個類甚至于哪個函數消耗了這麼多的CPU，并找到相應的解決方案。

有關 WebSphere 性能的更多資源，請參閱 developerWorks 中國站點的文章《專家訪談：Stacy Joines 和 Gary Hunt 談 WebSphere 性能》。

5. 我應該怎樣去判斷應用程式伺服器的性能是否滿足要求，都有哪些名額？

答：

在遇到性能問題時，嘗試使用Tivoli Performance Viewer，并一一察看如下最重要的10個監視項目：

· Servlets 和Enterprise JavaBeans

1. 平均響應時間

2. 請求數（事務）

3. 活的HTTP Session數

· 線程池

4. web 伺服器線程

5. web容器和EJB容器線程池

· 資料源

6. 資料源連接配接池大小

· Java 虛拟機

7. JVM記憶體，垃圾收集統計

· Web，應用程式，和資料庫伺服器上的系統資源

8. CPU使用率

9. 磁盤和網絡I/O

10. Paging活動

同時，可配合使用Tivoli Performance Advisor，它們可幫助您調整您的系統，對設定不足給出建議。

有關 WebSphere 調優工具的更多資源，請通路 developerWorks 中國站點文章和教程：

· 《Ruth Willenborg 關于性能工具的提示：選擇 WebSphere 性能工具》

· 《性能監測，診斷和優化》

· 《WebSphere應用伺服器記憶體洩漏探測與診斷工具選擇最佳實踐》

6. 系統中産生大對象對性能的影響怎樣？

答：

我們經常遇到如下的例子，如果一個報表系統運作在WAS裡，使用者經常抱怨系統的響應時間太長，反應太慢的情況。問題的根本原因是報表系統會産生一些大對象，而這個大對象的數值如果超過2M, JVM一定要在有限的空間裡為對象找到連續的空間。如果JVM為這個對象找不到連續的空間，就會對整個記憶體空間進行整理，如果大對象比較多，由于JVM對記憶體空間的頻繁整理會對系統的性能有着急劇的影響。造成系統的響應時間非常慢，是以應用程式應盡量避免産生大對象，或者用一個連結清單的結構來表達大對象，本質上把一個大對象拆成幾個可以聯接的小對象，讓JVM可以很容易的配置設定記憶體空間。

7. 如何解決記憶體洩漏問題？

答：

由于系統的複雜性，不可能通過程式來确定記憶體洩漏的根源，因為記憶體洩漏的根源可以是來源于自己寫的應用，開放源碼的元件，JDBC元件，甚至可以懷疑WAS本身也能造成記憶體洩漏。但也有一個解決思路，就是在應用程式已經發生記憶體洩漏時，把目前的記憶體中的所有對象做一個快照。從這些所有的對象中做分析，找到懷疑的地方，并寫測試案例來進行驗證。正常的情況下，要在不同的時間點上做幾個記憶體快照。IBM提供了幾個分析工具，MemDumpDiag，HeapRoots，利用這些工具可以對系統記憶體的使用進行輔助分析。另外一個有效的辦法是WebSphere還可以把GC（Garbage Collection）的log列印到SystemErr.log上，通過分析GC的日志可以得到很多的直覺上的對記憶體的使用，如記憶體的随着時間的變化情況等。IBM 提供的工具是“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector”，這個工具可以對GC進行分析統計。 有關在 WAS 中解決記憶體洩漏的更多資源，請參閱 developerWorks 中國站點的文章：

· 《WebSphere Application Server 中的記憶體洩漏檢測與分析：第 1 部分：記憶體洩漏概述》

· 《WebSphere Application Server 中的記憶體洩漏檢測與分析：第 2 部分：用于洩漏檢測與分析的工具和功能》

· 《WebSphere應用伺服器記憶體洩漏探測與診斷工具選擇最佳實踐》

8. 如何解決系統當機問題？

答：

WAS系統不會輕易的當機，因為WAS 容器能對它的記憶體和線程進行控制，大部分的情況是由于記憶體問題造成系統當機，如果這種情況發生，WAS預設的情況下會産生JavaCore檔案和Heap Dump檔案，需要對這兩個檔案進行分析。另外的能導緻系統當機的情況是WAS調用外部程式，如對C/C++程式的調用，這些JNI調用也有可能造成系統當機，如遇這種情況，從WAS出發找不到問題的根源的，需要從外部程式（C/C++）進行查找問題的根源。

9. WAS 運作在什麼平台上性能最好？是Intel、UNIX、pSeries/AIX、Sun/Solaris，還是 zSeries/zOS？

答：

這裡有幾個關于WAS在不同平台上的性能總結。當然您要清楚，在選擇WAS運作的平台時需要考慮衆多的因素，不僅是性能。

· WAS 幾乎完全是一個Java應用程式（除了有一小部分平台相關的代碼），基礎代碼對任何平台都是一樣的（除了zSerires/zOS）。是以，性能的任何差别主要依賴底層硬體、作業系統和JVM的性能。

· WebSphere的性能主要依賴于JVM的性能。JVM是本地代碼，由IBM或者作業系統提供者提供。IBM開發的JVM具有非常好的性能和可擴充性。pSeries平台上WebSphere 正是使用IBM的JVM，它有着相當突出的性能和可擴充性。關于JVM性能基準的更多資源，請通路以下站點：http://www.spec.org。

· WAS代碼對SMP（對稱多處理，Symmetrical Multi-Processing）處理器的可量測性做了優化，通常的規則是：基于UNIX，iSeries/OS400和zSeries/zOS的SMP 擴充結果比基于Intel的更強。而在UNIX作業系統中，AIX有最高的SMP擴充特性。

⒑ 問題：運作應用程式所需 CPU 的最小數量和最大數量是多少？

答：

現代作業系統通常在程序排程方面表現得很出色，進而最大程度減少了上下文切換。上下文切換是在作業系統排程程式用另一個程序替換 CPU 上正在運作的一個程序時發生的，而且是各種因素作用的結果，例如作業（或程序）優先級、是否等待其他資源（如 I/O）、程序是否将用完所有配置設定給它的 CPU 周期（時間片）等。但是，在執行上下文切換時，雖然現代作業系統表現很“出色”，卻并非“完美無缺”，因為程序在每次進行上下文切換時，它都将停止運作——這将導緻吞吐量出現延遲（和性能下降）。如果我們确實不希望出現任何上下文切換，則系統中的 CPU 數要大于該系統中運作的程序數。而這完全不切合實際，因為在一個系統中安裝這麼多的 CPU，幾乎沒有任何組織能負擔得起，而且也沒有必要，因為大多數程序都不要求對 CPU 進行持續通路。是以，我們應該轉而研究一些最重要的程序，這些程序在本文中即指系統中應用伺服器運作時所使用的JVM。

起初，我們假定每個應用伺服器 JVM 應該采用至少一個 CPU；這樣就有可能最大程度減少發生上下文切換的次數——至少就将用完時間片這一因素而言是如此（如上所述，導緻上下文切換還有其他因素）。但是除非您在運作所有伺服器時占用了全部 CPU 資源，否則，在應用程式請求（該請求随即被轉換為對作業系統資源的請求）到達應用伺服器時，很可能存在可用的 CPU 周期。是以，運作的應用伺服器數量有可能大于 CPU 數量。

不過，如果要獲得可以在環境中運作的伺服器的準确數量，則還得采用視情況而定之類的方式進行回答。這是因為該數量實際上取決于負荷、應用程式、吞吐量和響應時間要求等，确定這個準确數量的唯一方法是在環境中運作測試。

在開發環境（其中負荷可能是每個應用伺服器隻有一個使用者）中，您會期望每個 CPU 運作的應用伺服器執行個體數量是生産環境中的應用伺服器數量的數倍，這種想法很合理。盡管如此，也很難确定具體的應用伺服器數量，雖然為所有應用伺服器添加足夠的記憶體也是個相當重要的因素。根據經驗，所有 WebSphere Application Server JVM 程序加在一起的大小不應超過伺服器上未使用實體記憶體的 80%。在計算該數字可以達到的最大數目時，您必須考慮的不僅有最大堆大小，而且還有除最大堆大小之外的 Java? 位元組碼解釋器的程序大小（這個大小在作業系統程序表中列出）。位元組碼解釋器向程序表大約添加 65MB（除了最大堆大小 128MB 之外），并随最大堆大小的增加而增加。

在解決了 CPU 的最小數量後，您可能要問，最大 CPU 數量是多少？如果您了解到回答也是視情況而定，那不必感到驚訝。一個非常高效且經過精心編寫的應用程式隻通過一個應用伺服器程序即可使用多個 CPU。事實上，WebSphere Performance Lab 在運作涉及 Trade 性能基準時，使用了 12 個 CPU（有時更多）。而期望大多數應用程式具有這種伸縮性可能是不合理的，但大多數經過精心編寫的應用程式都應能通過應用伺服器使用多個 CPU（實際上，隻使用一個 CPU 通常表示存在應用程式瓶頸）。在任何情況下，由 Tom Alcott 在 WebSphere Scalability 一書講述的确定最佳克隆（或應用伺服器執行個體）數的指導原則仍然适用：

一般情況下，您應調整一個應用伺服器的執行個體來觀察吞吐量和性能，然後逐漸增加克隆數量，在添加每個克隆時，對性能和吞吐量進行測試。通過這種方式，可以确定為環境提供最佳吞吐量和性能所需的克隆數。通常，在 CPU 使用率達到稍微低于 75% 時，可以通過另添加克隆來提高吞吐量。

而且如您所見，對此問題的最終回答還是視情況而定。