(轉)websphere線程池 鏈接池設置

原文：http://www.talkwithtrend.com/Article/207511

池（Pool）是WebSphere中最常涉及的概念之一。從網絡、Web 服務器、Web 容器、EJB 容器，一直到數據源，每個環節都線程池、鏈接池的影子。要想恰當配置這些池的大小，首先要了解漏斗模型。

 

一般，WebSphere應用中的一個請求到達服務器，到真正開始處理，要通過一系列的鏈接池。廣域網上可能有大量的併發用戶同時訪問Web服務器，Web服務器上同時活動（Active）的鏈接可能高達10000個。但Web服務器到應用服務器（Web容器）的鏈接池大小可能只有200。Web容器到EJB容器的鏈接池更小，多是80。而後，通過數據源（Data source）到數據庫的鏈接最大可能只有25個。從Web服務器的鏈接池到數據庫的鏈接池尺寸逐漸變小，像一個漏斗（funnel），因此稱爲漏斗模型。

摘自《構建高性能WebSphere企業級應用》第二章

IBM 000-253中有這麼一道題：

According to the Upstream Queuing model for performance tuning, what reflets the correct application of recommended settings for maximum concurrent clients?

A Web Server=75, Web container=75, Datasource =25

B Web Server=75, Web container=50, Datasource =25

C Web Server=50, Web container=50, Datasource =50

        D Web Server=25, Web container=50, Datasource =75

根據漏斗模型，那麼很顯然應該選B。

那麼實際生產環境中就如此依樣畫葫蘆就能夠了麼？後面的池必定比前面的小麼？若是當前性能不行，增大池的大小就能提升麼？

絕沒有那麼簡單。後面的池小於前者，好比數據庫鏈接池小於web線程池，默認的假定是：並不是每一個JSP和Servlet都須要訪問數據庫。若是你的應用是數據庫密集型的應用，基本上每一個JSP和Servlet都須要訪問一次或屢次數據庫，並且系統中還有一些不通過jsp或Servlet的後臺進程。那麼數據源的鏈接池就必須大於web容器線程池，不然會報沒法獲得鏈接的錯。

下面按照個人經驗講述一下每層池大小設置值

對於Web服務器

IBM HTTP Server的優化就是對Apache的優化。通常須要調整httpd.conf中以下參數：

MaxClients：用來定義Web服務器能夠同時支持的最大併發鏈接數或併發用戶數，默認值是600。這個值須要根據你所但願的同時支持的併發用戶數來設置，通常是峯值的120%。固然這個值不能設的太大，畢竟Apache吃內存也是很厲害。我遇到的項目通常是不用調整的，你們能夠根據實際負載動態的調整MaxClients。

將 IBM HTTP Server 配置爲顯示狀態頁面：

• 編輯 IBM HTTP Server 的 httpd.conf 文件，今後文件的下列各行中註釋註釋字符（#）：

  #LoadModule status_module, modules/ApacheModuleStatus.dll,#<Location/server-status>#SetHandler server-status#</Location>

• 保存更改，而後從新啓動 IBM HTTP Server。
• 在 Web 瀏覽器中，轉至 http://yourhost/server-status。而且，單擊從新裝入以更新狀態。
• （可選）若是瀏覽器支持刷新，那麼轉至 http://your_host/server-status?refresh=5 以便每 5 秒鐘刷新一次。

 

上圖給出了一些其它參數的推薦值。注意Windows平臺和其它平臺的不一樣（ThreadsPerChild至關於Maxclients）。關於MinSpareServers,MaxSpareServers, 和StartServers 等的設置，以及MPM使用prefork或worker模塊時的不一樣，能夠閱讀Apache Performance Tuning。

若是你的應用訪問量很大，那麼也許你須要優化一下操做系統的tcp/ip相關參數。 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tuneopsys.html

並修改「負載均衡」選項和「重試時間間隔」Web 服務器插件屬性設置以提升性能http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunewebserv.html

Web容器線程池

要點就是：「一般，對於每一個服務器 CPU，5 至 10 個線程將會提供最佳吞吐量」（如今的一個cpu能夠用核來代替）。好比你的Pc Server有2塊CPU，每塊CPU都是4核，那麼你一個Application Server能夠設置的最小值和最大值能夠分別爲40、80。可是通常考慮到能充分利用CPU和Memory，或者爲不一樣的應用啓用不一樣的application server，一臺Pc Server上並不只有這麼一個appserver，並且還有別的進程在佔用着CPU，因此默認的10到50（Linux 系統上 25 個）是一個比較合適的值，固然更準確的值須要經過性能測試來肯定。

在進行性能測試的時候，若是吞吐率不是很滿意，或者在TPV中看到線程池佔用一直是最大值，不要馬上就調大線程池的設置——每每吞吐率會更一步降低。這時候要注意CPU佔用率的狀況、vmstat的r列值，特別是System狀態佔用率的狀況，若是接近10%，甚至超過10%，那麼能夠確定系統在進程切換上面消耗的資源太多了。下調線程池的大小反而會提高吞吐率，並且會因爲吞吐率的提高下降頁面平均響應時間。

這篇文章也許會使你對線程池大小對性能的影響有個感性的認識。

設置的地方你們應該都曉得，單擊服務器 > 應用程序服務器 >server_name > 線程池。

數據庫鏈接池

鏈接池的最小值，應該和性能測試時TPV觀察到的jdbc平均大小同樣，最大值根據實際須要設置，每次增加能夠設置成大於1，增加一次到位。總之儘可能避免鏈接池頻繁的增加和收縮，減小wait的狀況發生。

可使用 Tivoli Performance Viewer 查找池中最優鏈接數。若是併發等待者的數目大於 0，可是 CPU 負載未接近 100%，那麼考慮增長鏈接池大小。若是使用百分比值一直低於正常工做負載，那麼考慮減小池中的鏈接數。

Application Server 將在使用該數據源的每一個應用程序服務器中建立鏈接池的單獨實例。例如：

• 若是運行包含三個服務器的集羣，這三個服務器都使用myDataSource，而且 myDataSource 的「最大鏈接數」設置爲 10，那麼可生成多達 30 個鏈接（3 個服務器乘以 10 個鏈接）

這是須要考慮的，別數據庫端的鏈接大小不夠了。此外，inactive timeout和timeout的時間應該大於收集時間。

總結

這篇文章參考了IBM的inforcenter和developworks，給出了優化WebSphere池大小的一些經驗值，可是真正合適的大小還要參考實際的狀況，總之調優是個按部就班的過程。