系統(tǒng)應用服務器內存溢出解決報告(新)

1、所謂的光輝歲月，并不是以后，閃耀的日子，而是無人問津時，你對夢想的偏執(zhí)。XXX系統(tǒng)應用服務器內存溢出解決報告XXXX股份有限公司2010.9目錄第一章問題現(xiàn)象與分析21.1、 問題現(xiàn)象21.2、 通常導致這種現(xiàn)象的原因 21.3、 xxx 社保宕機現(xiàn)象對比分析 3第二章解決方法路線圖 42.1 jvm 的調整42.2 減少jvm 內存使用52.2.1 加快db訪問速度，減少中間件并發(fā)業(yè)務量 52.2.2 限制sql返回結果集62.2.3 減少業(yè)務會話中存放的對象 62.3補救措施6第三章、解決結果與進一步建議 63.1 解決結果63.2進一步建議7第一章問題現(xiàn)象與分析1.1、問題現(xiàn)象XXX應用

2、服務器經(jīng)常有內存溢出、系統(tǒng)沒有響應的現(xiàn)象，尤其在每月的月末最為明顯。 目前的應用服務器有三種類型，其中ibm和linux應用服務器報告頻繁出現(xiàn)內存溢出或沒有響應的現(xiàn)象，hp un ix應用服務器相穩(wěn)定。在出現(xiàn)問題期間Weblogic無法響應任何 客戶端請求，大量請求加載到了這臺沒有響應的Server 上,最后只有殺掉并重啟這臺應用服務器。1.2、通常導致這種現(xiàn)象的原因WLS Server沒響應可能的幾種原因：放棄很簡單，但你堅持到底的樣子一定很酷!2所謂的光輝歲月，并不是以后，閃耀的日子，而是無人問津時，你對夢想的偏執(zhí)。1、 繁重的I/O，呼叫DB時間過長導致中間件內存耗盡，server沒有響

3、應。2、 程序死循環(huán)，loop backs，這種情況cpu很忙，系統(tǒng)沒有響應。3、連接到外部server，沒響應，由于網(wǎng)絡等原因4、2個以上的執(zhí)行者同步死鎖5、業(yè)務量過大，全部線程都被占用，出現(xiàn)隊列等待現(xiàn)象6、讀寫本地I/O，發(fā)生阻塞WLS Server 宕機的原因：?OutOfMemory JNI程序 jvm 的 bug os 的 bug1.3、XXX社保宕機現(xiàn)象對比分析?應用服務器沒有響應分析通過初步判斷，對于 xxx應用服務器沒有響應的情況可以做如下排出法解決： 程序死循環(huán)這種情況會導致 cpu非常繁忙，而通過目前觀察，每次系統(tǒng)沒響應的時候，cpu沒有一直100%忙，另外，對出現(xiàn)問題時的

4、java core分析沒有發(fā)現(xiàn)這類線程，因此可以基本排除這種可能，。連接到外部server ，沒響應，由于網(wǎng)絡等原因目前我們的業(yè)務基本都是直接通過中間件訪問數(shù)據(jù)，沒有通過應用服務器間調用或 多數(shù)據(jù)庫調用的，基本排除這種可能。2個以上的執(zhí)行者同步死鎖這種情況有可能，但比較難找，一般都是業(yè)務高峰的時候才有可能出現(xiàn)，跟應用人 員了解后得知我們很少使用同步方式實現(xiàn)對資源的共享。另外通過對javacore 進行分析，并未發(fā)現(xiàn)同步造成的死鎖現(xiàn)象。業(yè)務量過大，全部線程都被占用，出現(xiàn)隊列等待現(xiàn)象通過觀察我們的業(yè)務量在高峰時確實很大，但由于我們配置的線程數(shù)都很高，盡管 出現(xiàn)宕機時也沒有達到配置的上線，所以這個方

