在信息系統(tǒng)中，不少性能問(wèn)題是由不起眼的應(yīng)用中間件造成的。在上周的線(xiàn)上交流中，大家針對(duì)應(yīng)用中間件的性能監(jiān)控、性能優(yōu)化提出了不少問(wèn)題，本文由交流活動(dòng)嘉賓、社區(qū)專(zhuān)家楊建旭對(duì)這些問(wèn)題進(jìn)行了分類(lèi)總結(jié)，使大家能夠更清晰了解和掌握相關(guān)知識(shí)點(diǎn)。（同時(shí)也感謝社區(qū)專(zhuān)家swallowluo等參與解答）
應(yīng)用中間件之所以誕生，是為了幫助應(yīng)用程序的編碼人員處理與業(yè)務(wù)邏輯沒(méi)有太大關(guān)系而又必須處理的經(jīng)常性事物，比如處理應(yīng)用程序和數(shù)據(jù)庫(kù)之間的關(guān)系，設(shè)置開(kāi)啟多少個(gè)session來(lái)處理客戶(hù)請(qǐng)求，session的超時(shí)時(shí)間等等。
然而在享受便利的同時(shí)，應(yīng)用中間件也會(huì)成為系統(tǒng)性能問(wèn)題的締造者，開(kāi)發(fā)人員和測(cè)試人員往往忽視了中間件本身對(duì)性能的影響，這種影響包括交易吞吐量的制約、響應(yīng)時(shí)間的影響、交易成功率的影響等等。
應(yīng)用中間件相關(guān)的性能監(jiān)控與優(yōu)化可以歸類(lèi)為6個(gè)字，判斷、監(jiān)控、優(yōu)化。
判斷
性能問(wèn)題是多方面的，比如應(yīng)用、系統(tǒng)軟件（應(yīng)用中間件、消息中間件、數(shù)據(jù)庫(kù)等）、操作系統(tǒng)、硬件、網(wǎng)絡(luò)，那么如何診斷性能問(wèn)題是出自應(yīng)用中間件。
監(jiān)控
監(jiān)控是確診性能問(wèn)題的唯一重要手段，沒(méi)有監(jiān)控?cái)?shù)據(jù)，任何人都只能猜測(cè)問(wèn)題原因，而不能確定問(wèn)題根因。
監(jiān)控包括了監(jiān)控工具和監(jiān)控指標(biāo)。監(jiān)控工具是利器，具有了利器還需要明確監(jiān)控什么指標(biāo)，這些指標(biāo)如何影響系統(tǒng)的性能。
優(yōu)化
應(yīng)用中間件的性能優(yōu)化涉及到調(diào)整中間件的參數(shù)和一些策略。需要了解調(diào)整這些指標(biāo)有什么好處和壞處，這些指標(biāo)之間有什么關(guān)聯(lián)。
一、 判斷
運(yùn)維監(jiān)控、甚至是專(zhuān)門(mén)的性能測(cè)試中，最容易漏掉監(jiān)控的就是“應(yīng)用中間件”和“存儲(chǔ)”。往往是出了問(wèn)題，把所有可能懷疑遍了，也沒(méi)發(fā)現(xiàn)什么可疑之處，比如cpu利用率不高、網(wǎng)絡(luò)帶寬占用率很低、讀寫(xiě)磁盤(pán)IOPS不多、數(shù)據(jù)庫(kù)響應(yīng)時(shí)間很短，應(yīng)用的并發(fā)數(shù)量也充足，可就是業(yè)務(wù)響應(yīng)時(shí)間很長(zhǎng)，吞吐量很低。甚至把硬件配置的一堆參數(shù)也分析的透徹，這時(shí)候才想起了中間件。
從上面的場(chǎng)景中，其實(shí)可以發(fā)現(xiàn)，從系統(tǒng)拓?fù)涞慕嵌?，前?>中間件->應(yīng)用->中間件->數(shù)據(jù)庫(kù)的包抄當(dāng)中，如果你發(fā)現(xiàn)其他都沒(méi)有問(wèn)題，那很可能就是中間件的問(wèn)題了。或者從系統(tǒng)層次的角度，應(yīng)用->系統(tǒng)軟件（中間件、數(shù)據(jù)庫(kù)）->OS->硬件/網(wǎng)絡(luò)這條線(xiàn)上，如果其他都沒(méi)問(wèn)題，那也得看看中間件了。
我比較主張，一旦遇到性能問(wèn)題，或者平時(shí)關(guān)在測(cè)試環(huán)境里做的性能測(cè)試，只要是涉及到應(yīng)用中間件的、并且有壓力的，一定要做好中間件的監(jiān)控，在所有監(jiān)控?cái)?shù)據(jù)都全面的時(shí)候，判斷問(wèn)題才得心應(yīng)手。就好比去醫(yī)院，說(shuō)了病情，大夫一般什么結(jié)論也不會(huì)給，而是開(kāi)一堆檢查單化驗(yàn)單，你先做N個(gè)檢查，我看看。
如果已經(jīng)有了中間件的監(jiān)控?cái)?shù)據(jù)，可以先關(guān)注ResponseTime（接收到請(qǐng)求和應(yīng)答之間的平均時(shí)間），如果這個(gè)值出現(xiàn)異常，那就說(shuō)明業(yè)務(wù)在中間件中的這段處理可能有問(wèn)題，這段時(shí)間包括了收到請(qǐng)求到分配執(zhí)行的時(shí)間，包括了應(yīng)用等待數(shù)據(jù)庫(kù)連接池的時(shí)間、包括中間件調(diào)用數(shù)據(jù)庫(kù)執(zhí)行時(shí)間等等，然后我們?cè)俜侄畏治瞿睦锍霈F(xiàn)了問(wèn)題。如果ResponseTime較長(zhǎng)，收到請(qǐng)求到分配執(zhí)行的時(shí)間很長(zhǎng)或者等待數(shù)據(jù)庫(kù)連接池的時(shí)間很長(zhǎng)，而從數(shù)據(jù)庫(kù)上查看SQL的執(zhí)行時(shí)間很短，那么八成就是中間件里面的時(shí)間長(zhǎng)了。
二、 監(jiān)控
1）中間件監(jiān)控
自然是各家自帶的監(jiān)控工具或者監(jiān)控模塊效果最好。采集項(xiàng)也都是針對(duì)自己的產(chǎn)品定制的。當(dāng)然，市面也會(huì)有針對(duì)某個(gè)中間件的監(jiān)控產(chǎn)品。
例如WAS監(jiān)控有自帶模塊“性能監(jiān)控基礎(chǔ)結(jié)構(gòu)（PMI）”，也有PerformanceTuningToolkit用于后期展示。應(yīng)用中間件WAS的監(jiān)控方法可以參考本次線(xiàn)上交流的分享http://www.talkwithtrend.com/Article/216341
tomcat監(jiān)控工具有市面上的probe等。
同時(shí)，可以查看中間件的日志、FFDC（事故記錄，其中包含堆棧跟蹤、異常發(fā)生時(shí)的環(huán)境，以及對(duì)生成這一異常的服務(wù)器的組件狀態(tài)所做的一個(gè)短轉(zhuǎn)儲(chǔ)）
2）JVM的監(jiān)控
但如果某個(gè)中間件沒(méi)有自帶監(jiān)控工具并且市面上也沒(méi)有它的監(jiān)控工具，可以采用JVM的監(jiān)控來(lái)監(jiān)控一些最基本的信息（JVM線(xiàn)程、GC等）。這種主要是通過(guò)Java自帶的JMX以及一些中間件的JMX接口查詢(xún)。可以通過(guò)Jconsole遠(yuǎn)程查看，開(kāi)源的話(huà)，Zabbix也可以收集的到，不過(guò)要自制模板。
3）應(yīng)用的監(jiān)控
APM是Application performance management的簡(jiǎn)稱(chēng)。
有時(shí)候中間件沒(méi)有定制的監(jiān)控工具，同時(shí)又覺(jué)得JVM的監(jiān)控信息太少，有時(shí)候單從中間件的監(jiān)控中不足以分析應(yīng)用的性能問(wèn)題、數(shù)據(jù)關(guān)聯(lián)，可以采用Pinpoint、Glowroot、dynatrace等工具。這類(lèi)工具采用插針的方式，在java代碼中插針，可以在吞吐量不是特別巨大的時(shí)候，監(jiān)控現(xiàn)在每一步的執(zhí)行干什么、響應(yīng)時(shí)間、數(shù)據(jù)關(guān)聯(lián)等等。但由于是采用插針?lè)绞剑谕掏铝刻貏e大的時(shí)候，這種應(yīng)用性能管理工具反而不太好使了。
如果想看最全面的性能數(shù)據(jù)，中間件自帶的工具無(wú)疑是最好的，例如WAS監(jiān)控有自帶模塊“性能監(jiān)控基礎(chǔ)結(jié)構(gòu)（PMI）”，并且輔以PerformanceTuningToolkit來(lái)做后期展示。對(duì)于大規(guī)模集群的監(jiān)控，只能是運(yùn)維級(jí)別的監(jiān)控，即大面上看一看（不像性能分析那么細(xì)致），這個(gè)應(yīng)用還活不活著，有沒(méi)有隊(duì)列堆積，資源利用率等等。例如webshpere采用IBM的itcam比較配套，正所謂原湯化原食，雖然我并不覺(jué)得ITCAM好用。開(kāi)源的優(yōu)秀代表比如zabbix，它可以提供分布式系統(tǒng)監(jiān)視以及網(wǎng)絡(luò)監(jiān)視功能的企業(yè)級(jí)的開(kāi)源解決方案。
如果從大的系統(tǒng)性能角度，需要看響應(yīng)時(shí)間、吞吐量、資源利用率、交易成功率這幾個(gè)重要的指標(biāo)。這幾個(gè)指標(biāo)都是可以從中間件中觀(guān)察到的。只不過(guò)這些指標(biāo)我們往往不從中間件中監(jiān)控。例如，響應(yīng)時(shí)間、吞吐量往往從用戶(hù)的端到端計(jì)算，或者從日志里面計(jì)算，資源利用率從操作系統(tǒng)層面監(jiān)控。這里介紹的指標(biāo)是中間件特有的監(jiān)控指標(biāo)。
最重要、最直觀(guān)的指標(biāo)就是響應(yīng)時(shí)間：這里的響應(yīng)時(shí)間指的是業(yè)務(wù)在中間件中的響應(yīng)時(shí)間。
例如WAS可以監(jiān)控到眾多的這方面的響應(yīng)時(shí)間，有
1）ServiceTime：完成servlet請(qǐng)求的平均響應(yīng)時(shí)間（毫秒），
2）ResponseTime：接收到請(qǐng)求和對(duì)方應(yīng)答之間的平均時(shí)間，
3）RequestResponseTime：接到請(qǐng)求與分派執(zhí)行之間的時(shí)間，
4）DispatchResponseTime：從分派執(zhí)行到返回應(yīng)答之間的平均時(shí)間。
5）等等
可以先關(guān)注ResponseTime（接收到請(qǐng)求和應(yīng)答之間的平均時(shí)間），如果這個(gè)值出現(xiàn)異常，那就說(shuō)明業(yè)務(wù)在中間件中的這段處理可能有問(wèn)題，這段時(shí)間包括了收到請(qǐng)求到分配執(zhí)行的時(shí)間，包括了應(yīng)用等待數(shù)據(jù)庫(kù)連接池的時(shí)間、包括中間件調(diào)用數(shù)據(jù)庫(kù)執(zhí)行時(shí)間等等，然后我們?cè)俜侄畏治瞿睦锍霈F(xiàn)了問(wèn)題。如果ResponseTime較長(zhǎng)，收到請(qǐng)求到分配執(zhí)行的時(shí)間很長(zhǎng)或者等待數(shù)據(jù)庫(kù)連接池的時(shí)間很長(zhǎng)，而從數(shù)據(jù)庫(kù)上查看SQL的執(zhí)行時(shí)間很短，那么八成就是中間件里面的時(shí)間長(zhǎng)了，需要重點(diǎn)關(guān)注其他的中間件當(dāng)中的指標(biāo)了。
其他比較常關(guān)注的指標(biāo)包括：
ConcurrentRequests：并發(fā)處理的請(qǐng)求數(shù)
RequestCount：servlet處理的請(qǐng)求總數(shù)。結(jié)合這個(gè)指標(biāo)和監(jiān)控的總時(shí)間，可以計(jì)算請(qǐng)求的吞吐量。
ErrorCount：錯(cuò)誤的數(shù)量。需要結(jié)合RequestCount計(jì)算錯(cuò)誤的比例。
PoolSize：連接池的大小
PercentUsed：正在使用的池的平均百分率
WaitTime：在允許連接之前的平均等待時(shí)間（單位毫秒）。如果這個(gè)值不為0，并且等待時(shí)間較長(zhǎng)，需結(jié)合PercentUsed和WaitingThreadCount來(lái)擴(kuò)大PoolSize。
WaitingThreadCount：等待連接的平均并發(fā)線(xiàn)程數(shù)
線(xiàn)程池有許多類(lèi)型，例如web容器線(xiàn)程池、ORB線(xiàn)程池、EJB異步線(xiàn)程池
池中配置的線(xiàn)程數(shù)。
ActiveCount：并發(fā)活動(dòng)的線(xiàn)程數(shù)
PercentUsed：正在使用的池的平均百分率，如果太大（超過(guò)80%，接近100%）那就說(shuō)明線(xiàn)程不足了。
HeapSize：JVM的堆大小
UsedMemory：JVM運(yùn)行時(shí)中的使用的內(nèi)存總量（KB）
ActiveCount：請(qǐng)求當(dāng)前訪(fǎng)問(wèn)的會(huì)話(huà)總數(shù)。在測(cè)試環(huán)境中，如果在穩(wěn)定的壓力面前，請(qǐng)求訪(fǎng)問(wèn)的會(huì)話(huà)數(shù)持久增長(zhǎng)，那么，很可能程序中沒(méi)有關(guān)閉會(huì)話(huà)的設(shè)置。最終會(huì)導(dǎo)致會(huì)話(huà)數(shù)不足，無(wú)法接受新的請(qǐng)求。
垃圾回收期間，1）占用CPU資源，2）業(yè)務(wù)的響應(yīng)時(shí)間略有影響。
因此垃圾回收的調(diào)用頻率比較重要。
GCIntervalTime：兩次垃圾回收調(diào)用之間的平均時(shí)間（毫秒）
GCTime：垃圾回收調(diào)用的平均持續(xù)時(shí)間（毫秒）
詳細(xì)可參考：
性能測(cè)試時(shí)需關(guān)注應(yīng)用中間件27個(gè)指標(biāo)和參數(shù)
一般來(lái)說(shuō)，jdbc延遲較高是因?yàn)閖dbc連接池?cái)?shù)量不足，應(yīng)用要連接數(shù)據(jù)庫(kù)，而連接不夠用了。但從這個(gè)案例的數(shù)據(jù)來(lái)看，最大連接池?cái)?shù)量180，當(dāng)前有104個(gè)連接是已經(jīng)連接了數(shù)據(jù)庫(kù)，這104個(gè)當(dāng)中，有19個(gè)是正在用的（即正在執(zhí)行sql），現(xiàn)成的可以用的就有104-19=85個(gè)，另外還有180-104=76個(gè)可以被后期產(chǎn)生。
但這種情況下竟然有40個(gè)線(xiàn)程正在等待“數(shù)據(jù)庫(kù)連接池“，平均等待時(shí)間5527毫秒。
可能性分析
1）weblogic的bug，咨詢(xún)廠(chǎng)商，查詢(xún)相關(guān)bug，必要時(shí)升級(jí)weblogic
2）整個(gè)weblogic系統(tǒng)處于半僵死狀態(tài)。
有資源（85個(gè)現(xiàn)成的連接）不用，往往是系統(tǒng)慢到了驚人的程度。建議檢查系統(tǒng)資源利用情況。操作系統(tǒng)層面，內(nèi)存是否有page space in/out，例如aix看看pgsin/pgsin有沒(méi)有非0的度數(shù)jvm的內(nèi)存是否瀕臨耗盡，系統(tǒng)不停的做垃圾回收（GC）系統(tǒng)分區(qū)的CPU分配過(guò)低，比如只分配了0.1顆cpu，CPU利用率90%以上。其他系統(tǒng)資源接近是否飽和。
可以通過(guò)查看垃圾回收日志中剩余內(nèi)存的大小或者已用內(nèi)存的大小進(jìn)行初步判斷，如果JVM的空閑內(nèi)存一直在減小，那么結(jié)可能存在內(nèi)存溢出（在垃圾回收日志中是可以看出哪些是fullGCC，哪些是minorGC的，而且如果沒(méi)有內(nèi)存溢出的話(huà)，fullGC后，空閑內(nèi)存會(huì)有較大提升，所以看垃圾回收日志是可以看出一些內(nèi)存溢出的端倪的。）。如果發(fā)現(xiàn)有內(nèi)存溢出的隱患時(shí)，可以通過(guò)kill -3或者wsadmin命令生成內(nèi)存轉(zhuǎn)儲(chǔ)文件，使用IBM提供的HA工具對(duì)內(nèi)存轉(zhuǎn)儲(chǔ)文件進(jìn)行分析，嘗試找到溢出點(diǎn)，并進(jìn)行修改。
如果實(shí)在找不到問(wèn)題原因，并且在垃圾回收日志中可以看到有內(nèi)存溢出的跡象，那么就要制定定期重啟WAS的機(jī)制了，然后一直到找到問(wèn)題為止。
三、 優(yōu)化
業(yè)務(wù)系統(tǒng)的性能上不去（具體表現(xiàn)在吞吐量低，響應(yīng)時(shí)間長(zhǎng)）等現(xiàn)象，不少是應(yīng)用中間件導(dǎo)致的。
例如系統(tǒng)的處理能力上不去，加了WAS并發(fā)也不管用，cpu利用率上不去。然后仔細(xì)一問(wèn)，加了什么并發(fā)，回答說(shuō)“負(fù)責(zé)去MQ隊(duì)列讀消息的應(yīng)用進(jìn)程數(shù)”，我問(wèn)“連數(shù)據(jù)庫(kù)的jdbc連接池?cái)?shù)量呢”，回答說(shuō)“不知道”。這說(shuō)明不少人對(duì)中間件的參數(shù)以及它的作用并不是很清楚。
跑在應(yīng)用中間件上的應(yīng)用是委托“中間件”來(lái)處理“應(yīng)用”與外界的一切聯(lián)系，比如
1）有請(qǐng)求進(jìn)來(lái)，我有多少個(gè)session來(lái)服務(wù)于請(qǐng)求
2）應(yīng)用需要讀寫(xiě)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)連接由應(yīng)用中間件負(fù)責(zé)，并且還放置了連接池。
3）應(yīng)用需要多少內(nèi)存，由中間件定制
4）應(yīng)用需要做GC，由中間件定制
5）等等
可以把這個(gè)中介（中間件）看做是應(yīng)用和外界聯(lián)系的一個(gè)管子，或者多個(gè)管子（每個(gè)管子負(fù)責(zé)某一方面的聯(lián)系）。
如果這個(gè)管子太細(xì)，比如數(shù)據(jù)庫(kù)jdbc連接池的太小，就不足以滿(mǎn)足應(yīng)用與數(shù)據(jù)庫(kù)的頻繁溝通。這樣前端就會(huì)積壓大量的業(yè)務(wù)等待處理，而后端又不給力，導(dǎo)致了等待“數(shù)據(jù)庫(kù)連接”的時(shí)間變得特別長(zhǎng)（也就是響應(yīng)時(shí)間增加），響應(yīng)時(shí)間增加后，單位時(shí)間呃逆處理的業(yè)務(wù)數(shù)量減少，也就是吞吐量下降。
上面的例子是前面的管子太粗，把大量的請(qǐng)求放進(jìn)來(lái)，跑到了應(yīng)用服務(wù)器上，而后面的管子（數(shù)據(jù)庫(kù)連接）太細(xì)。
假如說(shuō)這時(shí)候把后面的管子放的足夠大會(huì)出現(xiàn)什么結(jié)果呢？ 也許性能優(yōu)化的還不錯(cuò)，也許就出現(xiàn)災(zāi)難（也就是所謂的負(fù)優(yōu)化），本來(lái)一秒鐘還能處理10筆業(yè)務(wù)，結(jié)果，大量業(yè)務(wù)沖到數(shù)據(jù)庫(kù)上，把數(shù)據(jù)庫(kù)壓癱了，一筆業(yè)務(wù)能也處理不了了。
競(jìng)爭(zhēng)劇烈的時(shí)候（大量業(yè)務(wù)搶一個(gè)或幾個(gè)小管子）就會(huì)有等待超時(shí)（例如設(shè)置了進(jìn)程等待資源超過(guò)xx秒就超時(shí)，進(jìn)程自殺），或者僵死（擁有A資源，等待B資源，而另一個(gè)業(yè)務(wù)擁有B資源，等待A資源），這就造成了交易失敗。這也是為什么所有系統(tǒng)在吞吐量高到一定程度的時(shí)候就會(huì)出現(xiàn)交易成功率不再是100%的現(xiàn)象。
再比如設(shè)置GC太頻繁，會(huì)導(dǎo)致應(yīng)用總會(huì)有停頓，停下來(lái)做那個(gè)GC，而忘了應(yīng)該干的正經(jīng)事。
目標(biāo)是把耗費(fèi)在中間件的時(shí)間縮短（提升用戶(hù)體驗(yàn)），提高整個(gè)應(yīng)用服務(wù)器的吞吐量。
說(shuō)到優(yōu)化，往往用到的詞是調(diào)優(yōu)，既然是調(diào)優(yōu)，就是case by case的調(diào)，N個(gè)參數(shù)這個(gè)一會(huì)兒調(diào)高，那個(gè)一會(huì)兒調(diào)低。中間件的參數(shù)也是這樣，參數(shù)很多，互相牽制。參數(shù)有默認(rèn)的設(shè)置，根據(jù)自身系統(tǒng)運(yùn)行的情況，可以進(jìn)行調(diào)節(jié)，不能太大也不能太小，找到一個(gè)接近最優(yōu)的組合。
一般情況下，一個(gè)新的系統(tǒng)隆重出場(chǎng)，安裝上之后，參數(shù)都是默認(rèn)。所有調(diào)優(yōu)的起點(diǎn)都是這套默認(rèn)的參數(shù)。然后根據(jù)預(yù)期的性能模型（例如并發(fā)用戶(hù)數(shù)、操作頻度、業(yè)務(wù)類(lèi)型、吞吐量等等）施加壓力。如果是已經(jīng)在生產(chǎn)上運(yùn)行的系統(tǒng)，那么可以直接在業(yè)務(wù)高峰期抓取監(jiān)控信息。
根據(jù)各個(gè)監(jiān)控指標(biāo)看看哪個(gè)指標(biāo)不夠用了，例如jdbc連接池利用率90%，jdbc連接等待時(shí)間較長(zhǎng)，那就謹(jǐn)慎考慮是否增大jdbc連接池的數(shù)量。但前提是，調(diào)整某一個(gè)指標(biāo)，需要考慮對(duì)其副作用。例如，如果數(shù)據(jù)庫(kù)這時(shí)候資源利用率很高，SQL語(yǔ)句執(zhí)行時(shí)間較長(zhǎng)，這時(shí)候如果把jdbc連接池這個(gè)大口子給打開(kāi)了，會(huì)導(dǎo)致災(zāi)難性后果，要么就是吞吐量更低了、響應(yīng)時(shí)間更長(zhǎng)了，要么就是系統(tǒng)癱瘓了。
再例如，會(huì)話(huà)數(shù)、線(xiàn)程數(shù)到達(dá)最大值，接收不了新請(qǐng)求了，要么增大會(huì)話(huà)數(shù)、線(xiàn)程數(shù)看看，要么縮短每個(gè)會(huì)話(huà)的時(shí)間。如果增加會(huì)話(huà)數(shù)、線(xiàn)程數(shù)，就要考慮這個(gè)應(yīng)用服務(wù)器現(xiàn)在的資源利用情況能不能撐住更多的業(yè)務(wù)，后端的數(shù)據(jù)庫(kù)能不能撐住更多的業(yè)務(wù)。
增大這些指標(biāo)有一個(gè)終極影響，就算別的影響都沒(méi)有，占用更多的內(nèi)存總是有的吧。這一點(diǎn)和增大高速緩存、數(shù)據(jù)源語(yǔ)句緩存大小有點(diǎn)像。這里的性能提高了，而別的地方因?yàn)槿鄙賰?nèi)存而性能下降了，沒(méi)準(zhǔn)整體的性能也下降了。
如果是生產(chǎn)環(huán)境的調(diào)優(yōu)，一定要評(píng)估其影響后，采用漸進(jìn)的方式調(diào)，即目標(biāo)是從10調(diào)到50，但一次只增加一點(diǎn)，10-20-30-40-50，這樣慢慢調(diào)上來(lái)，這樣不至于因?yàn)槲粗蛞幌伦影严到y(tǒng)拖垮。
另外，調(diào)什么參數(shù)，一定要了解其含義、原理、調(diào)整后的收益和風(fēng)險(xiǎn)是什么，最好是N個(gè)參數(shù)能在腦子里纏繞為一個(gè)整體。
具體指標(biāo)含義及對(duì)性能的影響可以參考本次線(xiàn)上交流的分享“應(yīng)用中間件概念及關(guān)注指標(biāo)” http://www.talkwithtrend.com/Article/216337
如果覺(jué)得這些指標(biāo)太多，還要一個(gè)有優(yōu)先級(jí)的甩干版，如下：
高優(yōu)先：調(diào)整JDBC連接池大小、線(xiàn)性池（N種線(xiàn)程池）、JVM虛擬機(jī)的heapsize
中優(yōu)先：會(huì)話(huà)數(shù)、垃圾回收GC策略
另外還有高速緩存、數(shù)據(jù)源語(yǔ)句緩存大小
有人咨詢(xún)：什么有效辦法避免中間件實(shí)例hang死？
首先咱們分析下可能造成hang的原因
1）中間件bug
2）硬件資源不足
例如，jvm的heapsize太小，不足以運(yùn)行這個(gè)應(yīng)用服務(wù)器。這種情況就是加資源
3）應(yīng)用邏輯導(dǎo)致
例如內(nèi)存泄露，這個(gè)很難定位。但很好解決--restart。所以我見(jiàn)過(guò)很多企業(yè)的系統(tǒng)有定期重啟的運(yùn)維策略。所以?xún)?nèi)存資源充足的定義是：在下次系統(tǒng)重啟之前內(nèi)存沒(méi)有被耗盡。
避免的方法，1）定期重啟，2）采用集群，掛了一個(gè)不要緊，只要不是同時(shí)掛就行。
4）資源爭(zhēng)用導(dǎo)致
不當(dāng)?shù)呐渲靡矔?huì)導(dǎo)致中間件處于假死狀態(tài)。比如某類(lèi)資源（session或jdbc）被應(yīng)用完全占滿(mǎn)了，并且短期不釋放，這樣新的請(qǐng)求就沒(méi)法執(zhí)行，造成了假死的情況。這類(lèi)情況，要做好超時(shí)放棄的參數(shù)配置。
從上面的分析可以看出，除了調(diào)應(yīng)用bug，找廠(chǎng)商解決bug，增加硬件資源，調(diào)整中間件參數(shù)之外，還可以有的方法是系統(tǒng)架構(gòu)設(shè)計(jì)層面和運(yùn)維策略。
系統(tǒng)架構(gòu)設(shè)計(jì)層面：采用集群是個(gè)解決問(wèn)題的大招。IT行業(yè)從上世紀(jì)的硬件高可用轉(zhuǎn)變?yōu)榻裉斓能浖刂频母呖捎?，就是要解決各種解不了的問(wèn)題。
運(yùn)維設(shè)計(jì)策略：定期restart也是解決問(wèn)題的大招。
楊建旭 現(xiàn)任中國(guó)人民銀行清算總中心性能測(cè)試團(tuán)隊(duì)負(fù)責(zé)人，高級(jí)技術(shù)經(jīng)理。具有Linux/FreeBSD/Windows/MacOS/iOS等平臺(tái)的開(kāi)發(fā)經(jīng)驗(yàn)，并在自動(dòng)化測(cè)試、性能測(cè)試方面有深入的研究，對(duì)銀行業(yè)系統(tǒng)（z/OS、AIX、DB2、Oracle、WAS、MQ等），尤其是虛擬化趨勢(shì)下銀行業(yè)系統(tǒng)的性能測(cè)試、問(wèn)題分析、性能調(diào)優(yōu)有豐富的經(jīng)驗(yàn)。
聯(lián)系客服
