[-]

一???????????問題調優跟蹤

事務數1秒調整后4 秒對單測一支交易

事務平均數為478秒調整后15 秒對單測一支交易

事務數40秒調整后600秒對單測一支交易

事務數40秒調整后930秒對單測一支交易

事務數900TPS網絡資源滿100M網絡混合交易

長時間壓力測試后服務主機報錯cannot set user id 資源臨時不可用系統資源分配不夠混合交易

集群環境中隨著壓力測試時間增長主機資源利用率逐漸下降調整后問題解決混合交易

集群環境存在隊列等待集群管理通信出現隊列stuck情況經打補丁包后解決混合交易

演練環境出現coredump現象--外圍引發

演練環境出現GC無法回收資源現象--普元BPSserver引發

演練環境出現coredump現象之XA事務引發

二???????????Last 總結

一?????????架構

二?????????操作系統

三?????????網絡

四?????????應用

五?????????數據庫

六?????????其他

三???????????結束語

四???????????附

jconsole 監控stuck 線程

??新建 session

??進入session 并執行相關命令

weblogic 監控stuck 線程

一、???????????問題調優跟蹤

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左右；server端經觀察發現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模式，并在同一臺物理機是部署多個；以充分利用server資源；

9.?????演練環境出現coredump現象--外圍引發

2013/3/11，今天約200人同一時候在線做操作演練環境出現coredump，應用主機出現線程掛起狀態。

分析：

經跟蹤，是我們在調用外圍系統時，假設外圍(出現異常或通信故障)長時間不返回，我們的應用就一直等待，當大量并發調用外圍，會導致大量線程掛起，導致長時間GC無法回收，隨后出現coredump；

解決方式：

1.??????臨時先屏蔽外圍，此現象就不再出現；

2.??????調整接口模塊超時時間設置為15分鐘，應用線程退出；

?

10.?????????????演練環境出現GC無法回收資源現象--普元BPSserver引發

2013/3/12，今天約400人同一時候在線做操作，在壓力測試時(2013/3/9)，BPSserver已經存在瓶頸，當業務員登陸系統后，查待辦；當并發量大時，會導致數據庫資源過高，長時間不返回待辦事項，終于導致GC長時間無法回收資源；而在演練時2013/3/12晚上，當大量人員查待辦時，此現象又出現，而且頁面長時時間無返回，業務人員上報也上報此問題。

分析：

經跟蹤BPS應用和數據庫發現一查待辦的慢SQL，keyword段未加索引，且SQL寫法需調整；

???????? 解決方式：

1．? 添加keyword段索引

2．? 優化SQL寫法，提高查詢效率；

效果:

???????? 依據stuck線程跟蹤，沒有再發現此問題。

11.??????????????演練環境出現coredump現象之XA事務引發

2013/3/13，今天約12000人左右同一時候在線做操作演練環境出現coredump，應用主機出現線程掛起狀態。

???????? 分析：

因為在我們的應用採用分庫方式，分為貸前和貸后庫，為了保證寫事務一致性，採用了XA事務方法。而我們在寫的過程中，把讀數據庫也啟用了XA事務，最后引大大量事務未提交，占用大量JVM資源，最后出現coredump。

解決方式：

更改全部代碼，去掉全部讀數據庫的事務，對于單資源庫的，假設不須要事務則也去掉事務；

效果:

接下來幾點再未出現coredump現象；

?

二、???????????Last 總結

(一)?????????架構

1.????????Weblogic最好不要採用集群方式，而採用單域單sever模式，并在同一臺物理機是部署多個，以充分利用server資源；。

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 server裝有X window。

安裝 MobaXterm PersonalEdition 軟件。

1)??新建 session

?

2)??進入session 并執行相關命令

?

執行命令例如以下：

[root@localhost ~]# export DISPLAY=192.168.33.1:0.0 [root@localhost ~]# jconsole ?

?

?

2.?????weblogic 監控stuck 線程

因為時間原因，當時記錄的粘滯線程截圖沒有了，下次有機會我再補充上；

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的性能调优某大型银行的一个系统过程跟踪和记录的全部內容，希望文章能夠幫你解決所遇到的問題。

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