專利名稱：基于jvm服務(wù)器的性能優(yōu)化方法
技術(shù)領(lǐng)域：
本發(fā)明涉及Java虛擬機(Java Virtual Machine, JVM)技術(shù)領(lǐng)域,特別涉及一種基于JVM服務(wù)器的性能優(yōu)化方法。
背景技術(shù)：
Java虛擬機中的對象共劃分為三個代:年輕代(Young Generation)、年老代(OldGeneration)和持久代(Permanent Generation)。其中持久代主要存放的是Java類的類信息，與垃圾回收(Garbage Collection, GC)要收集的Java對象關(guān)系不大。年輕代和年老代的劃分是對垃圾回收影響比較大的。年輕代:所有新生成的對象首先都是放在年輕代的。年輕代的目標就是盡可能快速的收集掉那些生命周期短的對象。年輕代分三個區(qū)。一個Eden區(qū),兩個Survivor區(qū)(一般而言)。大部分對象在Eden區(qū)中生成。當Eden區(qū)滿時,還存活的對象將被復(fù)制到Survivor區(qū)(兩個中的一個)，當這個Survivor區(qū)滿時,此區(qū)的存活對象將被復(fù)制到另外一個Survivor區(qū)，當這個Survivor區(qū)也滿了的時候，從第一個Survivor區(qū)復(fù)制過來的并且此時還存活的對象，將被復(fù)制到“年老區(qū)(Tenured)”。需要注意，Survivor的兩個區(qū)是對稱的，沒先后關(guān)系，所以同一個區(qū)中可能同時存在從Eden復(fù)制過來的對象,和從前一個Survivor復(fù)制過來的對象，而復(fù)制到年老區(qū)的只有從第一個Survivor區(qū)過來的對象。而且,Survivor區(qū)總有一個是空的(因為Survior區(qū)分兩個區(qū)，在復(fù)制的時候從sO到si復(fù)制完以后sO區(qū)里面的對象將被釋放，等待下一次YGC時再進行交換，從Si到sO所以每次總有一個s區(qū)是空的)。同時，根據(jù)程序需要，Survivor區(qū)是可以配置為多個的(多于兩個)，這樣可以增加對象在年輕代中的存在時間，減少被放到年老代的可能。年輕代的回收稱為YGC。年老代:在年輕代中經(jīng)歷了 N次垃圾回收后仍然存活的對象，就會被放到年老代中。因此，可以認為年老代中存放的都是一些生命周期較長的對象。年老代的回收稱為Full GC。持久代:用于存放靜態(tài)文件，如今Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應(yīng)用可能動態(tài)生成或者調(diào)用一些class,例如:Hibernate等,在這種時候需要設(shè)置一個比較大的持久代空間來存放這些運行過程中新增的類。針對線上服務(wù)器的系統(tǒng)以及所有應(yīng)用服務(wù)，在部署后沒有進行過系統(tǒng)優(yōu)化，在隨著應(yīng)用服務(wù)的增減，用戶數(shù)量的增減，會造成線上部分服務(wù)器壓力過大，以及部分服務(wù)器利用不充分，尤其是在垃圾回收方面，和內(nèi)存利用效率息息相關(guān)，因此需要優(yōu)化服務(wù)器的配置。

