–參考Websphere性能學習筆記

1.WAS日志
WebSphere的日志信息：
…/profiles/Appsrv01/logs/server下主要日志：
SystemErr.log : 系統出錯日志
SystemOut.log : 系統中所有活動的日志
trace.log : 系統中所有跟蹤的事件的日志
startServer.log : 啟動服務器事件的日志
stopServer.log : 停止服務器事件的日志
native_stderr.log : GC垃圾收集日志,這表明了內存管理是否正常。通過一些工具，比如：ISA里的 PMAT (IBM Pattern Modeling and Analysis Tool for Java Garbage Collector)可以查看GC歷史趨勢，看有沒有內存泄漏的問題。
IBM Http Server(IHS)與Plugin日志信息 ： httpserver/../logs下相關日志如果有相關was拋錯等首先查看以上日志文件。
WebSphere的日志對問題定位非常關鍵，如果用戶安裝部署、配置資源或者運行應用程序出了問題，都需要看日志才能明白到底是哪里，哪個環節出了問題，才能進一步解決問題。
比如：WAS安裝失敗，需要看/logs/install/log.txt，甚至如果失敗發生在該文件創建之前，需要去 看/waslogs/下的臨時日志；server啟動不起來，需要看SystemOut.log; 連接數據源失敗也需要看SystemOut.log；JNDI name找不到，需要察看SystemOut.log里，它是在哪里找的？為什么找不到？；有時候根據需要，還要看ffdc目錄下得log, SystemOut.log里會打印在某個時間點生成了一個ffdc log，文件文是什么。
FFDC log即First Failure Data Capture，即抓一些錯誤發生第一時間的log。

WebSphere Application Server 日志記錄基礎結構是基于標準 Java 的日志記錄基礎結構（即java.util.logging）建立的。在一個典型的 WebSphere Application Server 配置中，日志記錄被設置為將普通和嚴重的日志消息分別寫入兩個文件，即SystemOut.log 和 SystemErr.log。
System.out 日志用于監視正在運行的應用程序服務器的運行狀況。
System.err 日志包含用于執行問題分析的異常堆棧跟蹤信息。

WebSphere Application Server 中還有其他兩個日志文件：JVM native_stdout 和 native_stderr 文件。與 SystemOut.log 和 SystemErr.log 不同，這兩個文件實際上是由 JVM 本身處理的，只包含與該 JVM 的操作有關的消息，而不包含來自 WebSphere Application Server 運行時的消息。

假設在native_stderr.log里有這么一段日志：

<AF[3160]: Allocation Failure. need 2621456 bytes, 195 ms since last AF>
<AF[3160]: managing allocation failure, action=2 (5049520/1073740288)>
  <GC(3538): GC cycle started Wed Jul 30 17:41:02 2008
  <GC(3538): freed 4619080 bytes, 0% free (9668600/1073740288), in 6135 ms>
  <GC(3538): mark: 992 ms, sweep: 28 ms, compact: 5115 ms>
  <GC(3538): refs: soft 0 (age >= 32), weak 0, final 7, phantom 3>
  <GC(3538): moved 6184798 objects, 298397088 bytes, reason=1, used 101520 more bytes>
<AF[3160]: managing allocation failure, action=3 (9668600/1073740288)>
<AF[3160]: managing allocation failure, action=4 (9668600/1073740288)>
<AF[3160]: managing allocation failure, action=6 (9668600/1073740288)>
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
JVMDG318: Heap dump file written to C:Program FilesIBMWebSphereAppServerprofilesdefaultheapdump.20080730.174102.3784.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to C:Program FilesIBMWebSphereAppServerprofilesdefaultjavacore.20080730.174149.3784.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
<AF[3160]: Insufficient space in Javaheap to satisfy allocation request>
<AF[3160]: completed in 92673 ms>

第一行是說需要2621456 bytes內存，分配失敗；
然后第二行告知可用內存只有5049520 bytes；
第三行GC開始回收內存；
第四行回收了4619080 bytes，總的可用內存變為9668600bytes。0% free是指當前可用/總內存大小，9668600/1073740288=0.0090，被約等于0了。
第五行開始不知道在干什么，猜測是移動數據以獲取連續空間？
第十一行終于報內存不足了，然后會記錄兩個日志文件，heapdump、javacore.log。
根據這兩個日志的時間，可以到sysetemOut.log中查看當時在做什么操作。

