(轉)WebSphere 中池資源調優 - 線程池、串連池和 ORB

標籤：rod   其他   thread   adc   chart   大量   計時   相互   效能最佳化   

WebSphere 中池資源調優 - 線程池、串連池和 ORB

來自：https://www.ibm.com/developerworks/cn/websphere/library/techarticles/1106_zhuxl_websphereenhancement/1106_zhuxl_websphereenhancement.html

IBM WebSphere Application Server （以下簡稱 WAS）能支援的應用程式越來越多，而這些應用程式有各自的獨特特性、需求和服務。正如任何兩個應用程式都不會採用完全相同的方式來使用應用伺服器一樣，我們也無法通過一組調優參數來為任意兩種不同的應用程式提供最佳效能。本篇文章將重點放在 WebSphere 伺服器中各種池資源的調優上，重點向讀者介紹線程池、串連池和 ORB 的作用以及調優的基本準則，通過本篇文章，讀者會對 WAS 調優有更加精確的掌握，特別是對各種池資源配置的瞭解會更加深入。從而能使自己更加有效率的使用 WebSphere 伺服器。

0 評論

朱 修磊, 軟體工程師, IBM

2011 年 6 月 13 日

• 內容

免費下載：IBM? WebSphere? Application Server 試用版
下載更多的IBM 軟體試用版，並加入IBM 軟體下載與技術交流群組，參與線上交流。

WebSphere 效能最佳化概述

是什麼引起了效能問題？或者如何提高系統的效能？這是我們在系統的開發和維護時經常會碰到的問題，但是這兩個問題很難回答。正如所示，效能問題可能發生於系統的各個環節中，當效能問題出來後很難馬上就定位效能的瓶頸在哪裡，即使找到了效能瓶頸，在進行調優的時候也要考慮系統整體環境，從上下文中分析，確定調優的策略；系統中一個或者多個“短板”的存在，就能讓系統無法達到設計時的目標，無法達到預期的效能提升。

在本文中，我們將重點放在 WebSphere 中各種池資源的調優上，包括線程池、資料庫連接池以及 ORB 的串連數調優。池（Pool）是 WebSphere 中最常涉及的概念之一。從網路、Web伺服器、Web 容器、EJB 容器，一直到資料來源，每一個環節都有線程池、串連池的影子。這些池資源從上到下被串連在一起，就形成了一個訪問和應答的隊列。在 WebSphere 的調優中，如果能合理的配置這些池資源，可以從很大程度上提高整個系統的運行效率。

圖 1. 效能問題發生在 WAS 和作業系統的各個環節中WAS 效能差的幾種表現及解決方案

系統效能差一般有以下兩種非常明顯的表現形式，第一種是 CPU 使用不高，使用者感覺交易回應時間很長；第二種是 CPU 使用很高，使用者感覺交易回應時間很長。對於第一種情況，可以斷定是由於系統的某一小部分造成了瓶頸，導致了所有的請求都在等待。簡單舉例來說，線程池的數量開的太小，導致所有的請求都在排隊等待進入線程池，因為沒有可用的線程使用，所以這個交易請求一直在排隊，導致交易回應時間很長。如果資料庫連接池開的太小，也會有同樣的表現。對於第二種情況，比較複雜。可能的根源之一是硬體資源不夠。根源之二是應用系統中產生了多個大對象。根源之三是程式演算法有問題。解決思路如下： 用效能分析器，如 RAD 或 JProfiler, 對運行環境進行分析，分析哪個類甚至於哪個函數消耗了這麼多的 CPU，並找到相應的解決方案。

WAS 效能調優沒有捷徑和魔術，因為每一個應用都有自己獨特的特性和資源需求，而且他們使用 WAS 的資源也有各種不同的方式，每一套調優的參數和策略僅適用於當前的系統內容，在實際的系統內容中不能簡單的將一種調優策略原封不動的移植到另外一個系統內容中，這樣往往得不到預期的調優目的，還可能照成更多的效能瓶頸。

 

回頁首

WebSphere 系統隊列介紹和調優

WAS 是由一系列相互作用的元件連線而成的，必須對這些被串連在一起的組件進行合理的調優，才能夠滿足客戶的應用對系統效能的要求。這些調整和調優將協助系統達到最大的吞吐率和最高的使用效率。

WebSphere 排隊網路