發(fā)明內(nèi)容
(一)要解決的技術(shù)問題
本發(fā)明要解決的技術(shù)問題是:線上部分服務(wù)器壓力過大，以及部分服務(wù)器利用不充分的問題。(二)技術(shù)方案為解決上述技術(shù)問題，本發(fā)明提供了一種基于JVM服務(wù)器的性能優(yōu)化方法，包括:S1:根據(jù)服務(wù)器的當前配置對服務(wù)器進行壓力測試，得到壓力測試結(jié)果；S2:判斷所述壓力測試結(jié)果是否滿足預(yù)先設(shè)定的閾值，若不滿足，則執(zhí)行步驟S3 ；若滿足，則使用當前配置作為優(yōu)化配置的結(jié)果；S3:調(diào)整服務(wù)器的當前配置參數(shù)，調(diào)整后執(zhí)行步驟SI。其中，所述壓力測試為在一段時間內(nèi)實時監(jiān)測配置參數(shù)的參數(shù)值，所述配置參數(shù)包括:垃圾回收參數(shù)。其中，所述步驟S3中包括:設(shè)置內(nèi)存大小、垃圾回收線程數(shù)及線程堆棧大小。其中，所述設(shè)置的垃圾回收線程數(shù)為CPU核的個數(shù)。其中，所述步驟S3中包括:設(shè)置JVM中的年輕代對象的Survivor區(qū)與Eden區(qū)比例。其中，所述步驟S3中包括:設(shè)置參數(shù)η，η為JVM中轉(zhuǎn)移到年老代的對象在年輕代中經(jīng)過垃圾回收的次數(shù)。其中，所述步驟S3中包括:設(shè)置JVM中年老代區(qū)的垃圾回收的次數(shù)。其中，所述步驟S3中包括:設(shè)置JVM中持久代區(qū)的存儲空間大小。其中，在壓力測試的過程中還包括并發(fā)執(zhí)行內(nèi)存碎片整理的過程。其中，所述步驟S3中包括:設(shè)置在進行m次年老代區(qū)的垃圾回收后進行所述內(nèi)存碎片整理。(三)有益效果本發(fā)明的基于JVM服務(wù)器的性能優(yōu)化方法通過對服務(wù)器的性能反復(fù)測試優(yōu)化，使得線上服務(wù)器壓力減小，以及部分服務(wù)器中資源得到充分利用。


