| “疾病” |
描述 |
征兆 |
原因或解決方法 |
| 內(nèi)存泄漏呈線性增長(zhǎng) |
各單元（如每個(gè)事務(wù)或每個(gè)用戶(hù)等）的內(nèi)存泄漏，導(dǎo)致內(nèi)存使用率隨時(shí)間或負(fù)載的增加呈線性增長(zhǎng)。系統(tǒng)性能隨時(shí)間或負(fù)載的增加大幅下降，重啟后系統(tǒng)可恢復(fù)正常 |
系統(tǒng)性能隨時(shí)間的增加逐漸下降, 系統(tǒng)性能隨負(fù)載的增加逐漸下降 |
雖然有許多外在因素存在（如各單元數(shù)據(jù)的鏈表存儲(chǔ)、尚未回收的緩沖中的回收或增長(zhǎng)操作等），但最為常見(jiàn)的原因還是資源泄漏 |
| 內(nèi)存泄漏呈指數(shù)級(jí)增長(zhǎng) |
內(nèi)存泄漏呈雙倍增長(zhǎng)，導(dǎo)致系統(tǒng)內(nèi)存消耗隨時(shí)間呈指數(shù)曲線變化 |
系統(tǒng)性能隨時(shí)間的增加逐漸下降,系統(tǒng)性能隨負(fù)載的增加逐漸下降 |
雖然有許多外在因素存在（如各單元數(shù)據(jù)的鏈表存儲(chǔ)、尚未回收的緩沖中的回收或增長(zhǎng)操作等），但最為常見(jiàn)的原因還是資源泄漏 |
| 導(dǎo)致無(wú)限循環(huán)的編碼缺陷 |
線程在while語(yǔ)句返回值為真的情況下發(fā)生阻塞， 將最終演變成為CPU密集型和等待密集型或螺旋等待變量 |
可預(yù)見(jiàn)的死鎖 |
需要進(jìn)行侵入式循環(huán)切除 |
| 資源泄漏 |
JDBC語(yǔ)句、CICS事務(wù)網(wǎng)關(guān)連接等出現(xiàn)資源泄漏，引發(fā)Java橋接層和后臺(tái)系統(tǒng)出現(xiàn)嚴(yán)重性能問(wèn)題 |
系統(tǒng)性能隨時(shí)間的增加逐漸下降, 可預(yù)見(jiàn)的死鎖, 系統(tǒng)突然出現(xiàn)混亂 |
通常是由于遺漏了Finally模塊，或者只是沒(méi)有用close函數(shù)關(guān)閉代表外部資源的對(duì)象 |
| 外部瓶頸 |
后臺(tái)或其它外部系統(tǒng)（如用戶(hù)驗(yàn)證）運(yùn)行緩慢，大大影響J2EE應(yīng)用服務(wù)器及應(yīng)用程序的運(yùn)行速度 |
系統(tǒng)持續(xù)緩慢運(yùn)行, 系統(tǒng)性能隨負(fù)載的增加逐漸下降 |
向?qū)＜遥ò煽康牡谌交蛳到y(tǒng)管理員等）咨詢(xún)特定外部瓶頸問(wèn)題的有效解決方法 |
| 外部系統(tǒng)的過(guò)度使用 |
J2EE應(yīng)用程序發(fā)送的請(qǐng)求過(guò)大過(guò)多，濫用后臺(tái)系統(tǒng)資源 |
系統(tǒng)持續(xù)緩慢運(yùn)行, 系統(tǒng)性能隨負(fù)載的增加逐漸下降 |
消除冗余的工作請(qǐng)求，分批處理同類(lèi)工作請(qǐng)求，把大請(qǐng)求細(xì)分為若干個(gè)小請(qǐng)求，調(diào)整工作請(qǐng)求或后臺(tái)系統(tǒng)（例如為公共查詢(xún)的關(guān)鍵字建立索引）等 |
| 頻繁調(diào)用CPU密集型組件的編碼缺陷 |
J2EE領(lǐng)域的通病是：些許編碼缺陷或少量編碼的交互失敗，都會(huì)令CPU掛起，從而將數(shù)據(jù)流量速度降至蝸行 |
系統(tǒng)持續(xù)緩慢運(yùn)行, 系統(tǒng)性能隨負(fù)載的增加逐漸下降 |
最好的解決方法是將數(shù)據(jù)存儲(chǔ)在本地緩存中，或者為執(zhí)行算法配備高速緩沖存儲(chǔ)器 |
| 橋接層本身存在的問(wèn)題 |
橋接層（如JDBC驅(qū)動(dòng)、CORBA到遺留系統(tǒng)的連接等）存在執(zhí)行缺陷。需要不斷對(duì)數(shù)據(jù)和請(qǐng)求作編組和取消編組操作，導(dǎo)致該層的數(shù)據(jù)流量速度降至蝸行。這種故障現(xiàn)象在早期階段與外部瓶頸極為相似 |
系統(tǒng)持續(xù)緩慢運(yùn)行, 系統(tǒng)性能隨負(fù)載的增加逐漸下降 |
檢查橋接層與外部系統(tǒng)的版本是否兼容。如果可能的話，對(duì)不同橋接供應(yīng)商進(jìn)行評(píng)估。通過(guò)重新規(guī)劃設(shè)計(jì)系統(tǒng)架構(gòu)，則可完全旁路橋接層 |
| 內(nèi)部資源瓶頸：資源的過(guò)度使用或分配不足 |
內(nèi)部資源（如線程、放入存儲(chǔ)池的對(duì)象等）匱乏，卻無(wú)法判斷是正常情況下隨負(fù)載增加而引起的資源過(guò)度使用，還是由于資源泄漏引起 |
系統(tǒng)性能隨負(fù)載的增加逐漸下降, 間發(fā)性的系統(tǒng)掛起或異常錯(cuò)誤 |
若因資源分配不足引起，則可依照最大預(yù)期負(fù)載值上調(diào)存儲(chǔ)池的最大容量；若因資源過(guò)度使用引起，請(qǐng)參看本表“外部系統(tǒng)的過(guò)度使用”一欄 |
| 不斷重試 |
失敗請(qǐng)求的頻繁重試（某些極端情況下將無(wú)休止重試） |
可預(yù)見(jiàn)的死鎖系統(tǒng)突然出現(xiàn)混亂 |
后臺(tái)系統(tǒng)可能已經(jīng)完全宕機(jī)。監(jiān)控系統(tǒng)可用性對(duì)這樣的狀況有所幫助，也可以只是將多次重復(fù)嘗試的請(qǐng)求從成功的請(qǐng)求中篩選出來(lái) |
| 線程阻塞點(diǎn) |
線程退回到無(wú)法完成的同步點(diǎn)，造成通信阻塞 |
系統(tǒng)性能隨負(fù)載的增加逐漸下降, 間發(fā)性的系統(tǒng)掛起或異常錯(cuò)誤, 可預(yù)見(jiàn)的死鎖, 系統(tǒng)突然出現(xiàn)混亂 |
或許根本沒(méi)有必要進(jìn)行同步（只需對(duì)系統(tǒng)重新設(shè)計(jì)稍加改良），當(dāng)然也可以定制一些外在的鎖定策略（如讀取器或?qū)懭肫鞯淖x/寫(xiě)鎖） |
| 線程的死鎖或活鎖 |
通常只是“獲取順序”問(wèn)題 |
系統(tǒng)突然出現(xiàn)混亂 |
解決方法選項(xiàng)包括主鎖、即定的獲取順序以及銀行家算法 |
| 網(wǎng)絡(luò)飽和 |
等待時(shí)間長(zhǎng)或基本無(wú)法將任何請(qǐng)求打包，導(dǎo)致系統(tǒng)異常停運(yùn)、系統(tǒng)掛起或活鎖等情況的出現(xiàn) |
系統(tǒng)持續(xù)緩慢運(yùn)行, 系統(tǒng)性能隨負(fù)載的增加逐漸下降, 間發(fā)性的系統(tǒng)掛起或異常錯(cuò)誤 |
如此棘手的問(wèn)題正在侵蝕著網(wǎng)絡(luò)系統(tǒng)，如果不及時(shí)升級(jí)系統(tǒng)的基礎(chǔ)架構(gòu)，提升網(wǎng)絡(luò)及路由器的運(yùn)行速度，將無(wú)法扼制日后類(lèi)似問(wèn)題的出現(xiàn) |
