Высокие объекты Скопируйте время, приводящее к длинным сборкам мусора с помощью G1GC

Question

У меня есть приложение Java, работающее в автономной JVM. Приложение прослушивает данные по одному или нескольким сокетам, ставит в очередь данные и имеет запланированные потоки, вытягивающие данные из очереди и сохраняющие его. Данные широкие, более 700 элементов данных на запись, хотя все элементы данных являются маленькими строками, целыми или длинными.

Приложение работает плавно в течение периодов времени, иногда от 30 минут до часа, но затем мы испытываем одну или несколько длинных пауз для сбора мусора. Большая часть времени паузы расходуется на время копирования объекта. Время sys также велико по сравнению с другими коллекциями.

Здесь детали JVM:

java version "1.7.0_03" 
Java(TM) SE Runtime Environment (build 1.7.0_03-b04) 
Java HotSpot(TM) 64-Bit Server VM (build 22.1-b02, mixed mode) 

Вот варианты JVM:

-XX:MaxPermSize=256m -XX:PermSize=256m -Xms3G -Xmx3G -XX:+UseG1GC -XX:-UseGCOverheadLimit 

Процесс набор задач 4 ядер (все на одной и той же розетки), но едва ли с использованием 2 из них. Все процессы на этом ящике привязаны к их собственным ядрам (с 0 ansd 1 не используется). Машина имеет много свободной памяти (20 + G), а верхний показывает процесс с использованием 2.5G памяти RES.

Вот некоторые из выхода журнала гх ...

[Object Copy (ms): 2090.4 2224.0 2484.0 2160.1 1603.9 2071.2 887.8 1608.1 1992.0 2030.5 1692.5 1583.9 2140.3 1703.0 2174.0 1949.5 1941.1 2190.1 2153.3 1604.1 1930.8 1892.6 1651.9 

[Eden: 1017M(1017M)->0B(1016M) Survivors: 7168K->8192K Heap: 1062M(3072M)->47M(3072M)] 

[Times: user=2.24 sys=7.22, real=2.49 secs] 

Любые идеи о том, почему объект Время копирования и SYS время настолько высоки, и как ее исправить? В журнале много коллекций мусора с почти одинаковыми размерами Eden/Survivors/Heap, которые занимают всего 10 или 20 мс.

Answer 1

У вас есть 3 гигабайта кучи? Установки сбора мусора становятся длиннее, так как куча становится больше, поскольку (хотя и менее часто), больше работы нужно делать, когда GC наконец-то понадобится.

Кажется, вы блокировка куча на 3-х гиге, установив минимум. Если приложение не нуждается в 3-х гигабайтах, это заставит его использовать это в любом случае .. и приведет к паузе, когда 3G наконец-то нужно будет собрать.

Я потратил довольно много времени на настройку Eclipse IDE для быстрого реагирования и нашел очень рано, что у компактных размеров кучи были лучшие характеристики с низкой паузой, чем большие.

Помимо настроек кучи JVM, вы можете убедиться в том, что элементы данных «nulls out» &, поскольку они отбрасываются.

Это стандартная практика в пакете коллекций java.util, но, возможно, у вас есть код, который может извлечь из этого выгоду. Записи 700-х годов, в частности, могут быть кандидатом на эту практику, что помогает упростить работу GC и обеспечить лучшую очистку от «мелких GC».

Answer 2

3gb не является большой кучей, а размер оставшихся в живых также невелик. Что-нибудь еще работает на этих ядрах? Сколько мусора вы генерируете и как часто он собирает? Возможно, вы захотите попробовать его и без G1GC.