當用戶端發出一個請求時，該請求會從網路端開始依次進入 WehSphere 伺服器的各個組件，這些請求會在各個組件中進行排隊等候使用伺服器資源或者等待進入下一個組件進一步被伺服器處理請求，每個組件裡的請求組成請求隊列，而組件依次排列，就夠成了 WebSphere 排隊網路。正如所示，該排隊網路包括互連網、Web 服務器、Web 容器、EJB 容器以及資料庫端的串連池隊列等等。WebSphere 隊列裡的各個組件是互相資源依賴的，對請求的平均服務時間依賴於伺服器隊列中每個組件在同一時間的最大並發數。

圖 2. WebSphere 排隊網路

保守隊列和開放隊列

在組成 WebSphere 排隊網路的隊列中，大部分都屬於保守隊列。對於保守隊列，我們可以設定某些參數來限制隊列中請求被處理的最大並發數，相反，開發隊列則沒有這樣的限制。與開放隊列相比，保守隊列的好處是，可以使系統資源被有效管理和利用，避免因為資源耗盡而引起的系統崩潰。例如，在 Web 容器中，假設平均處理一個 servlet 請求要建立 10M 大小的對象，如果我們設定其最大串連數是 100，那麼這樣就可以將 Web 容器對記憶體的最大消耗控制在 1G 左右。因此，保守隊列使得系統管理員更有效管理系統應用。

保守隊列中的使用者請求有兩種狀態，分別是啟用狀態和等待狀態。當請求處於啟用狀態時，表明該請求正在被伺服器進行處理；當請求處於等待狀態時，表明該請求還未被處理，而是在等待被啟用，進而才能夠使用伺服器資源。只有當一個處於啟用狀態的請求被處理完畢離開隊列後，才會有一個處於等待狀態的請求被啟用，否則該請求將一直處於等待狀態，直到伺服器逾時拋出異常，如果出現此種情況，則表明伺服器需要進行系統最佳化。

在 WebSphere 伺服器的隊列網路中，Web 服務器、Web 容器以及資料庫連接池都屬於保守隊列。EJB 容器則繼承了對象請求代理（ORB）的隊列特性，屬於開放隊列。

WebSphere 中的隊列調優和設定

在 WebSphere 中，我們主要通過最大和最小串連數兩個參數來對其隊列進行調優和設定，接下來我們會給出一個在進行 WebSphere 隊列調優時的基本準則。讀者在以後的調優中可以參照這個準則，然後結合自己的實際系統內容來進行隊列調優。

“漏鬥”原則

WAS 調優的第一原則就是漏鬥原則。一般來說，讓客戶不能及時得到處理的請求在網路中等待，比讓它們在 WebSphere 伺服器中等待要好。的設定使得只有即將被伺服器接受處理的請求才能進入 WAS 的排隊網路，這樣更能提高伺服器的穩定性，而不至於當大量請求突然進入 WAS 時引起資源耗盡的情況。要實現這個原則，那麼越往下遊的組件，其處理請求的最大並發數應小於上遊組件的最大並發數。如所示，只有可以被處理的請求才會進入相應的組件被處理，而大於該組件並發數的其他請求，則都處於排隊狀態，等待伺服器接受處理。

圖 3. Upstream queuing

在的例子中，我們可以看出，在 WebSphere 排隊網路中，從上到下隊列中處理請求的並發數越來越小。當 200 用戶端請求到達 Web 服務器的時候，因為 Web 服務器設定了自己的最大並發數是 75，所以剩下的 125 個客戶請求只能暫留在網路中進行排隊等待被 Web 服務器處理；當這 75 個請求經過 Web 服務器被處理後，其中 25 個仍在停留在 Web 服務器中排隊，而剩下的 50 個請求則進去 Web 容器被進一步處理；直到最後有 25 個請求到達最後的資料庫端，這時請求被處理完畢。在這個系統中，每一個組件都在充分的工作，沒有因為等待請求到來而造成的資源浪費，因為在任何一個時刻，每個隊列裡都有少量請求在等待著被下一個組件處理。因為大量的請求被阻止在 WebSphere 伺服器的外面（網路），所以 WebSphere 的各個組件不會因為大量請求同時到來而引起資源耗盡，這樣的設定增加了系統的穩定性。

繪製吞吐率曲線

上面介紹了在對 WebSphere 伺服器集區資源進行調優時的一個最重要的準則，下面我們來介紹如何根據這個準則，並結合使用者實際的系統內容來進行調優設定。首先我們需要畫出系統在運行時的吞吐率曲線，要完成曲線，需要準備一個測試案例，然後將系統運行起來，我們的目的是要將系統的潛能發揮到最大，即系統運行達到一個資源利用的飽和點。系統運行達到飽和點最有代表性新的特徵就是 CPU 的利用率接近 100%。

