針對sparc T4 8核心的適當G1 GC調優

Question

我的應用程序部署在運行Solaris的weblogic上，採用雙SPARC T4 8核3.0 GHz。此WebLogic實例使用G1 GC，我認爲這是可能的，以改善當前的配置：

GC_OPTIONS=" -server -XX:ConcGCThreads=4 -XX:+UseG1GC -XX:+DisableExplicitGC 
      -XX:MaxGCPauseMillis=300 -XX:GCPauseIntervalMillis=1000 -XX:+UseNUMA 
      -XX:+UseCompressedOops -XX:ReservedCodeCacheSize=128m 
      -Dweblogic.ThreadPoolPercentSocketReader=50 -Dweblogic.ThreadPoolSize=100 
      -Dweblogic.SelfTunningThreadPoolSizeMin=100 " 

我感到那ConcGCThreads已設置還沒有建立ParallelGCThreads的值。我認爲這會讓這兩個數值顯示一個合理的比例是一個好的開始。 Oracle的醫生說：

-XX：ParallelGCThreads = N

設置STW工作線程的值。將n的值設置爲邏輯處理器的數量 。 n的值與邏輯處理器的編號爲 的值最大爲8相同。

如果有八個以上的邏輯處理器，將n 的值設置爲大約5/8個邏輯處理器。這適用於大多數 的情況，除了較大的SPARC系統，其中n的值可以是邏輯處理器的大約5/16的 。

對於「邏輯處理器」是什麼沒有明確的說法。我搜索了網頁，看起來它可以理解爲在物理處理器或核心中運行的線程。根據http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/o11-090-sparc-t4-arch-496245.pdf，wl所運行的機架中的「邏輯處理器」數量將達到128個（2個8核處理器「能夠在8個線程之間切換」）。

但是我被告知，這128個「邏輯處理器」中的64個是爲數據庫保留的，剩下的那些共享用於運行Tuxedo和weblogic服務器。假設有兩個weblogic實例，並且認爲tuxedo和wl實例使用相同數量的thred是安全的，則可以認爲（64/3）*（5/16）= 6或7個ParallelGCThreads和因此1或至多2 ConcGCThreads是可以接受的。

你認爲這些是開始調整的合理值嗎？任何建議都是值得歡迎的。

編輯：今天的我有GCDetails enabled.Here是它的外觀在GC觀衆產生了一些日誌

我的解釋：當用戶

• 堆的使用慢慢長大做他們的任務
• 終身堆使用率（藍色曲折下的洋紅色線代表整體使用的堆）也可以，雖然仍然有相當可用的空間數量在年老一代
• 恰恰相反，年輕一代堆的邊緣是相當稀缺，它需要穩步垃圾收集
• 雖然沒有什麼立即令人不安的這張照片的趨勢是向上的。此外：在GC暫停時間（比如果沒有初始標記參與，幾乎2S否則1S略多）比300毫秒

就在垃圾收集日誌的顯示目標的目標遠長：