再看一段：

<AF[2]: Allocation Failure. need 524 bytes, 383 ms since last AF>
<AF[2]: managing allocation failure, action=0 (528723272/536869376)>
  <GC(2): GC cycle started Sat Apr 05 21:40:31 2008
  <GC(2): freed 3529224 bytes, 99% free (532252496/536869376), in 10 ms>
  <GC(2): mark: 7 ms, sweep: 3 ms, compact: 0 ms>
  <GC(2): refs: soft 0 (age >= 32), weak 0, final 7, phantom 0>
<AF[2]: completed in 11 ms>

這段應該說明，可用內存很大，但申請連續內存時可能還是不足。這段日志記錄的是gc回收后就正好夠了，所以沒有了上一段日志中的move.

WebSphere監控方法
方案一、通過perfServletApp進行監控
perfServletApp項目是由WebSphere提供的（在安裝目錄下可以找到PerfServletApp.ear，默認沒有部署），用于簡單的端對端檢索性能數據，IBM 或第三方供應商提供的任何工具都可以處理此性能數據。通過servlet訪問，返回XML格式的信息。

方案二、使用JMX接口開發監控程序
通過使用 PerfMBean 或個別MBean，您可使用AdminClient API 獲取性能監控基礎結構（PMI）數據

查看JMX通過SOAP連接WebSphere的端口：
應用程序服務器 > serverName > 端口 ==> SOAP_CONNECTOR_ADDRESS

參考：
http://yunzhu.iteye.com/blog/971254
http://yunzhu.iteye.com/blog/953387
http://www.ibm.com/developerworks/cn/websphere/downloads/peformtuning.html

2 常用監控指標分析

2.1 JVM
2.1.1 JVM 級的診斷
參考：
http://www.ibm.com/developerworks/cn/websphere/techjournal/0702_supauth/0702_supauth.html
在其核心中，WebSphere Application Server 首先是一個 JVM 進程。因此，為所有的 JVM 進程提供一系列診斷工具的想法是十分自然的。實際上，在 WebSphere Application Server 的用戶們遇到的問題中，有一部分是在 JVM 級首先表現出來的，如內存不足、崩潰等。
? verboseGC 日志大概是最常見的JVM 診斷類型。它顯示了 JVM 生存期間，各個垃圾回收周期的順序。它作為確定問題時的一項初始的輔助工具，常常具有不可估量的價值，它被用來檢測和診斷 JVM 中所有類型的內存分配異常問題，如內存泄漏、碎片，以及與 GC 有關的性能問題等等。IBM Support Assistant 中提供的 PMAT 工具，目前是幫助分析 verboseGC 日志文件內容的基本工具。
? 線程轉儲也是一種極為常見的 JVM 診斷類型。線程轉儲（也是一個 javacore) 可以根據管理員的請求觸發，也能在 JVM 中遇到某種特殊情況時自動觸發。線程轉儲是一個文本文件，包含了 JVM 狀態的關鍵方面的一個相對較短的快照。該快照最常用的部分是 JVM 中當前活動線程的列表，線程轉儲也因此得名。線程轉儲最常見的用途是診斷 JVM 中出現掛起、崩潰或 CPU 占用率過高的原因。線程轉儲是相對較短的文本文件，可以用簡單的文本編輯器進行檢查。不過，若是使用某種特殊的工具，用來解析和組織其中的內容，自動檢測并突出關鍵信息和異常，常常會更有效。現在用于此用途的工具主要有兩種：IBM Support Assistant 中提供的ThreadAnalyzer 和AlphaWorks 上提供的 Thread and Monitor Dump Analyzer。
? 堆轉儲是由 JVM 生成的另一種形式的轉儲，可以按需生成，也可以在滿足特殊條件時自動生成。通常，堆轉儲通常是一個很大的文件，它包含當前 JVM 堆中所有對象的一個列表。它用于在出現內存不足的情況下執行深入分析。例如，分析者可以找出哪些對象在堆中占用了最多的空間，哪些對象正在增殖，等等。由于堆存儲是一個很大的文件，手動檢查是不切實際的。Memory Dump Diagnostic for Java 工具 (MDD4J) 可以在 IBM Support Assistant 中找到，目前它是執行此類分析的主要工具。
? 第三類 JVM 轉儲是系統轉儲，或是簡單的核心文件。這是開銷最大、但也是最完整的轉儲方式。它是一個巨大的二進制文件，反映了 JVM 的全部內容：每一個 Java 對象及其字段、每一個線程、每個內存區域，等等。系統轉儲的最初用途是在其他類型的轉儲不夠用或無法生成時，幫助診斷崩潰、掛起或復雜的內存分配問題。不過，由于系統轉儲非常完整，它也能用來獲取 WebSphere Application Server 運行時當前狀態的多方面信息，甚至運行時期間應用程序的執行信息。預計將來系統轉儲在這方面還會有更多的用途。在IBM 之外可獲得的WebSphere Application Server JVM 系統轉儲內容檢查工具相對較少。因此，一般情況下，系統轉儲應發送給IBM Support 做深入分析。不過 IBM 最近引入了一項被稱為 Diagnostic Tooling Framework for Java (DTFJ) 的新技術，將使系統轉儲檢查工具的開發變得容易起來。預計基于 DTFJ 技術的工具在未來將得到廣泛使用。
? 最后，JVM 還提供了自己的 JVM 跟蹤工具，與 WebSphere 跟蹤工具不同，它在單個 Java 方法調用級、以及 JVM 實現操作的內部事件級提供了跟蹤工具。這種類型的跟蹤最常用于內部 JVM 問題的診斷，偶爾也用來診斷 WebSphere Application Server 級的問題。不過，方法級別的跟蹤對于 WebSphere 跟蹤而言是很有用的輔助手段。我們計劃在不久的將來擴展它的用途并編寫相關文檔。
Java Diagnostics Guide 是一個主要的信息來源，提供與各種類型的 JVM 級診斷工具和相應的轉儲生成方法相關的信息。這些工具中的每一個都具有各自格式的文檔。

