您好,登錄后才能下訂單哦!
雙核,4個cores; 16G memory
[root@alish3-cassandra-01 ~]# cat /proc/cpuinfo | grep "cpu cores"
cpu cores : 2
cpu cores : 2
響應時間優先的并發收集器,主要是保證系統的響應時間,減少垃圾收集時的停頓時間。適用于應用服務器、電信領域等。
ParNew收集器
ParNew收集器是Serial收集器的多線程版本,許多運行在Server模式下的虛擬機中首選的新生代收集器,除Serial外,只有它能與CMS收集器配合工作。
CMS收集器
CMS, 全稱Concurrent Low Pause Collector,是jdk1.4后期版本開始引入的新gc算法,在jdk5和jdk6中得到了進一步改進,它的主要適合場景是對響應時間的重要性需求 大于對吞吐量的要求,能夠承受垃圾回收線程和應用線程共享處理器資源,并且應用中存在比較多的長生命周期的對象的應用。CMS是用于對tenured generation的回收,也就是年老代的回收,目標是盡量減少應用的暫停時間,減少FullGC發生的幾率,利用和應用程序線程并發的垃圾回收線程來 標記清除年老代。
CMS并非沒有暫停,而是用兩次短暫停來替代串行標記整理算法的長暫停,它的收集周期是這樣:
初始標記(CMS-initial-mark) -> 并發標記(CMS-concurrent-mark) -> 重新標記(CMS-remark) -> 并發清除(CMS-concurrent-sweep) ->并發重設狀態等待下次CMS的觸發(CMS-concurrent-reset)
其中的1,3兩個步驟需要暫停所有的應用程序線程的。第一次暫停從root對象開始標記存活的對象,這個階段稱為初始標記;第二次暫停是在并發標記之后,暫停所有應用程序線程,重新標記并發標記階段遺漏的對象(在并發標記階段結束后對象狀態的更新導致)。第一次暫停會比較短,第二次暫停通常會比較長,并且remark這個階段可以并行標記。
而并發標記、并發清除、并發重設階段的所謂并發,是指一個或者多個垃圾回收線程和應用程序線程并發地運行,垃圾回收線程不會暫停應用程序的執行,如果你有多于一個處理器,那么并發收集線程將與應用線程在不同的處理器上運行,顯然,這樣的開銷就是會降低應用的吞吐量。Remark階段的并行,是指暫停了所有應用程序后,啟動一定數目的垃圾回收進程進行并行標記,此時的應用線程是暫停的。
($TOMCAT_HOME/bin/catalina.sh)
export JAVA_OPTS="-server -Xmx10240m -Xms10240m -Xmn3840m -XX:PermSize=256m
-XX:MaxPermSize=256m -Denv=denalicnprod
-XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=1048576
-XX:+DisableExplicitGC
-XX:+UseParNewGC -XX:ParallelGCThreads=10
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
-XX:+CMSScavengeBeforeRemark -XX:ParallelCMSThreads=10
-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
-XX:+UseFastAccessorMethods
-XX:LargePageSizeInBytes=128M
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDateStamps -Xloggc:gc.log -verbose:gc"
參 數 | 含 義 |
---|---|
-server | 一定要作為第一個參數,啟用JDK的server版本,在多個CPU時性能佳 |
-Xms | java Heap初始大小。 默認是物理內存的1/64。此值可以設置與-Xmx相同,以避免每次垃圾回收完成后JVM重新分配內存。 |
-Xmx | java heap最大值。建議均設為物理內存的80%。不可超過物理內存。 |
-Xmn | 設置年輕代大小,一般設置為Xmx的2/8~3/8,等同于-XX:NewSize 和 -XX:MaxNewSize 。 |
-XX:PermSize | 設定內存的永久保存區初始大小,缺省值為64M |
-XX:MaxPermSize | 設定內存的永久保存區最大大小,缺省值為64M |
-Denv | 指定tomcat運行哪個project |
-XX:SurvivorRatio | Eden區與Survivor區的大小比值, 設置為8,則兩個Survivor區與一個Eden區的比值為2:8,一個Survivor區占整個年輕代的1/10 |
-XX:PretenureSizeThreshold | 晉升年老代的對象大小。默認為0,比如設為1048576(1M),則超過1M的對象將不在eden區分配,而直接進入年老代。 |
-XX:+DisableExplicitGC | 關閉System.gc() |
-XX:+UseParNewGC | 設置年輕代為并發收集。可與CMS收集同時使用。 |
-XX:ParallelGCThreads | |
-XX:+UseConcMarkSweepGC | 設置年老代為并發收集。測試中配置這個以后,-XX:NewRatio=4的配置失效了。所以,此時年輕代大小最好用-Xmn設置。 |
-XX:+CMSParallelRemarkEnabled | 開啟并行remark |
-XX:+CMSScavengeBeforeRemark | 這個參數還蠻重要的,它的意思是在執行CMS remark之前進行一次youngGC,這樣能有效降低remark的時間 |
-XX:ParallelCMSThreads | CMS默認啟動的回收線程數目是 (ParallelGCThreads + 3)/4) ,如果你需要明確設定,可以通過-XX:ParallelCMSThreads=20來設定,其中ParallelGCThreads是年輕代的并行收集線程數 |
-XX:CMSInitiatingOccupancyFraction | 使用cms作為垃圾回收使用70%后開始CMS收集 |
-XX:+UseCMSInitiatingOccupancyOnly | 使用手動定義初始化定義開始CMS收集 |
-XX:+UseCMSCompactAtFullCollection | 打開對年老代的壓縮。可能會影響性能,但是可以消除內存碎片。 |
-XX:CMSFullGCsBeforeCompaction | 由于并發收集器不對內存空間進行壓縮、整理,所以運行一段時間以后會產生“碎片”,使得運行效率降低。此參數設置運行次FullGC以后對內存空間進行壓縮、整理。 |
-XX:+CMSPermGenSweepingEnabled | 為了避免Perm區滿引起的full gc,建議開啟CMS回收Perm區選項 |
-XX:+CMSClassUnloadingEnabled | |
-XX:+UseFastAccessorMethods | 原始類型的快速優化 |
-XX:LargePageSizeInBytes | 內存頁的大小,不可設置過大, 會影響Perm的大小 |
-XX:SoftRefLRUPolicyMSPerMB | “軟引用”的對象在最后一次被訪問后能存活0毫秒(默認為1秒)。 |
-XX:+PrintGCDetails | 記錄 GC 運行時的詳細數據信息,包括新生成對象的占用內存大小以及耗費時間等 |
-XX:+PrintGCTimeStamps | 打印垃圾收集的時間戳 |
-XX:+PrintHeapAtGC | 打印GC前后的詳細堆棧信息 |
-XX:+PrintGCApplicationStoppedTime | 打印垃圾回收期間程序暫停的時間.可與上面混合使用 |
-XX:+PrintGCDateStamps | 之前打印gc日志的時候使用是:-XX:+PrintGCTimeStamps,這個選項記錄的是jvm啟動時間為起點的相對時間,可讀性較差,不利于定位問題,使用PrintGCDateStamps記錄的是系統時間,更humanreadable |
-Xloggc | 與上面幾個配合使用,把相關日志信息記錄到文件以便分析 |
-verbose:gc | 記錄 GC 運行以及運行時間,一般用來查看 GC 是否是應用的瓶頸 |
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。