在運行測試案例的開始階段，我們將 WebSphere 排隊網路中所有的隊列並發數都設定為一個較大的值，而且各個隊列的值也設成是相等的。要保證這樣的設定可以使你的系統在運行時達到最大的處理能力。例如，將排隊網路的每一個隊列的最大並發數都設定成 100。

現在，我們開始進行一系列的測試，根據測試資料繪出吞吐率曲線。在每一次的測試後，增加使用者並發數，反覆項目測試，例如：把使用者並發數設定成如下一組數值進行一系列測試（1,5,10,25,50,100,150,200...），在每次測試後，記錄下本次系統的吞吐率和回應時間，就得到了類似於的吞吐率曲線。

圖 4. 吞吐率曲線

吞吐率是 WebSphere 伺服器在同一時間處理使用者請求的並發數，反應的是 WebSphere 處理並發請求的能力。從中我們可以看出，曲線可以分為三個階段，在第一階段，也就是 A 階段的時候，這時並發的數量比較少，吞吐率隨著並發數目的增加而增加。因為在這個時候，並發數較小，隊列中幾乎沒有請求在排隊，每當一個請求到來時就能立刻得到處理，隨著並發數的增加，在某一時刻，排隊情況開始出現，吞吐率曲線的增長變的緩慢，直到達到了系統處理能力的飽和點，這個時候也就是出現了系統的效能瓶頸。最具代表性的系統瓶頸是，在飽和點時，系統 CPU 利用率幾近 100%，這時我們只要換上更加高效能的 CPU 就可以提高整個系統的效能。在經過飽和點後，吞吐率曲線進入第二個階段 B，這時，隨著並發數的增加，輸送量並沒有增加，而是維持在一個穩定的水平。然而，用戶端所感受到的伺服器回應時間則會隨著並發數的增加而加長，這時因為很多的請求都在隊列裡排隊，並沒有及時的被伺服器處理。此刻，並發數繼續增加，就會進入第三個階段 C，這時，隨著並發數的增加，吞吐率反而會急劇下降，這時因為系統中某一個組件負載過重，導致資源已經被消耗殆盡。

在進行曲線繪製的過程中，我們需要注意一個問題，如果在飽和點出現的時候，系統的 CUP 利用率接近 100%，那麼我們就能進行進一步的調優設定了；如果 CPU 利用率沒有達到 100%，那麼就說明，系統中所啟動並執行應用程式存在問題，也就是效能瓶頸所在。比如，你的應用程式可能建立了很多的大對象，導致了 JAVA 中的頻繁 GC，大量佔用系統資源而出現效能瓶頸，對於效能瓶頸，我們需要認真檢查程式原始碼，找出問題所在，然後修改排查，消除因為應用而造成的系統瓶頸。找出效能系統瓶頸的方法很多，不是本文論述的重點，讀者可以參考其他資料來進行排查。

隊列初調

在吞吐率曲線達到飽和點時的使用者並發數是系統應用所能處理的最大並發數，這也是 A 階段和 B 階段的分界線。這個值將做為我們調整隊列大小的一個基準值。如所示，飽和點時，並發數是 50，我們選擇 48 來做為調整隊列的基準值，因為在此刻吞吐率和回應時間都是最佳的，這個值稱為程式所能處理請求的最大並發數。正如我們前面所介紹的，理想的情況是確保大量的等待請求處於網路中，而不是 WebSphere 伺服器中，所以參照“漏鬥”原則，我們可以對 WebSphere 伺服器中的各個組件的最大並發數進行如下設定：Web 服務器 , 75，Web 容器 50，資料庫連接池 45。然後我們在進行一系列的測試，對這些值進行微調，以使系統的效能達到最優。

根據應用的實際情況來調整隊列

僅僅根據上面的準則來調優 WAS 是遠遠不夠的，我們還應根據應用的使用環境和訪問模型來調整各個隊列的大小。並不是所有的請求都會從上一個隊列進入到下一個隊列中，比如，有些請求可能在經過 Web 服務器處理後就返回給用戶端了，因為這些使用者僅僅是想請求一些靜態頁面內容，這時我們可以將 Web 服務器的隊列值設的大一些，我們上面將 Web 服務器設成 75 就是這樣的考慮；又比如，如果在一個應用中，大部分的請求都需要進行複雜而耗時的資料庫操作，這時我們就應該考慮同時加大資料庫連接池和 Web 容器的隊列值大小。所以，在我們實際的調優中，必須結合具體的應用來確定合適的值，並在不斷調整的過程中，監控 CPU 和記憶體的使用，避免系統資源耗盡的情況出現。

 