---

2.1.2 HeapSize
可監控FreeMemory、ProcessCpuUsage、UsedMemory

調整JVM堆大小
JVM 中最大堆大小有三方面限制：相關操作系統的數據模型（32-bt還是64-bit）限制；系統的可用虛擬內存限制；系統的可用物理內存限制。32位系統下，一般限制在1.5G~2G；64為操作系統對內存無限制。

默認設置
VU：100
HeapSize：200
FreeMemory：28~8
TRT：5.8

調整Initial Heap Size和Maximum Heap Size為512M
VU：100
HeapSize：524
FreeMemory：380~179
TRT：8.1

調整Initial Heap Size和Maximum Heap Size為64M
在WebSphere的控制臺查看TPV，提示：
錯誤 500
處理請求時發生一個錯誤： /ibm/console/secure/layouts/contentLayout.jsp
消息： java.lang.OutOfMemoryError

---

2.1.3 GC日志分析
在WAS中打開詳細GC日志輸出

方法1、在管理控制臺中點擊服務器 > 應用服務器 > server1（或者是您自己定義服務器名） > JAVA和進程管理 > 進程定義 > Java虛擬機 > 選中詳細垃圾回收選項，重啟應用服務器，即可生效。打開垃圾回收開關后，關于內存的使用情況的日志會存儲到相應的日志目錄中的native_stdout.log文件中，并且可以通過分析該文件中的信息快速的找到產生問題的根源。

方法2、在通用JVM參數輸入框中添加：-Xverbosegclog:gc.log

用PMAT（IBM Pattern Modeling and Analysis Tool for Java Garbage Collector）分析GC日志：
java -Xmx512m -jar ga414.jar

在負載測試過程中收集垃圾回收統計數據是很有幫助的，但大大小小的每次回收都會被記錄下來，所以請記住在運行最終的基準之前要禁用詳細垃圾回收。

2.1.4 策略
參考：
http://www.webspherechina.net/home/space.php?uid=275&do=blog&id=52178
https://blog.csdn.net/suifeng3051/article/details/48292193
https://blog.csdn.net/antony9118/article/details/51375662
https://blog.csdn.net/shen_guo/article/details/50343135

在IBM SDK 5.0提供了四種不同的GC策略優化配置(IBM 在WebSphere 6.1版本開始，IBM JDK 升級到IBM SDK5.0，也就是常說的JDK1.5)，詳細如下：

