作者：人月神話，新浪博客同名
簡(jiǎn)介：多年SOA規(guī)劃建設(shè)，私有云PaaS平臺(tái)架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，長(zhǎng)期從事一線項(xiàng)目實(shí)踐
今天談下業(yè)務(wù)系統(tǒng)性能問(wèn)題分析診斷和性能優(yōu)化方面的內(nèi)容。這篇文章重點(diǎn)還是談已經(jīng)上線的業(yè)務(wù)系統(tǒng)后續(xù)出現(xiàn)性能問(wèn)題后的問(wèn)題診斷和優(yōu)化重點(diǎn)。
系統(tǒng)性能問(wèn)題分析流程
我們首先來(lái)分析下如果一個(gè)業(yè)務(wù)系統(tǒng)上線前沒有性能問(wèn)題，而在上線后出現(xiàn)了比較嚴(yán)重的性能問(wèn)題，那么實(shí)際上潛在的場(chǎng)景主要來(lái)自于以下幾個(gè)方面。
- 業(yè)務(wù)出現(xiàn)大并發(fā)的訪問(wèn)，導(dǎo)致出現(xiàn)性能瓶頸
- 上線后的系統(tǒng)數(shù)據(jù)庫(kù)數(shù)據(jù)日積月累，數(shù)據(jù)量增加后出現(xiàn)性能瓶頸
- 其它關(guān)鍵環(huán)境改變，比如我們常說(shuō)的網(wǎng)絡(luò)帶寬影響
正是由于這個(gè)原因，當(dāng)我們發(fā)現(xiàn)性能問(wèn)題的時(shí)候，首先就需要判斷是單用戶非并發(fā)狀態(tài)下本身就有性能問(wèn)題，還是說(shuō)在并發(fā)狀態(tài)才存在性能問(wèn)題。對(duì)于單用戶性能問(wèn)題往往比較容易測(cè)試和驗(yàn)證，對(duì)于并發(fā)性能問(wèn)題我們可以在測(cè)試環(huán)境進(jìn)行加壓測(cè)試和驗(yàn)證，以判斷并發(fā)下的性能。
如果是單用戶本身就存性性能問(wèn)題，那么大部分問(wèn)題都出在程序代碼和SQL需要進(jìn)一步優(yōu)化上面。如果是并發(fā)性能問(wèn)題，我們就需要進(jìn)一步分析數(shù)據(jù)庫(kù)和中間件本身的狀態(tài)，看是否需要對(duì)中間件進(jìn)行性能調(diào)優(yōu)。
在加壓測(cè)試過(guò)程中，我們還需要對(duì)CPU，內(nèi)存和JVM進(jìn)行監(jiān)控，觀察是否存在類似內(nèi)存泄漏無(wú)法釋放等情況，即并發(fā)下性能問(wèn)題本身也可能是代碼本身原因?qū)е滦阅墚惓！?/p>
性能問(wèn)題影響因素分析
對(duì)于性能問(wèn)題影響因素，簡(jiǎn)單來(lái)說(shuō)包括了硬件環(huán)境，軟件運(yùn)行環(huán)境和軟件程序三個(gè)方面的主要內(nèi)容。下面分別再展開說(shuō)明下。
硬件環(huán)境
硬件環(huán)境就是我們常說(shuō)的計(jì)算，存儲(chǔ)和網(wǎng)絡(luò)資源。
對(duì)于服務(wù)器的計(jì)算能力，一般來(lái)說(shuō)廠家都會(huì)提供TPMC參數(shù)作為一個(gè)參考數(shù)據(jù)，但是我們實(shí)際看到相同TPMC能力下的X86服務(wù)器能力仍然低于小型機(jī)的能力。
除了服務(wù)器的計(jì)算能力參數(shù)，另外一個(gè)重點(diǎn)就是我們說(shuō)的存儲(chǔ)設(shè)備，影響到存儲(chǔ)的重點(diǎn)又是IO讀寫性能問(wèn)題。有時(shí)候我們監(jiān)控發(fā)現(xiàn)CPU和內(nèi)存居高不下，而真正的瓶頸通過(guò)分析反而發(fā)現(xiàn)是由于IO瓶頸導(dǎo)致，由于讀寫性能跟不上，導(dǎo)致大量數(shù)據(jù)無(wú)法快速持久化并釋放內(nèi)存資源。
比如在Linux環(huán)境下，本身也提供了性能監(jiān)控工具方便進(jìn)行性能分析。比如常用的iostat,ps,sar,top,vmstat等，這些工具可以對(duì)CPU，內(nèi)存，JVM，磁盤IO等進(jìn)行性能監(jiān)控和分析，以發(fā)現(xiàn)真正的性能問(wèn)題在哪里。
比如我們常說(shuō)的內(nèi)存使用率持續(xù)告警，你就必須發(fā)現(xiàn)是高并發(fā)調(diào)用導(dǎo)致，還是JVM內(nèi)存泄漏導(dǎo)致，還是本身由于磁盤IO瓶頸導(dǎo)致。
對(duì)于CPU，內(nèi)存，磁盤IO性能監(jiān)控和分析的一個(gè)思路可以參考：
運(yùn)行環(huán)境-數(shù)據(jù)庫(kù)和應(yīng)用中間件
數(shù)據(jù)庫(kù)和應(yīng)用中間件性能調(diào)優(yōu)是另外一個(gè)經(jīng)常出現(xiàn)性能問(wèn)題的地方。
數(shù)據(jù)庫(kù)性能調(diào)優(yōu)
拿Oracle數(shù)據(jù)庫(kù)來(lái)說(shuō)，影響數(shù)據(jù)庫(kù)性能的因素包括：系統(tǒng)、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)。數(shù)據(jù)庫(kù)的優(yōu)化包括：優(yōu)化數(shù)據(jù)庫(kù)磁盤I/O、優(yōu)化回滾段、優(yōu)化Rrdo日志、優(yōu)化系統(tǒng)全局區(qū)、優(yōu)化數(shù)據(jù)庫(kù)對(duì)象。
要調(diào)整首先就需要對(duì)數(shù)據(jù)庫(kù)性能進(jìn)行監(jiān)控
我們可以在init.ora參數(shù)文件中設(shè)置TIMED_STATISTICS=TRUE 和在你的會(huì)話層設(shè)置ALTER SESSION SET STATISTICS=TRUE 。運(yùn)行svrmgrl 用 connect internal 注冊(cè)，在你的應(yīng)用系統(tǒng)正常活動(dòng)期間，運(yùn)行utlbstat.sql 開始統(tǒng)計(jì)系統(tǒng)活動(dòng)，達(dá)到一定的時(shí)間后，執(zhí)行utlestat.sql 停止統(tǒng)計(jì)。統(tǒng)計(jì)結(jié)果將產(chǎn)生在report.txt 文件中。
數(shù)據(jù)庫(kù)性能優(yōu)化應(yīng)該是一個(gè)持續(xù)性的工作，一個(gè)方面是本身的性能和參數(shù)巡檢，另外一個(gè)方面就是DBA也會(huì)經(jīng)常提取最占用內(nèi)存的低效SQL語(yǔ)句給開發(fā)人員進(jìn)一步分析，同時(shí)也會(huì)從數(shù)據(jù)庫(kù)本身的以下告警KPI指標(biāo)中發(fā)現(xiàn)問(wèn)題。
比如我們可能會(huì)發(fā)現(xiàn)Oracle數(shù)據(jù)庫(kù)出現(xiàn)內(nèi)存使用率高的告警，而通過(guò)檢查會(huì)發(fā)現(xiàn)是產(chǎn)生了大量的Redo日志導(dǎo)致，那么我們就需要從程序上進(jìn)一步分析為何會(huì)產(chǎn)生如此多的回滾。
應(yīng)用中間件性能分析和調(diào)優(yōu)
應(yīng)用中間件容器即我們常說(shuō)的Weblogic, Tomcat等應(yīng)用中間件容器或Web容器。應(yīng)用中間件調(diào)優(yōu)一個(gè)方面是本身的配置參數(shù)優(yōu)化設(shè)置，一個(gè)方面就是JVM內(nèi)存啟動(dòng)參數(shù)調(diào)優(yōu)。
對(duì)于應(yīng)用中間件本身的參數(shù)設(shè)置，主要包括了JVM啟動(dòng)參數(shù)設(shè)置，線程池設(shè)置，連接數(shù)的最小最大值設(shè)置等。如果是集群環(huán)境，還涉及到集群相關(guān)的配置調(diào)優(yōu)。
對(duì)于JVM啟動(dòng)參數(shù)調(diào)優(yōu)，往往也是應(yīng)用中間件調(diào)優(yōu)的一個(gè)關(guān)鍵點(diǎn)，但是一般JVM參數(shù)調(diào)優(yōu)會(huì)結(jié)合應(yīng)用程序一起進(jìn)行分析。
比如我們常見的JVM堆內(nèi)存溢出，如果程序代碼沒有內(nèi)存泄漏問(wèn)題的話，我就需要考慮調(diào)整JVM啟動(dòng)時(shí)候堆內(nèi)存設(shè)置。在32位操作系統(tǒng)下只能夠設(shè)置到4G，但是在64位操作系統(tǒng)下已經(jīng)可以設(shè)置到8G甚至更大的值。
其中JVM啟動(dòng)的主要控制參數(shù)說(shuō)明如下:
- -Xmx設(shè)置最大堆空間
- -Xms設(shè)置最小堆空間
- -XX:MaxNewSize設(shè)置最大新生代空間
- -XX:NewSize設(shè)置最小新生代空間
- -XX:MaxPermSize設(shè)置最大永久代空間(注：新內(nèi)存模型已經(jīng)替換為Metaspace)
- -XX:PermSize設(shè)置最小永久代空間(注：新內(nèi)存模型已經(jīng)替換為Metaspace)
- -Xss設(shè)置每個(gè)線程的堆棧大小
那么這些值究竟設(shè)置多大合適，具體來(lái)講：
Java整個(gè)堆大小設(shè)置，Xmx 和 Xms設(shè)置為老年代存活對(duì)象的3-4倍，即FullGC之后的老年代內(nèi)存占用的3-4倍。永久代 PermSize和MaxPermSize設(shè)置為老年代存活對(duì)象的1.2-1.5倍。
年輕代Xmn的設(shè)置為老年代存活對(duì)象的1-1.5倍。
老年代的內(nèi)存大小設(shè)置為老年代存活對(duì)象的2-3倍。
注意在新的JVM內(nèi)存模型下已經(jīng)沒有PermSize而是變化為Metaspace，因此需要考慮Heap內(nèi)存和Metaspace大小的配比，同時(shí)還需要考慮相關(guān)的垃圾回收機(jī)制是采用哪種類型等。
對(duì)于JVM內(nèi)存溢出問(wèn)題，我前面寫過(guò)一篇專門的分析文章可以參考。
從表象到根源-一個(gè)軟件系統(tǒng)JVM內(nèi)存溢出問(wèn)題分析解決全過(guò)程
軟件程序性能問(wèn)題分析
在這里首先要強(qiáng)調(diào)的一點(diǎn)就是，當(dāng)我們發(fā)現(xiàn)性能問(wèn)題后首先想到的就是擴(kuò)展資源，但是大部分的性能問(wèn)題本身并不是資源能力不夠?qū)е拢俏覀兂绦驅(qū)崿F(xiàn)上出現(xiàn)明顯缺陷。
比如我們經(jīng)常看到的大量循環(huán)創(chuàng)建連接，資源使用了不釋放，SQL語(yǔ)句低效執(zhí)行等。
為了解決這些性能問(wèn)題，最好的方法仍然是在事前控制。其中包括了事前的代碼靜態(tài)檢查工具的使用，也包括了開發(fā)團(tuán)隊(duì)對(duì)代碼進(jìn)行的Code Review來(lái)發(fā)現(xiàn)性能問(wèn)題。
所有已知的問(wèn)題都必須形成開發(fā)團(tuán)隊(duì)的開發(fā)規(guī)范要求，避免重復(fù)再犯。
業(yè)務(wù)系統(tǒng)性能問(wèn)題擴(kuò)展思考
對(duì)于業(yè)務(wù)系統(tǒng)的性能優(yōu)化，除了上面談到的標(biāo)準(zhǔn)分析流程和分析要素外，再談下其它一些性能問(wèn)題引發(fā)的關(guān)鍵思考。
上線前的性能測(cè)試是否有用？
有時(shí)候大家可能覺得奇怪，為何我們系統(tǒng)上線前都做了性能測(cè)試，為何上線后還是會(huì)出現(xiàn)系統(tǒng)性能問(wèn)題。那么我們可以考慮下實(shí)際上我們上線前性能測(cè)試可能存在的一些無(wú)法真實(shí)模擬生產(chǎn)環(huán)境的地方，具體為：
- 硬件能否完全模擬真實(shí)環(huán)境？最好的性能測(cè)試往往是直接在搭建完成的生產(chǎn)環(huán)境進(jìn)行。
- 數(shù)據(jù)量能否模擬實(shí)際場(chǎng)景？真實(shí)場(chǎng)景往往是多個(gè)業(yè)務(wù)表都已經(jīng)存在大數(shù)據(jù)量的積累而非空表。
- 并發(fā)能否模擬真實(shí)場(chǎng)景？一個(gè)是需要錄制復(fù)合業(yè)務(wù)場(chǎng)景，一個(gè)是需要多臺(tái)壓測(cè)機(jī)。
而實(shí)際上我們?cè)谧鲂阅軠y(cè)試的時(shí)候以上幾個(gè)點(diǎn)都很難真正做到，因此要想完全模擬出生產(chǎn)真實(shí)環(huán)境是相當(dāng)困難的，這也導(dǎo)致了很多性能問(wèn)題是在真正上線后才發(fā)現(xiàn)。
系統(tǒng)本身水平彈性擴(kuò)展是否完全解決性能問(wèn)題？
第二個(gè)點(diǎn)也是我們經(jīng)常談的比較多的點(diǎn)，就是我們的業(yè)務(wù)系統(tǒng)在進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候，特別是面對(duì)非功能性需求，我們都會(huì)談到系統(tǒng)本身的數(shù)據(jù)庫(kù)，中間件都采用了集群技術(shù)，能夠做到彈性水平擴(kuò)展。那么這種彈性水平擴(kuò)展能力是否又真正解決了性能問(wèn)題？
實(shí)際上我們看到對(duì)于數(shù)據(jù)庫(kù)往往很難真正做到無(wú)限的彈性水平擴(kuò)展，即使對(duì)于Oracle RAC集群往往也是最多擴(kuò)展到單點(diǎn)的2到3倍性能。對(duì)于應(yīng)用集群往往可以做到彈性水平擴(kuò)展，當(dāng)前技術(shù)也比較成熟。
當(dāng)中間件能夠做到完全彈性擴(kuò)展的時(shí)候，實(shí)際上仍然可能存在性能問(wèn)題，即隨著我們系統(tǒng)的運(yùn)行和業(yè)務(wù)數(shù)據(jù)量的不斷積累增值。實(shí)際上你可以看到往往非并發(fā)狀態(tài)下的單用戶訪問(wèn)本身就很慢，而不是說(shuō)并發(fā)上來(lái)后滿。因此也是我們常說(shuō)的要給點(diǎn)，即：
- 單點(diǎn)訪問(wèn)性能正常的時(shí)候可以擴(kuò)展集群來(lái)應(yīng)對(duì)大并發(fā)狀態(tài)下的同時(shí)訪問(wèn)
- 單點(diǎn)訪問(wèn)本身性能就有問(wèn)題的時(shí)候，要優(yōu)先優(yōu)化單節(jié)點(diǎn)訪問(wèn)性能
業(yè)務(wù)系統(tǒng)性能診斷的分類
對(duì)于業(yè)務(wù)系統(tǒng)性能診斷，如果從靜態(tài)角度我們可以考慮從以下三個(gè)方面進(jìn)行分類
- 操作系統(tǒng)和存儲(chǔ)層面
- 中間件層面（包括了數(shù)據(jù)庫(kù)，應(yīng)用服務(wù)器中間件）
- 軟件層面（包括了數(shù)據(jù)庫(kù)SQL和存儲(chǔ)過(guò)程，邏輯層，前端展現(xiàn)層等）
那么一個(gè)業(yè)務(wù)系統(tǒng)應(yīng)用功能出現(xiàn)問(wèn)題了，我們當(dāng)然也可以從動(dòng)態(tài)層面來(lái)看實(shí)際一個(gè)應(yīng)用請(qǐng)求從調(diào)用開始究竟經(jīng)過(guò)了哪些代碼和硬件基礎(chǔ)設(shè)施，通過(guò)分段方法來(lái)定位和查詢問(wèn)題。
比如我們常見的就是一個(gè)查詢功能如果出現(xiàn)問(wèn)題了，首先就是找到這個(gè)查詢功能對(duì)應(yīng)的SQL語(yǔ)句在后臺(tái)查詢是否很慢，如果這個(gè)SQL本身就慢，那么就要優(yōu)化優(yōu)化SQL語(yǔ)句。如果SQL本身快但是查詢慢，那就要看下是否是前端性能問(wèn)題或者集群?jiǎn)栴}等。
軟件代碼的問(wèn)題往往是最不能忽視的一個(gè)性能問(wèn)題點(diǎn)
對(duì)于業(yè)務(wù)系統(tǒng)性能問(wèn)題，我們經(jīng)常想到的就是要擴(kuò)展數(shù)據(jù)庫(kù)的硬件性能，比如擴(kuò)展CPU和內(nèi)存，擴(kuò)展集群，但是實(shí)際上可以看到很多應(yīng)用的性能問(wèn)題并不是硬件性能導(dǎo)致的，而是由于軟件代碼性能引起的。對(duì)于軟件代碼常見的性能問(wèn)題我在以往的博客文章里面也談過(guò)到，比較典型的包括了。
- 循環(huán)中初始化大的結(jié)構(gòu)對(duì)象，數(shù)據(jù)庫(kù)連接等
- 資源不釋放導(dǎo)致的內(nèi)存泄露等
- 沒有基于場(chǎng)景需求來(lái)適度通過(guò)緩存等方式提升性能
- 長(zhǎng)周期事務(wù)處理耗費(fèi)資源
- 處理某一個(gè)業(yè)務(wù)場(chǎng)景或問(wèn)題的時(shí)候，沒有選擇最優(yōu)的數(shù)據(jù)結(jié)構(gòu)或算法
以上都是常見的一些軟件代碼性能問(wèn)題點(diǎn)，而這些往往需要通過(guò)我們進(jìn)行Code Review或代碼評(píng)審的方式才能夠發(fā)現(xiàn)出來(lái)。因此如果要做全面的性能優(yōu)化，對(duì)于軟件代碼的性能問(wèn)題排查是必須的。
通過(guò)IT資源監(jiān)控或APM應(yīng)用工具來(lái)發(fā)現(xiàn)性能問(wèn)題
圖片來(lái)源 OneAPM
對(duì)于性能問(wèn)題的發(fā)現(xiàn)一般有兩條路徑，一個(gè)就是通過(guò)我們IT資源的監(jiān)控，APM的性能監(jiān)控和預(yù)警來(lái)提前發(fā)現(xiàn)性能問(wèn)題，一個(gè)是通過(guò)業(yè)務(wù)用戶在使用過(guò)程中的反饋來(lái)發(fā)現(xiàn)性能問(wèn)題。
APM應(yīng)用性能管理主要指對(duì)企業(yè)的關(guān)鍵業(yè)務(wù)應(yīng)用進(jìn)行監(jiān)測(cè)、優(yōu)化，提高企業(yè)應(yīng)用的可靠性和質(zhì)量，保證用戶得到良好的服務(wù)，降低IT總擁有成本(TCO)。
資源池-》應(yīng)用層-》業(yè)務(wù)層
這個(gè)可以理解為APM的一個(gè)關(guān)鍵點(diǎn)，原有的網(wǎng)管類監(jiān)控軟件更多的是資源和操作系統(tǒng)層面，包括計(jì)算和存儲(chǔ)資源的使用和利用率情況，網(wǎng)絡(luò)本身的性能情況等。但是當(dāng)要分析所有的資源層問(wèn)題如何對(duì)應(yīng)到具體的應(yīng)用，對(duì)應(yīng)到具體的業(yè)務(wù)功能的時(shí)候很難。
傳統(tǒng)模式下，當(dāng)出現(xiàn)CPU或內(nèi)存滿負(fù)荷的時(shí)候，如果要查找到具體是哪個(gè)應(yīng)用，哪個(gè)進(jìn)程或者具體哪個(gè)業(yè)務(wù)功能，哪個(gè)sql語(yǔ)句導(dǎo)致的往往并不是容易的事情。在實(shí)際的性能問(wèn)題優(yōu)化中往往也需要做大量的日志分析和問(wèn)題定位，最終才可能找到問(wèn)題點(diǎn)。
比如在我們最近的項(xiàng)目實(shí)施中，結(jié)合APM和服務(wù)鏈監(jiān)控，我們可以快速的發(fā)現(xiàn)究竟是哪個(gè)服務(wù)調(diào)用出現(xiàn)了性能問(wèn)題，或者快速的定位出哪個(gè)SQL語(yǔ)句有驗(yàn)證的性能問(wèn)題。這個(gè)都可以幫助我們快速的進(jìn)行性能問(wèn)題分析和診斷。
資源上承載的是應(yīng)用，應(yīng)用本身又包括了數(shù)據(jù)庫(kù)和應(yīng)用中間件容器，同時(shí)也包括了前端；在應(yīng)用之上則是對(duì)應(yīng)到具體的業(yè)務(wù)功能。因此APM一個(gè)核心就是要將資源-》應(yīng)用-》功能之間進(jìn)行整合分析和銜接。
而隨著DevOps和自動(dòng)化運(yùn)維的思路推進(jìn)，我們更加希望是通過(guò)APM等工具主動(dòng)監(jiān)控來(lái)發(fā)現(xiàn)性能問(wèn)題，對(duì)于APM工具最大的好處就是可以進(jìn)行服務(wù)全鏈路的性能分析，方便我們發(fā)現(xiàn)性能問(wèn)題究竟發(fā)生在哪里。比如我們提交一個(gè)表單很慢，通過(guò)APM分析我們很容易發(fā)現(xiàn)究竟是調(diào)用哪個(gè)業(yè)務(wù)服務(wù)慢，或者是處理哪個(gè)SQL語(yǔ)句慢。這樣可以極大的提升我們性能問(wèn)題分析診斷的效率。
