一、 問題調優跟蹤
1. 事務數1/秒，調整後4 /秒(對單測一支交易)
2013/1/3，啓動壓力測試後，事務約:1個左右每秒，經修改調整weblogic啓動 JVM 參數 JAVA_OPTIONS,事務數據能達到4個左右；調整項如下：
1.調整weblogic啓動 JVM 參數,在 JAVA_OPTIONS中增加: -Dweblogic.threadpool.MinPoolSize=200-Dweblogic.threadpool.MaxPoolSize=500
2.修改weblogic jdbc:domain->服務->數據源->loan->連接池->（初始容量:100， 最大容量:200， 最小容量:100）
2. 事務平均數爲4.78/秒，調整後15 /秒(對單測一支交易)
2013/2/4, 1.VU用戶併發能到達5個，事務平均數爲4.78左右，增加再多VU,事務數不會增加,跟蹤jrockit飛行記錄，發現有爭用現象，
javacommon.struts2.interceptor.SharedRenderVariableInterceptor 經排查是strus中有同步記錄事務數，導致線程等待。經調整後，能提升到每秒15個事務左右；修改項如下：
1）修改easyloan.war\WEB-INF\classes\struts.xml:把如下內容註釋掉：
<!--
<interceptors>
<interceptorname="sharedRenderVariableInterceptor"
class="javacommon.struts2.interceptor.SharedRenderVariableInterceptor"/>
<interceptor-stackname="customDefaultCrudStack">
<interceptor-refname="paramsPrepareParamsStack"/>
<interceptor-refname="sharedRenderVariableInterceptor"/>
</interceptor-stack>
</interceptors>
<default-interceptor-refname="customDefaultCrudStack"/>
--!>
2) 把 easyloan.war\WEB-INF\classes\struts.xml修改：
<constant name="struts.devMode" value="false"/> <!-- 開發模式設置爲false--!>
3) 修改 easyloan.war\WEB-INF\classes\spring\applicationContext-service.xml如下：
default-autowire="byName" default-lazy-init="false" <!-- 惰性加載,調整參數爲false --!>
4).向 easyloan.war\WEB-INF\classes\configuration.xml 文件的 <configuration>中增加如下：
<settings>
<settingname="lazyLoadingEnabled" value="false"/>
<settingname="aggressiveLazyLoading" value="fasle"/>
<settingname="defaultExecutorType" value="REUSE"/>
</settings>
3. 事務數40/秒，調整後600/秒(對單測一支交易)
2013/2/18, 前端LR顯示只能達到併發用戶約10個，tps到達40左右；服務器端經觀察發現GC無法回收，並且後續tps下降到約5個左右；
Weblogic32位，JDK64位，經調整爲weblogic32位和 weblogic 自帶的32位JDK，內存爲2G，性能提升約100倍（TPS:600,響應時間：0.37秒）
4. 事務數40/秒，調整後930/秒(對單測一支交易)
2013/2/20, 從開始執行性能測試以來，LR前端顯示 tps最高到達40左右(除換成32位JDK), TPS無再增漲。
今天拷貝jrockit3364bit,和jrockit22 64bit，其中安裝使用jrockit-jdk1.6.0_22-R28.1.1-4.0.1，性能明顯提升，TPS最高到達930;
5. 事務數900/TPS，網絡資源滿（100M網絡）(混合交易)
在測試過程中，由於網頁存在圖片文件傳輸，當有圖片加載的頁面過多，網絡資源就佔滿。
解決方法：
1. 改變網絡貸款爲1000M網絡
2. 對每個頁面的圖片能壓縮就壓縮；
3. 把很多頁面加載原素放到首頁加載，後續就不再加載資源；
6. 長時間壓力測試後，服務主機報錯：“cannot set user id: 資源暫時不可用，系統資源分配不夠”(混合交易)
解決方法：
修所有應用主機參數，即解決問題，之後再無此現象：
[loanapp@gdap1 ~]$ cat/etc/security/limits.conf |grep loanapp
#loanapp soft nproc 2047
loanapp soft nproc 10240
loanapp hard nproc 16384
loanapp soft nofile 65535
loanapp hard nofile 65536
7. 集羣環境中隨着壓力測試時間增長，主機資源利用率逐漸下降，調整後問題解決(混合交易)
2013/3/5，目前運行情況分析，併發 1200，每個 weblogic server 大約爲 100 個併發。針對此情況，建議進行如下調整，然後進行對比測試。
-Xms4096m -Xmx4096m -Xns1024m
-Xgc:throughput
-XXgcthreads:32
-XX:+HeapDumpOnCtrlBreak-XX:+HeapDumpOnOutOfMemoryError
-Dweblogic.threadpool.MinPoolSize=100
相關參數解釋,具體請參考 Jrockit參考手冊：
針對內存消耗較大應用，增加Xns指定 Jrockit的Nursery區域，可以使存活時間短的
java對象回收完全。
針對於線程數較大情況，默認GC回收線程爲 CPU核數（64） ，建議調小GC線程爲32進行測試，這樣可以降低進程的總線程數，降低線程數過大時的線程切換消耗。
在setDomainEnv.sh/中增加如下啓動參數:
JAVA_OPTIONS="${JAVA_OPTIONS}-Xgc:throughput -XX:+HeapDumpOnCtrlBreak -XX:+HeapDumpOnOutOfMemoryError-XXgcthreads:32"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.threadpool.MinPoolSize=100"
8. 集羣環境存在隊列等待，集羣管理通信出現隊列stuck情況，經打補丁包後解決；(混合交易)
2013/3/5日Weblogic控制檯的隊列長度存在排隊，數值只增加不會減少，無業務時，隊列數值也不會減少。
分析發現這些排隊請求不影響正常的業務請求，存在排隊時，Weblogic控制檯的“暫掛用戶請求計數”數值一直爲 0，表明正常業務請求都能正常處理。
檢查Weblogic官方公佈的補丁情況，發現此問題爲Weblogic10.3.6的一個bug，這些排隊請求爲Weblogic內部的RMI請求，此BUG 信息如下：
Bug 15839280 : [WLS10.3.6] QUEUE LENGTH COUNT INCREASES OVER TIMEAND NEVER REDUCES
修復補丁爲：Patch: 15839280
將Weblogic產品打上此補丁，壓測觀察，隊列能夠正常收回。
解決方法：
1. Weblogic1036-Patches
2. 不使用weblogic集羣模式，採用單域單sever模式，並在同一臺物理機是部署多個；以充分利用服務器資源；
9. 演練環境出現coredump現象--外圍引發
2013/3/11，今天約200人同時在線做操作演練環境出現coredump，應用主機出現線程掛起狀態。
分析：
經跟蹤，是我們在調用外圍系統時，如果外圍(出現異常或通信故障)長時間不返回，我們的應用就一直等待，當大量併發調用外圍，會導致大量線程掛起，導致長時間GC無法回收，隨後出現coredump；
解決方案：
1. 臨時先屏蔽外圍，此現象就不再出現；
2. 調整接口模塊超時時間設置爲15分鐘，應用線程退出；
10. 演練環境出現GC無法回收資源現象--普元BPS服務器引發
2013/3/12，今天約400人同時在線做操作，在壓力測試時(2013/3/9)，BPS服務器已經存在瓶頸，當業務員登陸系統後，查待辦；當併發量大時，會導致數據庫資源過高，長時間不返回待辦事項，最終導致GC長時間無法回收資源；而在演練時2013/3/12晚上，當大量人員查待辦時，此現象又出現，而且頁面長時時間無返回，業務人員上報也上報此問題。
分析：
經跟蹤BPS應用和數據庫發現一查待辦的慢SQL，關鍵字段未加索引，且SQL寫法需調整；
解決方案：
1． 增加關鍵字段索引
2． 優化SQL寫法，提高查詢效率；
效果:
根據stuck線程跟蹤，沒有再發現此問題。
11. 演練環境出現coredump現象之XA事務引發
2013/3/13，今天約12000人左右同時在線做操作演練環境出現coredump，應用主機出現線程掛起狀態。
分析：
由於在我們的應用採用分庫方式，分爲貸前和貸後庫，爲了保證寫事務一致性，採用了XA事務方法。而我們在寫的過程中，把讀數據庫也啓用了XA事務，最後引大大量事務未提交，佔用大量JVM資源，最後出現coredump。
解決方案：
更改所有代碼，去掉所有讀數據庫的事務，對於單資源庫的，如果不需要事務則也去掉事務；
效果:
接下來幾點再未出現coredump現象；
二、 Last 總結
(一) 架構
1. Weblogic最好不要採用集羣方式，而採用單域單sever模式，並在同一臺物理機是部署多個，以充分利用服務器資源；。
a) 雖然集羣可以減少部署工作量，降低參數修配置的工作量，方便統計計數等優點。
b) 缺點集羣存在集羣中節點同步信息的問題，如果集羣節點多，主機管理各節點資源還會消耗一部份資源。根據以上經驗，有可能會出現；
2. Weblogic的下，如果在業務邏輯性上，爲了要保證增、刪、改的事務一致性，啓用了XA事務，那麼一定記得不要不是所有的事務都需要用到XA事務,不使用XA事務：
a) 查詢不需要使用XA事務
b) 如果某些數據只存在於一個數據源中，同樣也不需要使用XA事務
注：XA事務是等待所有的事務成功後再算成功，否則回退，那麼就要保證過程的持續狀態，資源就得不到釋放，JVM內存中事務多了，協調各事務資源也就多了，從而引發粘滯線程，最終導致處理能力大幅度下降，最嚴重情況是導致JVMdown機，如第一章節的11個問題就是最好的例證；
3. 架構下的各組件的基本配置參數需要進行調整，那麼就需要對各組件非常瞭解熟悉才能調整,如struts spring 等組件配置參數要知道詳細配置組合，需求仔細研究各組件特性。
(二) 操作系統
操作系統與JDK的比配關係要經過不斷測試才能找出最優的配合；
操作系統相應參數是否按管方進行了調整，但最好能懂得部份內核機制，如調整TCPbuffer大小，內存頁大小等；
(三) 網絡
網絡貸款資源要注意監控，TPS上不去看是否存在帶寬資源問題；
(四) 應用
注意應用程序內部算法是否存在某種同步機制等算法，一般在保證同步的情況下，併發性能都不是太好；
(五) 數據庫
程序中是否存在Block現象，如事務同步算法等，此會導致在併發時出現隊列等待現象，最終TPS上不去；
數據的存儲IO，分庫，SQL索引等優化方法，這需要單獨的優化知識，必要時，找專業DBA配合；最好自己也學習一下Oracle 的體系結構，才知道大致出現在什麼地方的問題；
(六) 其它
性能測試時，挑選的常用且較爲複雜的交易進行性能測試，但無法cover所有的交易，那麼可能存在這種現象：
1． 某個業務上，用得少，性能測試時沒有挑選，但由於SQL寫得有問題，長時間操作(讀寫)數據庫，導致資源無法釋放，就有可能導致JVM dump掉；
2． 某一程序，同樣性能測試沒有做，JAVA程序在處理業務邏輯時是正確的，但申請的對象總是沒有釋放，長時間下去，多人多次長時間操作涉及此程序模塊，大量對象沒有釋放，JVM程度佔滿，最終出現coredump。
所以對於整個應用系統來說，不能完全相信性能測試結束了，調優也就結束了。根據許多項目印證，並非如此。後續還需要定期進行應用巡檢，包括操作系統運行記錄、應用運行記錄、中間件運行記錄、數據庫運行記錄，用以發現邊角處那些致命的小問題。
三、 結束語
此文章並非講每個細節如何調整，而只是個人習慣作個筆記而已。不喜勿噴，調優是個很大的工程，如JVM啓動參數應該使用哪些特性、操作系統應該調整哪些系統參數、架構中組件的特性應該怎麼調、數據庫應該怎麼調優，這些話題都太大，每個都要理解基本原理才能能給出調優意見；如我在沒有考Oracle OCP 之前，以爲Oracle調幾個參數就叫優化了，現在理解完全不一樣，磁盤特性、操作系統特性、Oracle相關特徵，如它的日誌、頁、Buffer、SQL語法寫法、索引如何建立，是否會產生分裂，這些都會影響到性能。而這些知識在網上都可以找到相應的文章，或是官方文檔有詳細說明。在某種架構下，哪些特性組合在一起纔是最優的，需要不斷的積累和前輩們的經驗，多看看技術原理的書籍或是官方文檔，才真正有利於調優；
四、 附
1. jconsole 監控stuck 線程
保證Linux 服務器裝有X window。
安裝 MobaXterm PersonalEdition 軟件。
1) 新建 session
2) 進入session 並執行相關命令
執行命令如下：
|
[root@localhost ~]# export DISPLAY=192.168.33.1:0.0 [root@localhost ~]# jconsole
|
2. weblogic 監控stuck 線程
由於時間原因，當時記錄的粘滯線程截圖沒有了，下次有機會我再補充上；