序號	策略	選項	描述	備注
1	針對吞吐量進行優化	-Xgcpolicy:optthruput	WAS默認策略。對于吞吐量比短暫的 GC 停頓更重要的應用程序，通常使用這種策略。每當進行垃圾收集時，應用程序都會停頓。
1	針對停頓時間進行優化	-Xgcpolicy:optavgpause	通過并發地執行一部分垃圾收集，在高吞吐量和短 GC 停頓之間進行折中。應用程序停頓的時間更短。
1	分代并發	-Xgcpolicy:gencon	以不同方式處理短期存活的對象和長期存活的對象。采用這種策略時，具有許多短期存活對象的應用程序會表現出更短的停頓時間，同時仍然產生很好的吞吐量。	推薦
1	子池	-Xgcpolicy:subpool	采用與默認策略相似的算法，但是采用一種比較適合多處理器計算機的分配策略。建議對于有 16 個或更多處理器的 SMP 計算機使用這種策略。這種策略只能在 IBM pSeries? 和 zSeries? 平臺上使用。需要擴展到大型計算機上的應用程序可以從這種策略中受益。

在Sun Jvm也有自己特色的GC策略，如：
可參考: java垃圾回收精粹

http://www.importnew.com/8335.html

序號	策略	選項	描述	備注
1	并發收集器(并發標記清理收集器,CMS)	-XX:+UseConcMarkSweepGC	并發收集器與應用程序同時運行。這些收集器在某點上（比如壓縮時），一般都不得不停止其他操作，以完成特定的任務，但是因為其他應用程序可進行其他的后臺操作，所以中斷其他處理的實際時間大大降低。
2	并行收集器	-XX:+UseParallelGC	并行收集器使用某種傳統的算法，并使用多線程并行地執行它們的工作。在多cpu機器上使用多線程技術可以顯著的提高java應用程序區性的可擴展性。
3	串行收集器	-XX:+UseSerialGC	用單線程處理所有垃圾回收工作，因為無需多線程交互，所以效率比較高,對于單處理器系統真是絕佳上選.但是，也無法使用多處理器的優勢，所以此收集器適合單處理器機器。當然，此收集器也可以用在小數據量（100M左右）情況下的多處理器機器上。

并行GC

-XX:+UseParallelGC
-XX:ParallelGCThreads= either equal to number of cpu or on multi core systems set it to somewhere between .5-1xNumber of cores.
配置并行收集器的線程數，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。

-XX:+UseParallelOldGC：配置年老代垃圾收集方式為并行收集。JDK6.0支持對年老代并行收集。

2.1.5 HeapDump
參考：
http://www.webspherechina.net/?viewnews-6051.html
http://guotufu.iteye.com/blog/1123890

2.2 線程
http://www.oschina.net/question/129540_21818
Web 容器線程池
一般來說，每個服務器 CPU，5 至 10 個線程將會提供最佳吞吐量。另外我們也可以利用 WAS 自帶的 TPV 來幫助我們設置 Web 容器線程池。對系統做一個壓力測試，保持一定的負載，觀測 TPV 中的 PercentMaxed 和 ActiveCount的值，PercentMaxed 表示所有線程被使用的平均百分比，如果該值較大，那么就應該增大線程池的值；ActiveCount 表示被激活的線程個數，如果該值遠小于當前線程池的大小，那么可以考慮減小線程池的值。可以 使用 WAS 管理控制臺進行 Web 容器線程池的配置，位于 Application servers > AppServer name > Thread pools > WebContainer
http://space.itpub.net/11605445/viewspace-600491

---

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%，那么可以肯定系統在進程切換上面消耗的資源太多了。下調線程池的大小反而會提升吞吐率，而且會由于吞吐率的提升降低頁面平均響應時間。

這篇文章也許會使你對線程池大小對性能的影響有個感性的認識：
http://www.ibm.com/developerworks/cn/java/l-threadPool/

---

調整線程池:
服務器 > 應用程序服務器 > server_name > 線程池 > WebContainer

默認線程池設置：
50
50
60000

VU:10
TRT:0.401
TP:4473169

監控到PoolSize：8

VU：30
TRT：0.911
TP：5392938

監控到PoolSize：12

VU：50
TRT：1.492
TP：4916714

監控到PoolSize：12

VU:100
TRT:3.203
TP:4178110

