Настройка Java 1.5 gc - PullRequest
       0

Настройка Java 1.5 gc

1 голос
/ 26 июня 2011

У нас большое приложение с выделенной кучей минимум 2 ГБ и максимум 8 ГБ. Во время нагрузочного теста мы находим очень длительное время паузы, когда циклы ГХ составляют более 16 с. Первоначально мы использовали «-XX: + UseParNewGC», но переключение на UseParallelGC дало нам столь необходимый прирост производительности, но у нас есть проблема с более длительным временем паузы под нагрузкой.

Мы пробовали несколько вариантов, таких как подрастающее молодое поколение, но, кажется, ничто не помогает ни одной идее, что еще можно попробовать? Мы можем увеличить размер кучи, если это необходимо, но мне интересно, что может ухудшить gc pause. Если ничего не поделаешь, я подумываю об использовании серверов приложений кластера с кучей 5 ГБ вместо одной большой кучи. снимок текущего журнала gc прилагается

J  
J Thu Jun 23 12:40:56 2011
J  [GCJ  
J Thu Jun 23 12:40:57 2011
 [PSYoungGen: 2130792K->475247K(2084160K)] 7198716K->5543171K(7676608K), 1.3280110 secs] [Times: user=0.00 sys=1.88, real=1.33 secs] 
J  
J Thu Jun 23 12:41:00 2011
J  [GCJ  
J Thu Jun 23 12:41:01 2011
 [PSYoungGen: 1966319K->417801K(1908928K)] 7034243K->5546416K(7501376K), 0.7025950 secs] [Times: user=0.01 sys=1.89, real=0.71 secs] 
J  
J Thu Jun 23 12:41:12 2011
J  [GCJ  
J Thu Jun 23 12:41:13 2011
 [PSYoungGen: 1908873K->269608K(2155520K)] 7037488K->5523748K(7747968K), 1.3117340 secs] [Times: user=0.01 sys=1.44, real=1.31 secs] 
J  
J Thu Jun 23 12:41:33 2011
J  [GC [PSYoungGen: 1747432K->138147K(1616000K)] 7001572K->5593865K(7208448K), 0.4949960 secs] [Times: user=0.01 sys=1.40, real=0.50 secs] 
J  [Full GCJ  
J Thu Jun 23 12:41:50 2011
 [PSYoungGen: 138147K->0K(1616000K)] [PSOldGen: 5455718K->3456287K(5592448K)] 5593865K->3456287K(7208448K) [PSPermGen: 256273K->256273K(524288K)], 17.0259440 secs] [Times: user=0.00 sys=16.88, real=17.02 secs] 
J  
J Thu Jun 23 12:42:09 2011
J  [GC [PSYoungGen: 1477824K->85118K(2110848K)] 4934111K->3541406K(7703296K), 0.1437050 secs] [Times: user=0.00 sys=0.30, real=0.14 secs] 
J  
J Thu Jun 23 12:42:20 2011
J  [GC [PSYoungGen: 1573438K->71812K(2100352K)] 5029726K->3600767K(7692800K), 0.2477960 secs] [Times: user=0.00 sys=0.65, real=0.25 secs] 

Ответы [ 3 ]

3 голосов
/ 26 июня 2011

Глядя на ваш журнал, ваша самая большая коллекция (17 секунд) собирает старое (постоянное) поколение.Использование параллельного сборщика мусора в Sun JVM должно помочь (+ XX: UseConcMarkSweepGC), так как это сделает сбор (в основном) одновременно, уменьшая время паузы).

Ваши паузы молодого поколения также достаточно велики,для объема данных, которые собираются.На какой машине вы работаете?Эти паузы тоже не очень часты, поэтому, если ваша цель - уменьшить время паузы, попробуйте уменьшить размер молодого поколения (-XX: NewRatio), что должно привести к более коротким, более частым паузах.

ВыТакже следует убедиться, что на вашей машине не происходит обмена.Вы не говорите, какую операционную систему вы используете, но в Linux запустите:

vmstat 5

и проверьте столбцы «si» и «so» во время работы этих больших сборщиков мусора.Если они не равны нулю, либо уменьшите использование памяти на машине, либо измените настройку «swappiness».

0 голосов
/ 26 марта 2012

В JDK 1.5 и JDK 1.6 вы увидите увеличение пауз GC при передаче от 2 до 4 ГБ памяти кучи.Кластеризация приложений, которым требуются большие кучи данных, является одним из вариантов.Другой, о котором я знаю, рассматривает альтернативные JVM.Если у вас куча 8 ГБ, вы можете увидеть улучшения в JDK 1.7.Есть некоторые оптимизации.Кроме того, у Sun / Oracle есть несколько других JVM, которые стоит рассмотреть.

Если вы еще не читали эту статью, она очень полезна и для Java 5.0 / JDK 1.5.Это может помочь. Настройка Java 5.0 .Я хотел бы подробнее остановиться на этом, но комментарии выше охватывают некоторые из элементов.

В качестве альтернативы на рынке есть еще одна JVM, принадлежащая частной компании под названием Azul Systems .У них есть несколько инструментов с открытым исходным кодом, чтобы проверить, может ли помочь их коллектор C4.У них есть платформа JVM, которая работает параллельно во время работы вашего приложения.Если их инструмент JHiccup сообщает, что у вас есть проблемы с GC, он может предоставить корпоративную JVM.Стоимость не бесплатна, поэтому, если вы рассматриваете небольшие развертывания (один сервер) и проблемы стоимостью менее 10 000 долларов, я бы (1) рассмотрел альтернативную бесплатную JVM и (2) попробовал бы другую JVM, если вы можете на ней работать(например, JDK 1.6 / 1.7).Если ни один из этих вариантов не подходит, попробуйте выполнить кластеризацию, но сделайте это с кучей ниже 4 ГБ.

Единственное, что я здесь отмечу, это то, что есть варианты «ARE» на выбор JVM.JRocket действительно помогает некоторым приложениям.

0 голосов
/ 26 июня 2011

Попробуйте сделать одинаковыми значения -Xms и -Xmx. если вы хотите, чтобы размер кучи был максимальным - 8 ГБ, то сделайте это также минимальным. Таким образом, JVM не нужно беспокоиться о выделении дополнительной памяти.

Как часто полные GC? если они происходят часто, то вам может потребоваться профилировать приложение, а не бить себя по голове настройкой параметров gc, которые в конечном итоге не будут иметь значения. Узнайте, что выделяет всю память для вас, и посмотрите, есть ли способ уменьшить ее.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...