Правильная настройка G1 GC для sparc T4 8-core

Question

мое приложение развернуто на веб-лого, запущенном на Solaris, на двух SPARC T4 8-ядерном 3,0 ГГц. Это WebLogic экземпляр использует g1 дс, и я думаю, что это возможно, чтобы улучшить текущую конфигурацию:

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 = п

Устанавливает значение рабочих потоков STW. Устанавливает значение n в число логических процессоров . Значение п совпадает с числом логических процессоров до значения 8.

Если есть больше, чем восемь логических процессоров, устанавливает значение п до приблизительно 5/8 из логических процессоров. Это работает в большинстве случаев , за исключением больших систем SPARC, где значение n может быть приблизительно 5/16 логических процессоров.

Нет четкого указания относительно того, что такое «логический процессор». Я искал в Интернете, и, похоже, это можно понять как поток, выполняющийся в физическом процессоре или ядре. Количество «логических процессоров» в стойке, на которой работает этот wl, будет составлять 128 (2 8-ядерные процессоры «с возможностью переключения между 8 потоками», согласно http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/o11-090-sparc-t4-arch-496245.pdf).

Но мне говорят, что 64 из этих 128 «логических процессоров» зарезервированы для базы данных, а остальные - для использования серверов Tuxedo и weblogic. Предполагая, что есть два экземпляра weblogic и можно с уверенностью считать, что экземпляры tuxedo и wl потребляют одинаковое количество threds, можно утверждать, что (64/3) * (5/16) ~ = 6 или 7 ParallelGCThreads и таким образом, 1 или не более 2 ConcGCThreads являются приемлемыми.

Как вы думаете, это разумные значения, чтобы начать настройку? Любое предложение приветствуется.

Edit: на сегодняшний день у меня есть журнал, производимый с GCDetails enabled.Here как это выглядит в средстве просмотра ого

Моей интерпретация:

• использования кучи медленно растет, как пользователи выполняют свои задачи
• Использование кучного использования кучи (пурпурная линия под синими зигзагами, которые обозначают общую использованную кучу), также делает, хотя по-прежнему имеется достаточное количество свободного места в заложенном поколении
• совсем наоборот, маржа кучи молодого поколения довольно скудна, и ее необходимо постоянно собирать мусор
• , хотя ничего не возникает, что вызывает беспокойство об этом изображении, тренд вверх.Более того: времена дс пауза (чуть более 1 сек, если не начальная метка не участвует, почти 2s в противном случае) гораздо больше, чем целевой цели 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 помещает это:

Вместо того чтобы использовать среднее время отклика (АРТ) в качестве метрики, чтобы установить XX: MaxGCPauseMillis =, рассмотреть вопрос об установлении величины, которая будет соответствовать цели 90% времени, или более , Это означает, что 90% пользователей, сделавших запрос , не будут иметь время ответа выше цели. Помните, время паузы - это цель и не гарантируется всегда.

Таким образом, я думаю, что это также могло бы помочь создать более реалистичный MaxGCPauseMillis, скажем, 600 мс. Если такая цель будет достигнута, большинство пользователей будут совершенно счастливы. Если пауза переваливается за 2 секунды, они, вероятно, не будут. Считаете ли вы, что этот параметр является кандидатом на дальнейшую настройку или имеет какое-либо другое предложение?

С уважением

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 Tuning [talk] и JavaOne 2012 сессия: G1 Garbage Collector Performance Tuning [youtube], [PDF ] - в последней части разговора они представляют некоторые сценарии G1 и возможные варианты настройки.
• G1: One Garbage Collector To Rule Them All
• См G1 Параметры командной строки и лучшие практики в Getting Started with the G1 Garbage Collector.