回頁首

WebSphere 池資源調優的最佳實務

我們在這裡給出 WebSphere 池資源調優的一些建議，但真正合適的大小還要參考實際情況，調優是一個循序漸進的過程，需要經過不斷的嘗試和修改才能最終達到系統設計所需要的最佳效能。

ORB 調優

當配置 ORB 線程池的時候，需要瞭解 EJB 用戶端對應用的訪問模式。比如，如果在一個 servlet 中只是有很少的 EJB 調用，而且每一次方法調用的時間相對很短，那麼你就應該調整 ORB 線程池的值盡量小於 Web 容器的最大並發數。

圖 5 . EJB 調用模式

並行調用 EJB 的 servlet 的數量和每次方法調用所持續的時間是我們調整 ORB 線程池大小的兩個依據。如，是兩種在 WAS 裡從 servlet 中調用 EJB 的情境。第一種情境中，servlet 主要做一些期間非常短的遠程調用，servlet 可以重用已經存在的 ORB 線程。在這種情況下，ORB 線程池可以設的比較小，例如只要設定為 Web 容易最大並發量的一半就行；第二種情境中，期間比較長的 EJB 調用將會長期的佔用 ORB 串連，因此該串連被重用的機會很小，所以在這種情境中，最好將 ORB 線程池的大小與 Web 容器的最大並發量設定成相等，或者更大。可以使用 WAS 管理主控台進行 ORB 線程池的配置，位於 Application servers > AppServer name > Thread pools > ORB.thread.pool

Web 容器線程池

一般來說，每個伺服器 CPU，5 至 10 個線程將會提供最佳輸送量。另外我們也可以利用 WAS 內建的 TPV 來協助我們設定 Web 容器線程池。對系統做一個壓力測試，保持一定的負載，觀測 TPV 中的PercentMaxed和ActiveCount的值，PercentMaxed 表示所有線程被使用的平均百分比，如果該值較大，那麼就應該增大線程池的值；ActiveCount 表示被啟用的線程個數，如果該值遠小於當前線程池的大小，那麼可以考慮減小線程池的值。可以使用 WAS 管理主控台進行 Web 容器線程池的配置，位於 Application servers > AppServer name > Thread pools > WebContainer

資料庫連接池

當我們串連任何資料庫時，資料庫連接的初始化是一個非常耗資源的操作，所以當效能問題出現時，只是一味的加大資料庫連接池往往並不能提高效能。通常的做法是，首先將資料庫連接池的大小增大一倍，看看是否可以解決效能問題，如果可以，再逐步減少資料庫連接池的值，找到效能瓶頸以及達到最優效能時串連池的大小。一般來講，資料庫連接池的值小於 Web 容器線程池的值是比較好的選擇。

在實際的環境中，我們可以利用 TPV 去監控資料庫連接池的使用方式，以此來調整資料庫連接池的大小，從而確定最優的調優策略。可以從 TPV 的以下監測值中尋找答案。

表 1. TPV 監控列表

監測值名稱	描述	調優策略
PooSize	串連池的大小	PooSize 會隨著新串連的建立而增加，會隨著串連的銷毀而減少；應該為串連池設立一個最大值。
PercentUsed	串連池線程被使用的百分比	如果該值長時間都很小，那麼你應該調小 PooSize，反之應該增大。
WaitingThreadCount	單位時間內正在等待建立資料庫連接的線程的個數	系統最佳的效能體現在該值總是保持在很小的數目，如果該值偏大，則需要對系統進行調優
PercentMaxed	資料庫所有串連都被使用的時間所佔的百分比	確保這個值不會長時間的達到 100%，如果是那樣，那麼你該考慮增大 PooSize 值

可以使用 WAS 管理主控台進行資料庫連接池的配置，位於 JDBC providers > Provider name > Data sources > Data source name > Connection pools

 

回頁首

結束語

在本文中，我們詳細的討論了 WebSphere 伺服器中池資源的概念以及調優，並在介紹 WebSphere 排隊網路的基礎上，闡述了如何在實際的生產環境中進行池資源配置。通過閱讀本文，讀者可以基本掌握 WebSphere 效能調優的一般準則，並能初步掌握效能最佳化的一些技巧和方法。

(轉)WebSphere 中池資源調優 - 線程池、串連池和 ORB