5、面可以被排除。繁重的I/O ，呼叫DB時間過長導致中間件內存耗盡由于我們經(jīng)常有新業(yè)務變更，尤其近期還有居民醫(yī)保業(yè)務上線，因此I/O問題導致放棄很簡單，但你堅持到底的樣子一定很酷！4所謂的光輝歲月，并不是以后，閃耀的日子，而是無人問津時，你對夢想的偏執(zhí)。的因素也需要重點考察！讀寫本地I/O ，發(fā)生阻塞，多線程耗盡 jvm內存這種現(xiàn)象很可能發(fā)生，應重點給予關注? 對WLS SERVER宕機的幾種情況的分析：OufOfMemory目前xxx社保應用服務器出現(xiàn)宕機的時候基本都表現(xiàn)為這種現(xiàn)象，這也是中間件服 務器最常見的現(xiàn)象。原因可能有多種，可能是平臺的，多數(shù)情況下是物理內存配置過低， 或jvm 參數(shù)配

6、置過低造成的。但通過對xxx社保配置參數(shù)進行分析發(fā)現(xiàn)參數(shù)基本合理，除了線程數(shù)和連接池配置稍大點，其它都很正常。由此分析是估計是其它原因造成的。其它可能的原因可能是平臺原因，比如jvm版本、垃圾回收方式和算法的缺陷等；也可能是應用造成的，比如業(yè)務并發(fā)量過大，內存不足造成，也可能是返回大結果集以 及會話存放對象過多等原因。因此重點是找出可行的解決方案，避免出現(xiàn)內存溢出，減 少對jvm內存的使用量。平臺 bug比如jni、jvm、os的bug等。每個 weblogic 版本都有對應的平臺 Jni，用來增加 系統(tǒng)性能，但有時表現(xiàn)出不穩(wěn)定的現(xiàn)象。Jvm和os版本對 WLS server的穩(wěn)定更是影響很大

7、，通過以前的記錄發(fā)現(xiàn)ibm和linux的應用服務器比hp出現(xiàn)的宕機頻率更多些，因此有必要對ibm 和linuxjvm 做些分析和調整。第二章解決方法路線圖通過前面分析把解決問題的路線圖定位在三方面，一個是調整現(xiàn)有平臺jvm版本和參數(shù)，盡量達到平臺的穩(wěn)定性；另外一個是考慮如何減少jvm內存的使用上，尤其要解決訪問DB慢以及返回大結果集這兩方面，以期通過增強訪問速度減少并發(fā)量，減少返回結果對內存的占 用，從而使系統(tǒng)不發(fā)生或少發(fā)生OutOfMemory現(xiàn)象。另外，在意外出現(xiàn)宕機的情況下，通過負載均衡器的配置實現(xiàn)新請求直接發(fā)送給其它運行正常的服務器。2.1 jvm 的調整采用方法：? 調整ibm應用服

8、務器的jvm系統(tǒng)參數(shù)kcluster等，消除內存碎片。? 調整linux應用服務器的jvm ，由bea的jrockit 到sun jdk 。實際效果:? Ibm服務器jvm為142，由于本版本的垃圾回收算法問題，會出現(xiàn)內存碎片，7月份相應調整了 jvm 參數(shù)，不過還是宕機很多次，沒有明顯效果。通過對8月份ibm 服務器一次宕機javacore 分析，發(fā)現(xiàn)在高峰階段jvm還是會出現(xiàn)heap lock 資源等待現(xiàn)象，經(jīng)查ibm資料，基本上還是證實是內存碎片過多，并發(fā)申請內存太多導 致系統(tǒng)無內存可用，最后宕機。不過8月份已經(jīng)好很多了，才發(fā)現(xiàn)一次。這種情況目前最好方法是通過減少并發(fā)量來解決，由于應用的

9、原因目前還無法升級jvm。?Linux服務器的jvm通過從jroick調整到sun后，在7月份就效果就很好。在8月份系統(tǒng)出現(xiàn)一次沒有響應了，當時內存還是剩余很多的，現(xiàn)象也是 OutOfMemory ，但同時報 sun javaException in thread "CompilerThreadO"java .Ian g.OutOfMemoryError:requested32760bytesforChu nkPool:allocate. Out of swap space?經(jīng)查這種現(xiàn)象跟在linux平臺上jvm虛擬機不穩(wěn)定有關，但這種現(xiàn)象不會經(jīng)常出現(xiàn)。2.2減少jvm內存