監控到PoolSize：4

修改線程池設置：
5
5
60000

VU：50
TRT：1.525
TP：4820978

監控到
ActiveCount：2
PoolSize：3
PercentMaxed：0

VU：100
TRT：2.458
TP：5390173

監控到
ActiveCount：2
PoolSize：3
PercentMaxed：0

修改線程池設置：
2
2
60000

VU：100
TRT：3.092
TP：4265748

監控到
ActiveCount：1
PoolSize：2
PercentMaxed：0

修改線程池設置：
1
1
60000
啟動不了控制臺！只能找到server.xml文件修改回去！

2.3 Web應用程序
重點關注servlet、jsp的請求數、服務時間：

2.4 Session

主要關注ActiveCount、LiveCount

Session timeout:
The default value of Session Timeout is 30 minutes. Reducing this value to a lower number can help reduce memory consumption requirements, allowing a higher user load to be sustained for longer periods of time. Reducing the value too low can interfere with the user experience.

How To Set:
In the WebSphere Administrative Console: Servers > Application Servers > WebSphere Portal > Container Settings: Web Container Settings > Session Management > Session Timeout -> Set Timeout

---

內存中最大會話量：100
Timeout：2分鐘
VU：100
提示錯誤：
Action.c(31): Error -26612: HTTP Status-Code=500 (Internal Server Error) for “http://192.168.1.101:9080/PlantsByWebSphere/servlet/AccountServlet?action=login&updating=false”

內存中最大會話量：1000、允許溢出
Timeout：2分鐘
VU：100
不提示錯誤
內存使用：518M
TRT：7.9

內存中最大會話量：1000、允許溢出
Timeout：30分鐘
VU：100
內存使用：497M->513M（LiveCount和ActiveCount持續增加）
TRT：8.5

2.5 JDBC
主要關注：
WaitingThreadCount
FaultCount
PercentUsed
FreePoolSize

應用程序讀取數據庫有2種方式，一種是直接連接數據庫，一種是調用連接池。
1) 直連是程序直接創建物理連接，調用數據庫進行數據讀取。直連的創建會帶來很大的系統開銷，若程序中多處頻繁使用直連，會造成應用服務器資源消耗過多，影響程序的性能。
2) 連接池是創建和管理一個物理連接的緩沖池，其中會保留一定數量創建的物理連接不關閉，當有客戶端請求時，調用連接池，可以有效減少物理連接的創建次數，降低直連所帶來的系統開銷，緩解應用服務器壓力，提高程序性能。

調整設置連接池屬性：
資源 > JDBC > 數據源> 連接池屬性 > 常規屬性
包括：
-連接超時時間
-最大連接數
-最小連接數
-收集時間
-未使用的超時時間
-時效超時
-清除策略（一般選擇整個池）

連接超時值確保小于事務超時

連接超時
概述：
連接超時是指，當對指定連接池進行請求時，池中沒有可用連接（連接全部被使用，或者數據庫請求超時），當請求時間到達指定之間時未響應，那麼這個時候就會產生超時異常，通過日志可以發現。
意義：
連接超時的設置，是對我們應用響應速度的一種把關，客戶往往要求我們的產品在多長時間必須有響應，所以連接超時的設置，可以讓我們發現哪些程序點有響應速度問題，可能是數據庫查詢語句問題，也有可能是程序邏輯死循環，再有可能就是數據庫表結構需要優化，還有可能是最大連接數到達最大值。

最大連接數
概述：
最大連接數是指當前連接池中允許創建的最大物理連接數，當到達指定值后，將不允許創建物理連接。和連接超時相對應，當達到最大值后，連接請求將等待，直到池中有空閑連接為止，否則報連接超時錯誤。當使用集群機制時，會同時存在多個相同連接池，這個時候需要考慮最大數量的設置。
意義：
最大連接數可以有效控制創建物理連接的數量，連接池的大小影響著服務器資源的占用情況，若連接池過大，則會長期占用服務器可利用資源，若連接池過小，無法滿足現場環境應用高負載使用壓力。最大連接數的設置應根據TPV觀測數據進行合理配置。