2014-01-16T11:18:12.728+0100: 50293.457: [GC pause (young), 1.36713100 secs] 
    [Parallel Time: 1308.6 ms] 
     [GC Worker Start (ms): 50293458.0 50293458.0 50293458.0 50293458.1 50293458.1 50293458.1 50293458.2 50293458.2 
     Avg: 50293458.1, Min: 50293458.0, Max: 50293458.2, Diff: 0.2] 
     [Ext Root Scanning (ms): 982.5 174.5 146.2 150.6 170.6 139.6 154.5 158.8 
     Avg: 259.7, Min: 139.6, Max: 982.5, Diff: 842.9] 
     [Update RS (ms): 0.0 16.9 36.2 42.3 18.6 54.6 38.8 34.9 
     Avg: 30.3, Min: 0.0, Max: 54.6, Diff: 54.6] 
     [Processed Buffers : 0 15 21 31 18 27 11 21 
      Sum: 144, Avg: 18, Min: 0, Max: 31, Diff: 31] 
     [Scan RS (ms): 0.2 9.8 9.7 8.7 10.0 10.0 8.1 9.0 
     Avg: 8.2, Min: 0.2, Max: 10.0, Diff: 9.8] 
     [Object Copy (ms): 275.1 132.6 142.2 131.8 133.9 129.4 131.9 130.5 
     Avg: 150.9, Min: 129.4, Max: 275.1, Diff: 145.6] 
     [Termination (ms): 0.0 924.0 923.4 924.2 924.5 924.0 924.3 924.5 
     Avg: 808.6, Min: 0.0, Max: 924.5, Diff: 924.5] 
     [Termination Attempts : 1 1049 1140 1011 881 979 894 780 
      Sum: 6735, Avg: 841, Min: 1, Max: 1140, Diff: 1139] 
     [GC Worker End (ms): 50294715.8 50294715.9 50294716.0 50294715.9 50294715.9 50294715.9 50294715.9 50294715.9 
     Avg: 50294715.9, Min: 50294715.8, Max: 50294716.0, Diff: 0.1] 
     [GC Worker (ms): 1257.9 1257.9 1257.9 1257.9 1257.7 1257.8 1257.7 1257.7 
     Avg: 1257.8, Min: 1257.7, Max: 1257.9, Diff: 0.3] 
     [GC Worker Other (ms): 50.8 50.8 50.7 50.8 50.9 50.9 50.9 50.9 
     Avg: 50.8, Min: 50.7, Max: 50.9, Diff: 0.2] 
    [Clear CT: 1.1 ms] 
    [Other: 57.4 ms] 
     [Choose CSet: 0.1 ms] 
     [Ref Proc: 49.8 ms] 
     [Ref Enq: 0.1 ms] 
     [Free CSet: 5.9 ms] 
    [Eden: 1322M(1322M)->0B(1312M) Survivors: 68M->78M Heap: 4494M(6952M)->3182M(6952M)] 
[Times: user=9.12 sys=0.18, real=1.37 secs] 

到目前爲止，沒有疏散失敗，大量的對象分配或完整的垃圾收集發生。有一點是沒有別的選擇，只有在服務器被阻擋時才能產生完整的gc。

有8名並行工作者;因爲ConcGCThreads設置爲4我認爲我可以設置ParallelGCThreads = 16或將ConcGCThreads減少到2.不知道什麼選項更好，可能前者是。但畢竟它可能並不那麼重要。

參考處理時間一直很高。著名貝克威思文章提到：

如果你詢問處理中見高次，然後請上 並行處理參考通過啓用 命令行下面的選項打開-XX：+ ParallelRefProcEnabled。

這是我絕對認爲我應該做的，肯定會的。

然而，主要的問題是如何減少gc暫停的長度。一個更高的ParallelGCThreads可以提供幫助，但也許這個問題與過於雄心勃勃的暫停時間有關;作爲Oracle教程所說：

代替使用平均響應時間（ART）作爲指標來設定的 XX：MaxGCPauseMillis =，考慮設置值，將滿足該 目標90％的時間或更。這意味着90％的用戶請求 的用戶的響應時間不會超過目標。請記住， 暫停時間是一個目標，並不能保證始終得到滿足。

所以我認爲它也可以幫助建立一個更現實的MaxGCPauseMillis，比如600ms。如果要實現這樣的目標，大多數用戶會非常高興。如果暫停時間超過2s，他們可能不會。你認爲這個參數是否可以進一步調整或有其他建議？

問候

Answer 1

的密鑰G1優標誌是：

• –XX:G1MixedGCLiveThresholdPercent：要包括在混合收集在老區域實時對象的佔用率閾值。
• –XX:G1HeapWastePercent：您可以在堆中容忍的垃圾的閾值。
• –XX:G1MixedGCCountTarget：應收集最多G1MixedGCLiveThresholdPercent實時數據的區域的混合垃圾收集的目標數量。
• –XX:G1OldCSetRegionThresholdPercent：對混合收集期間可收集的最大舊區域數量的限制。

您的命令行選項還應包含GC日誌記錄：–XX:+PrintGCDetails –XX:+PrintGCTimeStamps。

考慮到-XX:ParallelGCThreads，您可以嘗試一半或總「處理器」 - 64你的情況，並從那裏去。此外，您需要考慮您的PoolSize = 100，因此如果需要保持池的繁忙狀態，則需要設置ParallelGCThreads = 28或更少。

考慮到G1優化選項，請參閱以下資源：

• 的JavaOne 2013 G1調整 [talk]，和JavaOne，2012會話：G1垃圾回收器性能優化 [youtube]，[PDF ] - 在演講的最後部分，他們展示了一些G1場景和可能的調整選項。
• G1: One Garbage Collector To Rule Them All
• 見G1的命令行選項和最佳實踐在Getting Started with the G1 Garbage Collector。