10、使用想辦法減少jvm內存使用量是解決問題的關鍵，減少應用服務器瞬時的并發(fā)量是一個好的途 徑，這就要保證快速的 DB訪問，小的結果集返回，session中少量的保存對象，同時會話保 持不宜過長。2.2.1 加快db訪問速度，減少中間件并發(fā)業(yè)務量采用方法1：通過oracle oem 等工具跟蹤監(jiān)控大量耗 I/O的語句，同時監(jiān)控其它影響 db服 務器運行慢的進程。實際效果：項目組調整低性能的 sql后，該部分業(yè)務明顯加快， 沒有再發(fā)現(xiàn)相關業(yè)務的大量全 表掃描等情況。采用方法2 :對影響應收預覽速度的ac40瘦身，重建并進行了分區(qū)。實際效果：根據(jù)現(xiàn)場反映速度有些提升。但由于對另外一個影響速度的關鍵表a

11、b30無法瘦身（醫(yī)保業(yè)務用），目前應收預覽速度要有質的飛躍還很難。222限制sql返回結果集采用方法：從底層編寫監(jiān)控 sql返回的大結果集程序，可定制記錄數(shù)等參數(shù)實際效果：目前已經(jīng)抓到很多大 sql，返回的結果集從幾千達到10幾萬以上，基本消除了大結果集造成的原因，長期部署可對新程序新業(yè)務的大結果集檢驗有非常大的好處。2.2.3減少業(yè)務會話中存放的對象采用方法：減少會話中的存放對象數(shù)，把沒有必要或不需要使用的對象從會話中清除。實際效果：這是一個備用手段，由于是改動了程序，為了生產(chǎn)安全考慮，暫時沒有部署，在 其它手段沒有效果的情況下經(jīng)過測試后再把它加載上去。2.3對本地讀寫的定位通過對大量ibm

12、 java core分析，發(fā)現(xiàn)有讀寫I/O導致的堵塞。2.4補救措施方法：在應用服務器上部署一個test.html靜態(tài)頁面，同時在負載均衡器上配置對這個靜態(tài)頁面的定時訪問。結果：通過8月份業(yè)務的實際運行考驗確實起到了作用，7月份當一臺服務器沒有響應的時候馬上就有業(yè)務人員反映， 8月份卻沒有，同時我們也發(fā)現(xiàn)了的確新的請求就不再發(fā)給問 題服務器，重新啟動后新請求一點一點的加載上來，改善是很有效果的。第三章、解決結果與進一步建議3.1解決結果通過兩個月周期的現(xiàn)場分析、調整，目前應用服務器系統(tǒng)穩(wěn)定性已經(jīng)明顯提高了。盡管放棄很簡單，但你堅持到底的樣子一定很酷!8所謂的光輝歲月，并不是以后，閃耀的日子，而

13、是無人問津時，你對夢想的偏執(zhí)。 月底個別高峰的時候還會出現(xiàn)系統(tǒng)沒有響應情況，但通過其它手段彌補已經(jīng)不會影響業(yè)務的 運行。分析導致系統(tǒng)宕機因素是多方面的，包括java平臺的原因，程序大結果集的原因，表數(shù)據(jù)量大/sql程序不夠優(yōu)化的原因，陣列I/O性能的原因、并發(fā)大業(yè)務的等原因。這些原因往往交織在一起，呈現(xiàn)出各種系統(tǒng)宕機狀況。但最終只要我們提高sql的運行速度，降低jvm的內存使用量，把握好大的結果集和大的業(yè)務對象使用，盡管jvm本身有不穩(wěn)定的情況，也不會或很少出現(xiàn)jvm宕機現(xiàn)象的。3.2進一步建議? 優(yōu)化或升級現(xiàn)有陣列目前整體系統(tǒng)的瓶頸在 I/O上，希望考慮陣列升級計劃。 ? 對目前業(yè)務數(shù)據(jù)和程序做一個周期瘦身和優(yōu)化方案