最小連接數
概述：
最小連接數是指當前連接池要保留的最小物理連接，其決定未使用超時維護機制的下限，連接池的創建不是根據最小連接數而特意創建，而是根據用戶請求而創建，系統會一直維護最小的連接數目。
意義：
最小連接數使應用服務器保持一定數量的物理連接，利用應用服務器維護機制，合理分配服務器資源。當應用程序訪問頻繁，但訪問人數少的情況下，最小連接數的合理配置，可以將有效的資源進行充分利用，滿足特定應用需求。

收集時間
概述：
收集時間是連接池維護機制的核心，是指每次維護連接池的時間間隔。其有兩個維護指標，分別為未使用超時和時效超時，其值應該小于兩個指標中的任何一個。每一次維護周期中，連接池都會將連接池中超時的物理連接關閉，以減少系統占用資源。
意義：
合理的收集時間設置，是幫助我們關閉不必要的連接，節省系統資源占用的有效途徑。收集時間設置不易過大，因為時間間隔過長，會使很多未被使用的物理連接持續占用資源。若收集時間過小，則頻繁的維護會帶來很多系統開銷，連接池的主要精力都放到了維護上。

未使用的超時
概述：
未使用的超時指池中的物理連接空閑未使用的時間間隔，每隔指定時間，系統會為連接標記，幫助收集時間在維護過程中進行關閉。未使用的超時應該小于實效超時時間，并且其以最小連接數為標準，當連接數超過最小連接數時，其才起作用。
意義：
未使用超時的設置，幫助我們關閉不必要的空閑連接，釋放系統資源，并且減少數據庫開銷。根據現場環境使用情況，我們可以根據系統訪問頻繁程序，來定制合理的未使用超時，如果過小，當訪問頻繁程度大時，總需要重新創建，如果過大，當訪問頻繁程度不大時，連接池又空閑占用過多。

時效超時
概述：
實效超時指關閉物理連接的時間間隔，這個值是指到達指定的時間后，關閉滿足時間條件的物理連接，若這個物理連接未使用，則直接關閉，若這個連接正在使用，則當前事務結束后，關閉此連接。這個值不受最小連接數的影響，若沒有新創建的連接，此機制會關閉連接直到為0。
意義：
時效超時的設置，是為了方式應用程序或者數據庫造成的數據庫連接持續占用，可能導致的原因包括程序邏輯錯誤，數據庫宕機導致的錯誤等。還有一種情況為人為導致，就是若某個用戶持續占用一個資源不放，會導致其他用戶無法訪問。所以時效超時的設置，是對不合理使用應用，或者鏈接錯誤等進行強行關閉，保證程序的穩定性和持久性。

3 性能監控工具
3.1 IBM Support Assistant (ISA) Workbench
下載：
http://www-01.ibm.com/software/support/isa/

IBM Monitoring and Diagnostic Tools for Java - Health Center
簡介：
http://www.ibm.com/developerworks/java/jdk/tools/healthcenter/
The IBM Monitoring and Diagnostic Tools for Java - Health Center (Health Center) enables you to assess the current status of a running Java application. Health Center continuous monitoring provides information to identify and help resolve problems with your application:
? Identify if native or heap memory is leaking
? Discover which methods are taking most time to run
? Pin down I/O bottlenecks
? Visualize and tune garbage collection
? View any lock contentions
? Analyse unusual WebSphere? Real Time events
? Monitor your applications Thread activity
Use Health Center to help you:
? Optimize application performance
? Improve application stability and uptime
? Reduce system resource usage
? Reduce the time to resolve problems
? Drive down development and maintenance costs
? Trigger System dumps for analysis in IBM Monitoring and Diagnostics Tools for Java Memory Analyser
? Turn on verbosegc collection for analysis in IBM Monitoring and Diagnostics Tools for Java Garbage Collection and Memory Visualizer

安裝使用：
http://www.ibm.com/developerworks/java/jdk/tools/healthcenter/getting_started.html
1、下載安裝IBM Support Assistant Workbench.

2、在Workbench中安裝Health Center：

IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer …
IBM Monitoring and Diagnostic Tools for Java™ - Garbage Collection and Memory Visualizer 是詳細的 GC 數據可視化器。GC and Memory Visualizer 解析并繪制各種日志類型，包括詳細的 GC 日志、-Xtgc 輸出、本機內存日志（來自于 ps、svmon 和 perfmon 的輸出）。
它提供：
- 各種詳細的 GC 數據值的圖形顯示
- 調優推薦和問題檢測（如內存泄漏）
- 報告、原始日志、表格化數據和圖視圖
- 將數據另存為 HTML 報告、jpeg 圖像或 .csv 文件（導出到電子表格）
- 查看和對比多條記錄
- optthruput、optavgpause 和 gencon GC 方式的分析

