Websphere 学习(二)
–參考Websphere性能學(xué)習(xí)筆記
1.WAS日志
WebSphere的日志信息：
…/profiles/Appsrv01/logs/server下主要日志：
SystemErr.log : 系統(tǒng)出錯(cuò)日志
SystemOut.log : 系統(tǒng)中所有活動(dòng)的日志
trace.log : 系統(tǒng)中所有跟蹤的事件的日志
startServer.log : 啟動(dòng)服務(wù)器事件的日志
stopServer.log : 停止服務(wù)器事件的日志
native_stderr.log : GC垃圾收集日志,這表明了內(nèi)存管理是否正常。通過一些工具，比如：ISA里的 PMAT (IBM Pattern Modeling and Analysis Tool for Java Garbage Collector)可以查看GC歷史趨勢，看有沒有內(nèi)存泄漏的問題。
IBM Http Server(IHS)與Plugin日志信息 ： httpserver/../logs下相關(guān)日志如果有相關(guān)was拋錯(cuò)等首先查看以上日志文件。
WebSphere的日志對問題定位非常關(guān)鍵，如果用戶安裝部署、配置資源或者運(yùn)行應(yīng)用程序出了問題，都需要看日志才能明白到底是哪里，哪個(gè)環(huán)節(jié)出了問題，才能進(jìn)一步解決問題。
比如：WAS安裝失敗，需要看/logs/install/log.txt，甚至如果失敗發(fā)生在該文件創(chuàng)建之前，需要去 看/waslogs/下的臨時(shí)日志；server啟動(dòng)不起來，需要看SystemOut.log; 連接數(shù)據(jù)源失敗也需要看SystemOut.log；JNDI name找不到，需要察看SystemOut.log里，它是在哪里找的？為什么找不到？；有時(shí)候根據(jù)需要，還要看ffdc目錄下得log, SystemOut.log里會(huì)打印在某個(gè)時(shí)間點(diǎn)生成了一個(gè)ffdc log，文件文是什么。
FFDC log即First Failure Data Capture，即抓一些錯(cuò)誤發(fā)生第一時(shí)間的log。
WebSphere Application Server 日志記錄基礎(chǔ)結(jié)構(gòu)是基于標(biāo)準(zhǔn) Java 的日志記錄基礎(chǔ)結(jié)構(gòu)（即java.util.logging）建立的。在一個(gè)典型的 WebSphere Application Server 配置中，日志記錄被設(shè)置為將普通和嚴(yán)重的日志消息分別寫入兩個(gè)文件，即SystemOut.log 和 SystemErr.log。
System.out 日志用于監(jiān)視正在運(yùn)行的應(yīng)用程序服務(wù)器的運(yùn)行狀況。
System.err 日志包含用于執(zhí)行問題分析的異常堆棧跟蹤信息。
WebSphere Application Server 中還有其他兩個(gè)日志文件：JVM native_stdout 和 native_stderr 文件。與 SystemOut.log 和 SystemErr.log 不同，這兩個(gè)文件實(shí)際上是由 JVM 本身處理的，只包含與該 JVM 的操作有關(guān)的消息，而不包含來自 WebSphere Application Server 運(yùn)行時(shí)的消息。
假設(shè)在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內(nèi)存，分配失??；
然后第二行告知可用內(nèi)存只有5049520 bytes；
第三行GC開始回收內(nèi)存；
第四行回收了4619080 bytes，總的可用內(nèi)存變?yōu)?668600bytes。0% free是指當(dāng)前可用/總內(nèi)存大小，9668600/1073740288=0.0090，被約等于0了。
第五行開始不知道在干什么，猜測是移動(dòng)數(shù)據(jù)以獲取連續(xù)空間？
第十一行終于報(bào)內(nèi)存不足了，然后會(huì)記錄兩個(gè)日志文件，heapdump、javacore.log。
根據(jù)這兩個(gè)日志的時(shí)間，可以到sysetemOut.log中查看當(dāng)時(shí)在做什么操作。
再看一段：
<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>這段應(yīng)該說明，可用內(nèi)存很大，但申請連續(xù)內(nèi)存時(shí)可能還是不足。這段日志記錄的是gc回收后就正好夠了，所以沒有了上一段日志中的move.
WebSphere監(jiān)控方法
方案一、通過perfServletApp進(jìn)行監(jiān)控
perfServletApp項(xiàng)目是由WebSphere提供的（在安裝目錄下可以找到PerfServletApp.ear，默認(rèn)沒有部署），用于簡單的端對端檢索性能數(shù)據(jù)，IBM 或第三方供應(yīng)商提供的任何工具都可以處理此性能數(shù)據(jù)。通過servlet訪問，返回XML格式的信息。
方案二、使用JMX接口開發(fā)監(jiān)控程序
通過使用 PerfMBean 或個(gè)別MBean，您可使用AdminClient API 獲取性能監(jiān)控基礎(chǔ)結(jié)構(gòu)（PMI）數(shù)據(jù)
查看JMX通過SOAP連接WebSphere的端口：
應(yīng)用程序服務(wù)器 > 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 常用監(jiān)控指標(biāo)分析
2.1 JVM
2.1.1 JVM 級的診斷
參考：
http://www.ibm.com/developerworks/cn/websphere/techjournal/0702_supauth/0702_supauth.html
在其核心中，WebSphere Application Server 首先是一個(gè) JVM 進(jìn)程。因此，為所有的 JVM 進(jìn)程提供一系列診斷工具的想法是十分自然的。實(shí)際上，在 WebSphere Application Server 的用戶們遇到的問題中，有一部分是在 JVM 級首先表現(xiàn)出來的，如內(nèi)存不足、崩潰等。
? verboseGC 日志大概是最常見的JVM 診斷類型。它顯示了 JVM 生存期間，各個(gè)垃圾回收周期的順序。它作為確定問題時(shí)的一項(xiàng)初始的輔助工具，常常具有不可估量的價(jià)值，它被用來檢測和診斷 JVM 中所有類型的內(nèi)存分配異常問題，如內(nèi)存泄漏、碎片，以及與 GC 有關(guān)的性能問題等等。IBM Support Assistant 中提供的 PMAT 工具，目前是幫助分析 verboseGC 日志文件內(nèi)容的基本工具。
? 線程轉(zhuǎn)儲(chǔ)也是一種極為常見的 JVM 診斷類型。線程轉(zhuǎn)儲(chǔ)（也是一個(gè) javacore) 可以根據(jù)管理員的請求觸發(fā)，也能在 JVM 中遇到某種特殊情況時(shí)自動(dòng)觸發(fā)。線程轉(zhuǎn)儲(chǔ)是一個(gè)文本文件，包含了 JVM 狀態(tài)的關(guān)鍵方面的一個(gè)相對較短的快照。該快照最常用的部分是 JVM 中當(dāng)前活動(dòng)線程的列表，線程轉(zhuǎn)儲(chǔ)也因此得名。線程轉(zhuǎn)儲(chǔ)最常見的用途是診斷 JVM 中出現(xiàn)掛起、崩潰或 CPU 占用率過高的原因。線程轉(zhuǎn)儲(chǔ)是相對較短的文本文件，可以用簡單的文本編輯器進(jìn)行檢查。不過，若是使用某種特殊的工具，用來解析和組織其中的內(nèi)容，自動(dòng)檢測并突出關(guān)鍵信息和異常，常常會(huì)更有效?，F(xiàn)在用于此用途的工具主要有兩種：IBM Support Assistant 中提供的ThreadAnalyzer 和AlphaWorks 上提供的 Thread and Monitor Dump Analyzer。
? 堆轉(zhuǎn)儲(chǔ)是由 JVM 生成的另一種形式的轉(zhuǎn)儲(chǔ)，可以按需生成，也可以在滿足特殊條件時(shí)自動(dòng)生成。通常，堆轉(zhuǎn)儲(chǔ)通常是一個(gè)很大的文件，它包含當(dāng)前 JVM 堆中所有對象的一個(gè)列表。它用于在出現(xiàn)內(nèi)存不足的情況下執(zhí)行深入分析。例如，分析者可以找出哪些對象在堆中占用了最多的空間，哪些對象正在增殖，等等。由于堆存儲(chǔ)是一個(gè)很大的文件，手動(dòng)檢查是不切實(shí)際的。Memory Dump Diagnostic for Java 工具 (MDD4J) 可以在 IBM Support Assistant 中找到，目前它是執(zhí)行此類分析的主要工具。
? 第三類 JVM 轉(zhuǎn)儲(chǔ)是系統(tǒng)轉(zhuǎn)儲(chǔ)，或是簡單的核心文件。這是開銷最大、但也是最完整的轉(zhuǎn)儲(chǔ)方式。它是一個(gè)巨大的二進(jìn)制文件，反映了 JVM 的全部內(nèi)容：每一個(gè) Java 對象及其字段、每一個(gè)線程、每個(gè)內(nèi)存區(qū)域，等等。系統(tǒng)轉(zhuǎn)儲(chǔ)的最初用途是在其他類型的轉(zhuǎn)儲(chǔ)不夠用或無法生成時(shí)，幫助診斷崩潰、掛起或復(fù)雜的內(nèi)存分配問題。不過，由于系統(tǒng)轉(zhuǎn)儲(chǔ)非常完整，它也能用來獲取 WebSphere Application Server 運(yùn)行時(shí)當(dāng)前狀態(tài)的多方面信息，甚至運(yùn)行時(shí)期間應(yīng)用程序的執(zhí)行信息。預(yù)計(jì)將來系統(tǒng)轉(zhuǎn)儲(chǔ)在這方面還會(huì)有更多的用途。在IBM 之外可獲得的WebSphere Application Server JVM 系統(tǒng)轉(zhuǎn)儲(chǔ)內(nèi)容檢查工具相對較少。因此，一般情況下，系統(tǒng)轉(zhuǎn)儲(chǔ)應(yīng)發(fā)送給IBM Support 做深入分析。不過 IBM 最近引入了一項(xiàng)被稱為 Diagnostic Tooling Framework for Java (DTFJ) 的新技術(shù)，將使系統(tǒng)轉(zhuǎn)儲(chǔ)檢查工具的開發(fā)變得容易起來。預(yù)計(jì)基于 DTFJ 技術(shù)的工具在未來將得到廣泛使用。
? 最后，JVM 還提供了自己的 JVM 跟蹤工具，與 WebSphere 跟蹤工具不同，它在單個(gè) Java 方法調(diào)用級、以及 JVM 實(shí)現(xiàn)操作的內(nèi)部事件級提供了跟蹤工具。這種類型的跟蹤最常用于內(nèi)部 JVM 問題的診斷，偶爾也用來診斷 WebSphere Application Server 級的問題。不過，方法級別的跟蹤對于 WebSphere 跟蹤而言是很有用的輔助手段。我們計(jì)劃在不久的將來擴(kuò)展它的用途并編寫相關(guān)文檔。
Java Diagnostics Guide 是一個(gè)主要的信息來源，提供與各種類型的 JVM 級診斷工具和相應(yīng)的轉(zhuǎn)儲(chǔ)生成方法相關(guān)的信息。這些工具中的每一個(gè)都具有各自格式的文檔。
2.1.2 HeapSize
可監(jiān)控FreeMemory、ProcessCpuUsage、UsedMemory
調(diào)整JVM堆大小
JVM 中最大堆大小有三方面限制：相關(guān)操作系統(tǒng)的數(shù)據(jù)模型（32-bt還是64-bit）限制；系統(tǒng)的可用虛擬內(nèi)存限制；系統(tǒng)的可用物理內(nèi)存限制。32位系統(tǒng)下，一般限制在1.5G~2G；64為操作系統(tǒng)對內(nèi)存無限制。
默認(rèn)設(shè)置
VU：100
HeapSize：200
FreeMemory：28~8
TRT：5.8
調(diào)整Initial Heap Size和Maximum Heap Size為512M
VU：100
HeapSize：524
FreeMemory：380~179
TRT：8.1
調(diào)整Initial Heap Size和Maximum Heap Size為64M
在WebSphere的控制臺(tái)查看TPV，提示：
錯(cuò)誤 500
處理請求時(shí)發(fā)生一個(gè)錯(cuò)誤： /ibm/console/secure/layouts/contentLayout.jsp
消息： java.lang.OutOfMemoryError
2.1.3 GC日志分析
在WAS中打開詳細(xì)GC日志輸出
方法1、在管理控制臺(tái)中點(diǎn)擊服務(wù)器 > 應(yīng)用服務(wù)器 > server1（或者是您自己定義服務(wù)器名） > JAVA和進(jìn)程管理 > 進(jìn)程定義 > Java虛擬機(jī) > 選中詳細(xì)垃圾回收選項(xiàng)，重啟應(yīng)用服務(wù)器，即可生效。打開垃圾回收開關(guān)后，關(guān)于內(nèi)存的使用情況的日志會(huì)存儲(chǔ)到相應(yīng)的日志目錄中的native_stdout.log文件中，并且可以通過分析該文件中的信息快速的找到產(chǎn)生問題的根源。
方法2、在通用JVM參數(shù)輸入框中添加：-Xverbosegclog:gc.log
用PMAT（IBM Pattern Modeling and Analysis Tool for Java Garbage Collector）分析GC日志：
java -Xmx512m -jar ga414.jar
在負(fù)載測試過程中收集垃圾回收統(tǒng)計(jì)數(shù)據(jù)是很有幫助的，但大大小小的每次回收都會(huì)被記錄下來，所以請記住在運(yùn)行最終的基準(zhǔn)之前要禁用詳細(xì)垃圾回收。
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策略優(yōu)化配置(IBM 在WebSphere 6.1版本開始，IBM JDK 升級到IBM SDK5.0，也就是常說的JDK1.5)，詳細(xì)如下：
| 序號 | 策略 | 選項(xiàng) | 描述 | 備注 |
|---|---|---|---|---|
| 1 | 針對吞吐量進(jìn)行優(yōu)化 | -Xgcpolicy:optthruput | WAS默認(rèn)策略。對于吞吐量比短暫的 GC 停頓更重要的應(yīng)用程序，通常使用這種策略。每當(dāng)進(jìn)行垃圾收集時(shí)，應(yīng)用程序都會(huì)停頓。 | |
| 1 | 針對停頓時(shí)間進(jìn)行優(yōu)化 | -Xgcpolicy:optavgpause | 通過并發(fā)地執(zhí)行一部分垃圾收集，在高吞吐量和短 GC 停頓之間進(jìn)行折中。應(yīng)用程序停頓的時(shí)間更短。 | |
| 1 | 分代并發(fā) | -Xgcpolicy:gencon | 以不同方式處理短期存活的對象和長期存活的對象。采用這種策略時(shí)，具有許多短期存活對象的應(yīng)用程序會(huì)表現(xiàn)出更短的停頓時(shí)間，同時(shí)仍然產(chǎn)生很好的吞吐量。 | 推薦 |
| 1 | 子池 | -Xgcpolicy:subpool | 采用與默認(rèn)策略相似的算法，但是采用一種比較適合多處理器計(jì)算機(jī)的分配策略。建議對于有 16 個(gè)或更多處理器的 SMP 計(jì)算機(jī)使用這種策略。這種策略只能在 IBM pSeries? 和 zSeries? 平臺(tái)上使用。需要擴(kuò)展到大型計(jì)算機(jī)上的應(yīng)用程序可以從這種策略中受益。 |
在Sun Jvm也有自己特色的GC策略，如：
可參考: java垃圾回收精粹
http://www.importnew.com/8335.html
| 序號 | 策略 | 選項(xiàng) | 描述 | 備注 |
|---|---|---|---|---|
| 1 | 并發(fā)收集器(并發(fā)標(biāo)記清理收集器,CMS) | -XX:+UseConcMarkSweepGC | 并發(fā)收集器與應(yīng)用程序同時(shí)運(yùn)行。這些收集器在某點(diǎn)上（比如壓縮時(shí)），一般都不得不停止其他操作，以完成特定的任務(wù)，但是因?yàn)槠渌麘?yīng)用程序可進(jìn)行其他的后臺(tái)操作，所以中斷其他處理的實(shí)際時(shí)間大大降低。 | |
| 2 | 并行收集器 | -XX:+UseParallelGC | 并行收集器使用某種傳統(tǒng)的算法，并使用多線程并行地執(zhí)行它們的工作。在多cpu機(jī)器上使用多線程技術(shù)可以顯著的提高java應(yīng)用程序區(qū)性的可擴(kuò)展性。 | |
| 3 | 串行收集器 | -XX:+UseSerialGC | 用單線程處理所有垃圾回收工作，因?yàn)闊o需多線程交互，所以效率比較高,對于單處理器系統(tǒng)真是絕佳上選.但是，也無法使用多處理器的優(yōu)勢，所以此收集器適合單處理器機(jī)器。當(dāng)然，此收集器也可以用在小數(shù)據(jù)量（100M左右）情況下的多處理器機(jī)器上。 |
并行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.
配置并行收集器的線程數(shù)，即：同時(shí)多少個(gè)線程一起進(jìn)行垃圾回收。此值最好配置與處理器數(shù)目相等。
-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 容器線程池
一般來說，每個(gè)服務(wù)器 CPU，5 至 10 個(gè)線程將會(huì)提供最佳吞吐量。另外我們也可以利用 WAS 自帶的 TPV 來幫助我們設(shè)置 Web 容器線程池。對系統(tǒng)做一個(gè)壓力測試，保持一定的負(fù)載，觀測 TPV 中的 PercentMaxed 和 ActiveCount的值，PercentMaxed 表示所有線程被使用的平均百分比，如果該值較大，那么就應(yīng)該增大線程池的值；ActiveCount 表示被激活的線程個(gè)數(shù)，如果該值遠(yuǎn)小于當(dāng)前線程池的大小，那么可以考慮減小線程池的值?？梢?使用 WAS 管理控制臺(tái)進(jìn)行 Web 容器線程池的配置，位于 Application servers > AppServer name > Thread pools > WebContainer
http://space.itpub.net/11605445/viewspace-600491
Web容器線程池
要點(diǎn)就是：“通常，對于每個(gè)服務(wù)器 CPU，5 至 10 個(gè)線程將會(huì)提供最佳吞吐量”（現(xiàn)在的一個(gè)cpu可以用核來代替）。比如你的Pc Server有2塊CPU，每塊CPU都是4核，那么你一個(gè)Application Server可以設(shè)置的最小值和最大值可以分別為40、80。但是一般考慮到能充分利用CPU和Memory，或者為不同的應(yīng)用啟用不同的application server，一臺(tái)Pc Server上并不僅有這么一個(gè)appserver，而且還有別的進(jìn)程在占用著CPU，所以默認(rèn)的10到50（Linux 系統(tǒng)上 25 個(gè)）是一個(gè)比較合適的值，當(dāng)然更準(zhǔn)確的值需要通過性能測試來確定。
在進(jìn)行性能測試的時(shí)候，如果吞吐率不是很滿意，或者在TPV中看到線程池占用一直是最大值，不要立刻就調(diào)大線程池的設(shè)置——往往吞吐率會(huì)更一步下降。這時(shí)候要注意CPU占用率的情況、vmstat的r列值，特別是System狀態(tài)占用率的情況，如果接近10%，甚至超過10%，那么可以肯定系統(tǒng)在進(jìn)程切換上面消耗的資源太多了。下調(diào)線程池的大小反而會(huì)提升吞吐率，而且會(huì)由于吞吐率的提升降低頁面平均響應(yīng)時(shí)間。
這篇文章也許會(huì)使你對線程池大小對性能的影響有個(gè)感性的認(rèn)識(shí)：
http://www.ibm.com/developerworks/cn/java/l-threadPool/
調(diào)整線程池:
服務(wù)器 > 應(yīng)用程序服務(wù)器 > server_name > 線程池 > WebContainer
默認(rèn)線程池設(shè)置：
50
50
60000
VU:10
TRT:0.401
TP:4473169
監(jiān)控到PoolSize：8
VU：30
TRT：0.911
TP：5392938
監(jiān)控到PoolSize：12
VU：50
TRT：1.492
TP：4916714
監(jiān)控到PoolSize：12
VU:100
TRT:3.203
TP:4178110
監(jiān)控到PoolSize：4
修改線程池設(shè)置：
5
5
60000
VU：50
TRT：1.525
TP：4820978
監(jiān)控到
ActiveCount：2
PoolSize：3
PercentMaxed：0
VU：100
TRT：2.458
TP：5390173
監(jiān)控到
ActiveCount：2
PoolSize：3
PercentMaxed：0
修改線程池設(shè)置：
2
2
60000
VU：100
TRT：3.092
TP：4265748
監(jiān)控到
ActiveCount：1
PoolSize：2
PercentMaxed：0
修改線程池設(shè)置：
1
1
60000
啟動(dòng)不了控制臺(tái)！只能找到server.xml文件修改回去！
2.3 Web應(yīng)用程序
重點(diǎn)關(guān)注servlet、jsp的請求數(shù)、服務(wù)時(shí)間：
2.4 Session
主要關(guān)注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
內(nèi)存中最大會(huì)話量：100
Timeout：2分鐘
VU：100
提示錯(cuò)誤：
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”
內(nèi)存中最大會(huì)話量：1000、允許溢出
Timeout：2分鐘
VU：100
不提示錯(cuò)誤
內(nèi)存使用：518M
TRT：7.9
內(nèi)存中最大會(huì)話量：1000、允許溢出
Timeout：30分鐘
VU：100
內(nèi)存使用：497M->513M（LiveCount和ActiveCount持續(xù)增加）
TRT：8.5
2.5 JDBC
主要關(guān)注：
WaitingThreadCount
FaultCount
PercentUsed
FreePoolSize
應(yīng)用程序讀取數(shù)據(jù)庫有2種方式，一種是直接連接數(shù)據(jù)庫，一種是調(diào)用連接池。
1) 直連是程序直接創(chuàng)建物理連接，調(diào)用數(shù)據(jù)庫進(jìn)行數(shù)據(jù)讀取。直連的創(chuàng)建會(huì)帶來很大的系統(tǒng)開銷，若程序中多處頻繁使用直連，會(huì)造成應(yīng)用服務(wù)器資源消耗過多，影響程序的性能。
2) 連接池是創(chuàng)建和管理一個(gè)物理連接的緩沖池，其中會(huì)保留一定數(shù)量創(chuàng)建的物理連接不關(guān)閉，當(dāng)有客戶端請求時(shí)，調(diào)用連接池，可以有效減少物理連接的創(chuàng)建次數(shù)，降低直連所帶來的系統(tǒng)開銷，緩解應(yīng)用服務(wù)器壓力，提高程序性能。
調(diào)整設(shè)置連接池屬性：
資源 > JDBC > 數(shù)據(jù)源> 連接池屬性 > 常規(guī)屬性
包括：
-連接超時(shí)時(shí)間
-最大連接數(shù)
-最小連接數(shù)
-收集時(shí)間
-未使用的超時(shí)時(shí)間
-時(shí)效超時(shí)
-清除策略（一般選擇整個(gè)池）
連接超時(shí)值確保小于事務(wù)超時(shí)
連接超時(shí)
概述：
連接超時(shí)是指，當(dāng)對指定連接池進(jìn)行請求時(shí)，池中沒有可用連接（連接全部被使用，或者數(shù)據(jù)庫請求超時(shí)），當(dāng)請求時(shí)間到達(dá)指定之間時(shí)未響應(yīng)，那麼這個(gè)時(shí)候就會(huì)產(chǎn)生超時(shí)異常，通過日志可以發(fā)現(xiàn)。
意義：
連接超時(shí)的設(shè)置，是對我們應(yīng)用響應(yīng)速度的一種把關(guān)，客戶往往要求我們的產(chǎn)品在多長時(shí)間必須有響應(yīng)，所以連接超時(shí)的設(shè)置，可以讓我們發(fā)現(xiàn)哪些程序點(diǎn)有響應(yīng)速度問題，可能是數(shù)據(jù)庫查詢語句問題，也有可能是程序邏輯死循環(huán)，再有可能就是數(shù)據(jù)庫表結(jié)構(gòu)需要優(yōu)化，還有可能是最大連接數(shù)到達(dá)最大值。
最大連接數(shù)
概述：
最大連接數(shù)是指當(dāng)前連接池中允許創(chuàng)建的最大物理連接數(shù)，當(dāng)?shù)竭_(dá)指定值后，將不允許創(chuàng)建物理連接。和連接超時(shí)相對應(yīng)，當(dāng)達(dá)到最大值后，連接請求將等待，直到池中有空閑連接為止，否則報(bào)連接超時(shí)錯(cuò)誤。當(dāng)使用集群機(jī)制時(shí)，會(huì)同時(shí)存在多個(gè)相同連接池，這個(gè)時(shí)候需要考慮最大數(shù)量的設(shè)置。
意義：
最大連接數(shù)可以有效控制創(chuàng)建物理連接的數(shù)量，連接池的大小影響著服務(wù)器資源的占用情況，若連接池過大，則會(huì)長期占用服務(wù)器可利用資源，若連接池過小，無法滿足現(xiàn)場環(huán)境應(yīng)用高負(fù)載使用壓力。最大連接數(shù)的設(shè)置應(yīng)根據(jù)TPV觀測數(shù)據(jù)進(jìn)行合理配置。
最小連接數(shù)
概述：
最小連接數(shù)是指當(dāng)前連接池要保留的最小物理連接，其決定未使用超時(shí)維護(hù)機(jī)制的下限，連接池的創(chuàng)建不是根據(jù)最小連接數(shù)而特意創(chuàng)建，而是根據(jù)用戶請求而創(chuàng)建，系統(tǒng)會(huì)一直維護(hù)最小的連接數(shù)目。
意義：
最小連接數(shù)使應(yīng)用服務(wù)器保持一定數(shù)量的物理連接，利用應(yīng)用服務(wù)器維護(hù)機(jī)制，合理分配服務(wù)器資源。當(dāng)應(yīng)用程序訪問頻繁，但訪問人數(shù)少的情況下，最小連接數(shù)的合理配置，可以將有效的資源進(jìn)行充分利用，滿足特定應(yīng)用需求。
收集時(shí)間
概述：
收集時(shí)間是連接池維護(hù)機(jī)制的核心，是指每次維護(hù)連接池的時(shí)間間隔。其有兩個(gè)維護(hù)指標(biāo)，分別為未使用超時(shí)和時(shí)效超時(shí)，其值應(yīng)該小于兩個(gè)指標(biāo)中的任何一個(gè)。每一次維護(hù)周期中，連接池都會(huì)將連接池中超時(shí)的物理連接關(guān)閉，以減少系統(tǒng)占用資源。
意義：
合理的收集時(shí)間設(shè)置，是幫助我們關(guān)閉不必要的連接，節(jié)省系統(tǒng)資源占用的有效途徑。收集時(shí)間設(shè)置不易過大，因?yàn)闀r(shí)間間隔過長，會(huì)使很多未被使用的物理連接持續(xù)占用資源。若收集時(shí)間過小，則頻繁的維護(hù)會(huì)帶來很多系統(tǒng)開銷，連接池的主要精力都放到了維護(hù)上。
未使用的超時(shí)
概述：
未使用的超時(shí)指池中的物理連接空閑未使用的時(shí)間間隔，每隔指定時(shí)間，系統(tǒng)會(huì)為連接標(biāo)記，幫助收集時(shí)間在維護(hù)過程中進(jìn)行關(guān)閉。未使用的超時(shí)應(yīng)該小于實(shí)效超時(shí)時(shí)間，并且其以最小連接數(shù)為標(biāo)準(zhǔn)，當(dāng)連接數(shù)超過最小連接數(shù)時(shí)，其才起作用。
意義：
未使用超時(shí)的設(shè)置，幫助我們關(guān)閉不必要的空閑連接，釋放系統(tǒng)資源，并且減少數(shù)據(jù)庫開銷。根據(jù)現(xiàn)場環(huán)境使用情況，我們可以根據(jù)系統(tǒng)訪問頻繁程序，來定制合理的未使用超時(shí)，如果過小，當(dāng)訪問頻繁程度大時(shí)，總需要重新創(chuàng)建，如果過大，當(dāng)訪問頻繁程度不大時(shí)，連接池又空閑占用過多。
時(shí)效超時(shí)
概述：
實(shí)效超時(shí)指關(guān)閉物理連接的時(shí)間間隔，這個(gè)值是指到達(dá)指定的時(shí)間后，關(guān)閉滿足時(shí)間條件的物理連接，若這個(gè)物理連接未使用，則直接關(guān)閉，若這個(gè)連接正在使用，則當(dāng)前事務(wù)結(jié)束后，關(guān)閉此連接。這個(gè)值不受最小連接數(shù)的影響，若沒有新創(chuàng)建的連接，此機(jī)制會(huì)關(guān)閉連接直到為0。
意義：
時(shí)效超時(shí)的設(shè)置，是為了方式應(yīng)用程序或者數(shù)據(jù)庫造成的數(shù)據(jù)庫連接持續(xù)占用，可能導(dǎo)致的原因包括程序邏輯錯(cuò)誤，數(shù)據(jù)庫宕機(jī)導(dǎo)致的錯(cuò)誤等。還有一種情況為人為導(dǎo)致，就是若某個(gè)用戶持續(xù)占用一個(gè)資源不放，會(huì)導(dǎo)致其他用戶無法訪問。所以時(shí)效超時(shí)的設(shè)置，是對不合理使用應(yīng)用，或者鏈接錯(cuò)誤等進(jìn)行強(qiáng)行關(guān)閉，保證程序的穩(wěn)定性和持久性。
3 性能監(jiān)控工具
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 是詳細(xì)的 GC 數(shù)據(jù)可視化器。GC and Memory Visualizer 解析并繪制各種日志類型，包括詳細(xì)的 GC 日志、-Xtgc 輸出、本機(jī)內(nèi)存日志（來自于 ps、svmon 和 perfmon 的輸出）。
它提供：
- 各種詳細(xì)的 GC 數(shù)據(jù)值的圖形顯示
- 調(diào)優(yōu)推薦和問題檢測（如內(nèi)存泄漏）
- 報(bào)告、原始日志、表格化數(shù)據(jù)和圖視圖
- 將數(shù)據(jù)另存為 HTML 報(bào)告、jpeg 圖像或 .csv 文件（導(dǎo)出到電子表格）
- 查看和對比多條記錄
- 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 是個(gè)用來監(jiān)控 IBM 的 WebSphere 應(yīng)用服務(wù)器的 Nagios 插件。監(jiān)控的內(nèi)容包括：
MonitorJvmHeapsize
MonitorJdbcConnectionPools
MonitorThreadPools
MonitorLiveSessions
3.3 LoadRunner監(jiān)視WebSphere (略)
總結(jié)
以上是生活随笔為你收集整理的Websphere 学习(二)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： CXF和Axis的比较【转】
- 下一篇： 泰拉瑞亚手游秘银重剑怎么获取