圖1是本發(fā)明實施例的一種基于JVM服務(wù)器的性能優(yōu)化方法流程圖；圖2是對JVM服務(wù)器的性能優(yōu)化前的壓力測試結(jié)果圖；圖3是對JVM服務(wù)器的性能優(yōu)化前每秒點擊次數(shù)隨時間變化曲線圖；圖4是對JVM服務(wù)器的性能優(yōu)化后的壓力測試結(jié)果圖；圖5是對JVM服務(wù)器的性能優(yōu)化后內(nèi)存為4G時每秒點擊次數(shù)隨時間變化曲線圖；圖6是對JVM服務(wù)器的性能優(yōu)化后內(nèi)存為5G時每秒點擊次數(shù)隨時間變化曲線圖；圖7是對JVM服務(wù)器的性能優(yōu)化后內(nèi)存為8G時每秒點擊次數(shù)隨時間變化曲線圖。
具體實施例方式下面結(jié)合附圖和實施例，對本發(fā)明的具體實施方式
作進一步詳細描述。以下實施例用于說明本發(fā)明，但不用來限制本發(fā)明的范圍。如圖1所示，本發(fā)明的基于JVM服務(wù)器的性能優(yōu)化方法包括:步驟S101，根據(jù)服務(wù)器的當前配置對服務(wù)器進行壓力測試，得到壓力測試結(jié)果。
步驟S102，判斷壓力測試結(jié)果是否滿足預(yù)先設(shè)定的閾值，若不滿足，則執(zhí)行步驟S103 ;若滿足，執(zhí)行步驟S104。其中，閾值根據(jù)實際線上服務(wù)器的運行情況及用戶數(shù)量不同而不同。閾值的設(shè)定根據(jù)服務(wù)器能承受性能壓力的情況下，資源利用率達到最高，不浪費。步驟S103，調(diào)整服務(wù)器的當前配置參數(shù)，調(diào)整后執(zhí)行步驟S101。步驟S104，使用當前配置作為優(yōu)化配置的結(jié)果。本發(fā)明主要思想是根據(jù)壓力測試結(jié)果優(yōu)化JVM GC回收的相關(guān)參數(shù)，然后通過優(yōu)化后的壓力測試結(jié)果與線上配置進行比對，來檢查是否通過優(yōu)化而對項目本身的GC回收情況、網(wǎng)絡(luò)吞吐情況、單位時間(秒)點擊率、以及系統(tǒng)實時壓力情況(CPU、內(nèi)存、磁盤)有所提升，本發(fā)明主要將單位時間(秒)點擊率作為壓力測試主要指標，以下通過測試項目來具體說明本發(fā)明的方法，其中，機器硬件信息:CPU:1ntel (R) Xeon (R) CPU E5620i2.40GHz 4 核，8 通道，內(nèi)存:24G。軟件信息:系統(tǒng):CentOS 5.664位內(nèi)核版本:2.6.18-238.12.1.el5Tomcat:Apache Tomcat/6.0.29Jdk: java version “ 1.6.0_16” 64 位壓力測試軟件:Loadrunner上述步驟中主要測試以下參數(shù)，參數(shù)值是線上JVM初始化配置:JAVA_0PTS = " $JAVA_0PTS-server-Xms6144M-Xmx6144M-Xmn4096M-XX:PermSize=6OOM-XX:MaxPermSize = 300M-XX:SurvivorRatio = 65536-XX:MaxTenuringThreshold=O-Xnoclassgc-XX:+DisableExplicitGC-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+UseCMSCompactAtFuI IColIection-XX:CMSFulIGCsBeforeCompaction =1-XX:+CMSClassUnloadingEnabled -XX:-CMSParaIIelRemarkEnabIe d-XX: CMSInitiatingOccupancyFraction = 40-XX:SoftRefLRUPoIicyMSPerMB = O-XX:+PrintGCDetails-XX:+PrintGCTimeStamps:/backup/common-logs/gc_8080.log"上述線上配置分析如下:I)-XX:SurvivorRatio:此參數(shù)設(shè)置為設(shè)置年輕代中Eden區(qū)與Survivor區(qū)的大小比值。通常為6或者4，兩個Survivor區(qū)與一個Eden區(qū)的通常配置為比值為2: 6或者2: 4，也就是說一個Survivor區(qū)占整個年輕代的1/8或者1/6，而線上配置為-XX: SurvivorRatio = 65536,是比較流行的放棄Survivor區(qū)從而增加Eden區(qū)內(nèi)存大小的方式，延長了 YGC回收時間。2)-XX: PermSize = 600M 但是-XX:MaxPermSize = 300M 才設(shè)置 300，這里的配置
存在問題。3) -XX:MaxTenuringThreshold = 0 指定一個 object 在經(jīng)歷了 n 次 YGC 后轉(zhuǎn)移到年老代區(qū)，設(shè)置是0，也就是說每次YGC回收都會把一些長周期的對象丟入年老代區(qū)，增加了年老代區(qū)累計也就是增加了 full GC回收次數(shù)。4) -Xnoclassgc 關(guān)閉針對 class 的 GC 功能；5)-XX:+DisableExplicitGC禁止 java程序中的Full GC,如System, gc ()的調(diào)用。設(shè)置該參數(shù)是禁止由于程序員調(diào)用System, gc ()引起的手動GC，以防止在代碼里誤用，對性能造成沖擊。6)-XX:+UseParNewGC設(shè)置年輕代為并行收集。7)-XX:+UseConcMarkSwe印GC設(shè)置年老帶為多線程并行FulI GC。8)-XX:+UseCMSCompactAtFulICollection 在使用 concurrent gc 的情況下，防止memory fragmention,對 live object 進行整理，使 memory 碎片減少。9) -XX:CMSFulIGCsBeforeCompaction 表示執(zhí)行 N 次 Full GC 后執(zhí)行內(nèi)存壓縮。10)-XX: +CMSParallelRemarkEnabled 在使用 UseParNewGC 的情況下，盡量減少mark的時間。11) -XX: CMSInitiatingOccupancyFraction設(shè)置年老代空間達到預(yù)定的百分比時進行 Full GC。上述壓力測試為在一段時間內(nèi)實時監(jiān)測配置參數(shù)的參數(shù)值，利用Tomcat對JVM進行實時監(jiān)控，如圖2所示。線上Survivor區(qū)設(shè)置為0,沒有被占用所以這里很明顯，回收過程沒有Survivor區(qū)交替。Eden區(qū)設(shè)置為4G空間，YGC 一共執(zhí)行了 242次共消耗15.466s，平均每次YGC回收時間為0.0640s。年老代區(qū)分配2G 空間，但是-XX: CMSIni tiatingOccupancyFract ion 設(shè)置為 40 所以年老代區(qū)每次都沒有被充分利用的情況下就進行了 Full GC。年老代區(qū)一共執(zhí)行了 26次Full GC，耗時22.060s，平均每次Full GC時間為
0.848s。Perm區(qū)線上設(shè)置300M，從整個壓力測試過程來看測試項目所利用的持久代區(qū)只有64M，可以釋放持久代perm區(qū)。采用壓力測試工具Loadrunner監(jiān)測每秒事務(wù)處理量(TransactionPerSecond,TPS)，如圖3所示。從圖3中可看出服務(wù)器很不穩(wěn)定，秒級并發(fā)均值在450左右。隨著用戶的增加，響應(yīng)速度逐漸變慢，當達到1060的時候，開始報錯。監(jiān)測系統(tǒng)情況，系統(tǒng)Load值維持在3-4之間相對穩(wěn)定，隨著用戶數(shù)的增加CPU處理存在等待。(此處的load指的是Iinux系統(tǒng)cpu負載值1adavg為3_4，前面有提到系統(tǒng)的配置CPU為4核、8通道，這個load值如果超過通道數(shù)“8”，則視為系統(tǒng)負載處于臨界警告，可能會出現(xiàn)機器負載過高而導(dǎo)致死機)。監(jiān)測壓力過程中應(yīng)用現(xiàn)象，在用戶達到650的時候，響應(yīng)速度迅速變慢。點擊部分頁面等待時間較長，當用戶數(shù)超過1000后會出現(xiàn)報錯，點擊每個頁面，等待時間都在8-10秒。上述配置導(dǎo)致服務(wù)器壓力過大，需要優(yōu)化配置如下:JAVA_0PTS = " $JAVA_0PTS-Dcom.sun.management.jmxremote-Dcom.sun.management, jmxremote.Port = 9004-Dcom.sun.management, jmxremote, authenticate=false-Dcom.sun.management, jm xremote.ssl = false-Djava.rm1.server, hostname=10.10.110.113-server-Xms4096M-Xmx4096M-Xmn2048M-Xss256k-XX:PermSize =150M-XX:MaxPermS i z e = 150M-XX:ParalIeIGCThreads = 8-XX:SurvivorRatio = 18-Xnoclassgc-XX:MaxTenuringThreshold = 10-XX:+DisableExplicitGC-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+UseCMSCompactAtFulIColIection-XX:CMSFulIGCsBeforeCompaction = 5-XX:+CMSClassUnloadingEnabled-XX:+CMSParalIelRemarkEnabled-XX:CMSInitiatingOccupancyFraction = 80-XX:SoftRefLRUPoIicyMSPerMB = O-XX:+PrintGCDetaiIs-XX:+PrintGCTimeStamps-Xloggc:/backup/common-logs/gc_8080.log"上述優(yōu)化配置分析。1.-XX:ParallelGCThreads:設(shè)置GC回收線程數(shù)，根據(jù)服務(wù)器CPU數(shù)來確認。(幾核CPU就設(shè)置為幾)。充分利用cpu資源。i1.-XX: SurvivorRatio = 18設(shè)置Survivor區(qū)與Eden區(qū)比例，根據(jù)對線網(wǎng)配置測試，這里為18則Eden區(qū)占18/20，Survivor區(qū)占2/20。ii1.MaxTenuringThreshold指定一個對象在經(jīng)歷了 n次YGC后轉(zhuǎn)移到年老代區(qū)，明顯在測試中Survivor區(qū)有足夠的空間承載YGC交換，同時降低了年老代區(qū)的增長率。iv.-XX:+UseCMSCompactAtFulICollection 指在使用并發(fā) GC 的情況下，為防止內(nèi)存碎片過多，對存活對象進行內(nèi)存碎片整理一般和-XX:CMSFullGCsBeforeCompaction = 5一起使用。而后者指在進行幾次Full GC后進行碎片整理。V.-XX:CMSInitiatingOccupancyFraction = 80將Full GC 的閥值調(diào)大，從而大大的減少了 Full GC的次數(shù)。原配置為40。v1._Xss256k設(shè)置每個線程的堆棧大小。在相同物理內(nèi)存下，減小這個值能生成更多的線程。vi1.-XX = PermSize = 150M調(diào)整持久代的大小，充分利用內(nèi)存空間。原配置為300M，內(nèi)存不能充分利用。優(yōu)化后實時監(jiān)測的情況如圖4所示:I)開放了 Survivor區(qū),減少年老代區(qū)增長頻率。2) YGC回收次數(shù)增多為582次，但是總耗時減少為18.889s，所以每次的YGC回收的平均時間為0.0324s。3)開放Survivor區(qū),年老代區(qū)在整個壓力過程(I小時內(nèi))沒有發(fā)生Fullgc。4) Perm區(qū)調(diào)整為200M利用率也有所增長。利用Loadrunner監(jiān)測TPS值,如圖5所示,服務(wù)器整個用戶(Vuser)增長過程相對線上配置穩(wěn)定，如階梯狀的曲線所示，秒級點擊次數(shù)平均在520次，比線上增長了近100。系統(tǒng)情況，系統(tǒng)load也在2-3之間徘徊，當用戶數(shù)超過1000后CPU處理一樣存在等待。壓力過程中應(yīng)用現(xiàn)象，訪問相對平穩(wěn)了很多。當用戶數(shù)達到1000后，通過頁面訪問等待時間在3-5秒左右，比之前的線上配置有明顯的提升。上述優(yōu)化測試通過使用jvm監(jiān)控工具和1adrunner得出:I)在增加內(nèi)存測試時，對4G，5G，8G，的情況分別測試，在增加內(nèi)存大小的前提下，JVM GC回收并沒有增長，5G和8G內(nèi)存分配的情況，如圖6和7所示，并發(fā)數(shù)并沒有4G的情況下高，從而確定，64位系統(tǒng)下linux2.6內(nèi)核，JVM最優(yōu)分配為4G,增大內(nèi)存后會浪費。2) JVM優(yōu)化就是減少YGC的時間。經(jīng)過優(yōu)化后，YGC時間由每次0.063秒減少到每次0.032秒。3) JVM優(yōu)化還有就是減少Full GC的次數(shù)，增大Full GC的周期。經(jīng)過優(yōu)化后，F(xiàn)ullGC在一個小時相同時間內(nèi)，由26次，每次0.848秒，減少到?jīng)]有發(fā)生Full GC。4)服務(wù)器整個用戶增長過程相對線上配置穩(wěn)定，秒級點擊次數(shù)平均在520次，比線上增長了 70 (并發(fā)量由450提高到520)。5)不同的應(yīng)用需要通過JVM的觀察進行優(yōu)化，基本遵循:更大的年輕代必然導(dǎo)致更小的年老代，大的年輕代會延長普通GC的周期，但會增加每次GC的時間；小的年老代會導(dǎo)致更頻繁的Full GC ;更小的年輕代必然導(dǎo)致更大年老代，小的年輕代會導(dǎo)致普通GC很頻繁，但每次的GC時間會更短；大的年老代會減少Full GC的頻率；具體如何選擇應(yīng)該依賴應(yīng)用程序?qū)ο笊芷诘姆植记闆r:如果應(yīng)用存在大量的臨時對象，應(yīng)該選擇更大的年輕代；如果存在相對較多的持久對象，年老代應(yīng)該適當增大。但很多應(yīng)用都沒有這樣明顯的特性，在抉擇時應(yīng)該根據(jù)以下兩點:(A)本著Full GC盡量少的原則，讓年老代盡量緩存常用對象，JVM的默認比例1: 2也是這個道理(B)通過觀察應(yīng)用一段時間，看其他在峰值時年老代會占多少內(nèi)存，在不影響FullGC的前提下，根據(jù)實際情況加大年輕代，比如可以把比例控制在1:1。但應(yīng)該給年老代至少預(yù)留增長空間。以上實施方式僅用于說明本發(fā)明，而并非對本發(fā)明的限制，有關(guān)技術(shù)領(lǐng)域的普通技術(shù)人員，在不脫離本發(fā)明的精神和范圍的情況下，還可以做出各種變化和變型，因此所有等同的技術(shù)方案也屬于本發(fā)明的范疇，本發(fā)明的專利保護范圍應(yīng)由權(quán)利要求限定。
權(quán)利要求
1.一種基于JVM服務(wù)器的性能優(yōu)化方法,其特征在于，包括: 51:根據(jù)服務(wù)器的當前配置對服務(wù)器進行壓力測試，得到壓力測試結(jié)果； 52:判斷所述壓力測試結(jié)果是否滿足預(yù)先設(shè)定的閾值，若不滿足，則執(zhí)行步驟S3 ;若滿足，則使用當前配置作為優(yōu)化配置的結(jié)果； 53:調(diào)整服務(wù)器的當前配置參數(shù)，調(diào)整后執(zhí)行步驟SI。
2.如權(quán)利要求1所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，所述壓力測試為在一段時間內(nèi)實時監(jiān)測配置參數(shù)的參數(shù)值，所述配置參數(shù)包括:垃圾回收參數(shù)。
3.如權(quán)利要求1所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，所述步驟S3中調(diào)整服務(wù)器的當前配置參數(shù)包括:設(shè)置內(nèi)存大小、垃圾回收線程數(shù)及線程堆棧大小。
4.如權(quán)利要求3所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，所述設(shè)置的垃圾回收線程數(shù)為CPU核的個數(shù)。
5.如權(quán)利要求1所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，所述步驟S3中包括:設(shè)置JVM中的年輕代對象的Survivor區(qū)與Eden區(qū)比例。
6.如權(quán)利要求1所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，所述步驟S3中調(diào)整服務(wù)器的當前配置參數(shù)包括:設(shè)置參數(shù)n，n為JVM中轉(zhuǎn)移到年老代的對象在年輕代中經(jīng)過垃圾回收的次數(shù)。
7.如權(quán)利要求1所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，所述步驟S3中調(diào)整服務(wù)器的當前配置參數(shù)包括:設(shè)置JVM中年老代區(qū)的垃圾回收的次數(shù)。
8.如權(quán)利要求1所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，所述步驟S3中調(diào)整服務(wù)器的當前配置參數(shù)包括:設(shè)置JVM中持久代區(qū)的存儲空間大小。
9.如權(quán)利要求1 8中任一項所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，在壓力測試的過程中還包括并發(fā)執(zhí)行內(nèi)存碎片整理的過程。
10.如權(quán)利要求9所述的基于JVM服務(wù)器的性能優(yōu)化方法，其特征在于，所述步驟S3中調(diào)整服務(wù)器的當前配置參數(shù)還包括:設(shè)置在進行m次年老代區(qū)的垃圾回收后進行所述內(nèi)存碎片整理。
全文摘要
本發(fā)明公開了一種基于JVM服務(wù)器的性能優(yōu)化方法，涉及Java虛擬機技術(shù)領(lǐng)域，包括S1根據(jù)服務(wù)器的當前配置對服務(wù)器進行壓力測試，得到壓力測試結(jié)果；S2判斷所述壓力測試結(jié)果是否滿足預(yù)先設(shè)定的閾值，若不滿足，則執(zhí)行步驟S3；若滿足，則使用當前配置作為優(yōu)化配置的結(jié)果；S3調(diào)整服務(wù)器的當前配置參數(shù)，調(diào)整后執(zhí)行步驟S1。本發(fā)明使得線上服務(wù)器壓力減小，以及部分服務(wù)器中資源得到充分利用。
文檔編號G06F9/455GK103186412SQ20111046215
公開日2013年7月3日 申請日期2011年12月31日 優(yōu)先權(quán)日2011年12月31日
發(fā)明者高赫 申請人:北京新媒傳信科技有限公司