參考：
WebSphere troubshooting-用工具分析GC Log
http://hi.baidu.com/onroading/item/5f26139619641ab983d2959d

IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)
IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) parses IBM verbose GC trace, analyzes Java heap usage, and recommends key configurations based on pattern modeling of Java heap usage. Only verbose GC traces generated from IBM JDKs are supported. (PMAT is a Technology Preview and is in English only.)

參考：
http://www-01.ibm.com/support/docview.wss?uid=swg27007240&aid=1

IBM Thread and Monitor Dump Analyzer for Java
參考：
http://guotufu.iteye.com/blog/1123890

What is IBM Thread and Monitor Dump Analyzer for Java?During the run time of a Java™ process, some Java Virtual Machiness (JVMs) may not respond predictably and oftentimes seem to hang up for a long time or until JVM shutdown occurs. It is not easy to determine the root cause of these sorts of problems.
By triggering a javacore when a Java process does not respond, it is possible to collect diagnostic information related to the JVM and a Java application captured at a particular point during execution. For example, the information can be about the operating system, the application environment, threads, native stack, locks, and memory. The exact contents are dependent on the platform on which the application is running.
On some platforms, and in some cases, javacore is known as “javadump.” The code that creates javacore is part of the JVM. One can control it by using environment variables and run-time switches. By default, a javacore occurs when the JVM terminates unexpectedly. A javacore can also be triggered by sending specific signals to the JVM. Although javacore or javadump is present in Sun Solaris JVMs, much of the content of the javacore is added by IBM and, therefore, is present only in IBM JVMs.
IBM Thread and Monitor Dump Analyzer for Java analyzes javacore and diagnoses monitor locks and thread activities in order to identify the root cause of hangs, deadlocks, and resource contention or monitor bottlenecks.

How does it work?This technology analyzes each thread information and provides diagnostic information, such as current thread information, the signal that caused the javacore, Java heap information (maximum Java heap size, initial Java heap size, garbage collector counter, allocation failure counter, free Java heap size, and allocated Java heap size), number of runnable threads, total number of threads, number of monitors locked, and deadlock information.
In addition, IBM Thread and Monitor Dump Analyzer for Java provides the recommended size of the Java heap cluster (applicable only to IBM SDK 1.4.2 and 1.3.1 SR7 or above) based on the heuristic analysis engine.
IBM Thread and Monitor Dump Analyzer for Java compares each javacore and provides process ID information for threads, time stamp of the first javacore, time stamp of the last javacore, number of garbage collections per minute, number of allocation failures per minute, time between the first javacore and the last javacore, number of hang suspects, and list of hang suspects.
This technology also compares all monitor information in javacore and detects deadlock and resource contention or monitor bottlenecks, if there are any.

Database Connection Pool Analyzer for IBM WebSphere Application Server
參考：
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21254645
http://yishueitian326.blog.163.com/blog/static/28586375201010935436260/
http://www-01.ibm.com/support/docview.wss?uid=swg21392440

簡介：
IBM Database Connection Pool Analyzer helps you to resolve JDBC connection pool related problems through its heuristic analysis engine. This tool is a tech preview and is available in English only.

IBM Trace and Request Analyzer for WebSphere Application Server
A tool that detects delays and hangs in WebSphere(R) trace and HTTP plug-in trace. This tool is a tech preview and is available in English only.

WebSphere Application Server Performance Tuning Toolkit
參考：
http://www.ibm.com/developerworks/cn/websphere/downloads/peformtuning.html

3.2 Nagios WAS
https://www.oschina.net/p/nagios-was/similar_projects?lang=21&sort=view&p=3

Nagios WAS 是個用來監控 IBM 的 WebSphere 應用服務器的 Nagios 插件。監控的內容包括：
MonitorJvmHeapsize
MonitorJdbcConnectionPools
MonitorThreadPools
MonitorLiveSessions

3.3 LoadRunner監視WebSphere (略)

總結

以上是生活随笔為你收集整理的Websphere 学习(二)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。