Обзор IBM JVM
Как вы, вероятно, видели из моих других статей, IBM JVM отличается от HotSpot JVM в некоторых аспектах, так как у него нет, например, пространства памяти PermGen. С точки зрения сборки мусора, он предоставляет вам продвинутые алгоритмы, которые могут использовать преимущества машины с несколькими физическими ядрами; похож на JVM HotSpot.
С точки зрения устранения неполадок IBM предоставляет вам множество инструментов; включая встроенные возможности создания дампов потоков и дампов кучи из его реализации JVM.
Например, IBM JVM Thread Dump является особенно мощным средством, поскольку он предоставляет вам дополнительные данные о вашей JVM, такие как переменные активной среды JVM, политики GC, загруженные классы в каждом активном загрузчике классов и т. Д. Мы рассмотрим это более подробно в части 4 из нашего учебного плана .
IBM VM — поведение GC по умолчанию
Теперь вернемся к нашей основной теме. Очень важно, чтобы вы понимали поведение по умолчанию сборщика мусора IBM JVM (версии 1.5 и 1.6). По умолчанию пространство кучи Java создается с использованием только постоянной памяти, например, оно не создает отдельное пространство YoungGen (питомник). Это означает, что любое выделение памяти направляется в постоянное пространство (недолговечные и долгоживущие объекты), которое впоследствии получает сборщик по умолчанию (через Full GC).
Ниже приведен подробный снимок GC, показывающий разбивку памяти GC по умолчанию с объяснениями:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
<af type="tenured" id="5" timestamp="Mar 01 13:40:30 2012" intervalms="0.000"> <minimum requested_bytes="48" /> <time exclusiveaccessms="0.106" meanexclusiveaccessms="0.106" threads="0" lastthreadtid="0x000000011A846B00" /> <tenured freebytes="20131840" totalbytes="2013265920" percent="0" > <soa freebytes="0" totalbytes="1993134080" percent="0" /> <loa freebytes="20131840" totalbytes="20131840" percent="100" /> </tenured> <gc type="global" id="8" totalid="2492" intervalms="2017588.587"> <finalization objectsqueued="199" /> <timesms mark="808.286" sweep="9.341" compact="0.000" total="818.292" /> <tenured freebytes="1362331024" totalbytes="2013265920" percent="67" > <soa freebytes="1344212368" totalbytes="1995147264" percent="67" /> <loa freebytes="18118656" totalbytes="18118656" percent="100" /> </tenured> </gc> <tenured freebytes="1362330976" totalbytes="2013265920" percent="67" > <soa freebytes="1344212320" totalbytes="1995147264" percent="67" /> <loa freebytes="18118656" totalbytes="18118656" percent="100" /> </tenured> <time totalms="818.750" /></af> |
Хорошо, политика IBM JVM GC по умолчанию отличается … в чем проблема?
Проблема с этой политикой JVM по умолчанию заключается в том, что все объекты Java копируются в постоянное пространство и собираются с помощью глобальной коллекции (Full GC). Для многих приложений Java EE соотношение недолговечных и долгоживущих объектов намного выше. Это означает, что вашей JVM потребуется выполнить довольно много основных коллекций для очистки недолговечных объектов; Результаты: увеличенная частота Full GC, увеличенное время паузы JVM, увеличенная загрузка ЦП и снижение производительности!
Это именно то, что мы наблюдали при выполнении нагрузочного тестирования после перехода на JVM HotSpot 1.5 (с использованием инкрементного и параллельного GC) на IBM JVM 1.6 с политикой GC по умолчанию. Тяжелый процесс GC был идентифицирован как первопричина в соответствии с приведенным выше объяснением.
Решение пожалуйста!
Хорошей новостью является то, что IBM JVM представила сборщик поколений и одновременный сборщик мусора начиная с версии 1.5. Эта политика GC обеспечивает именно то, что мы хотим:
- Это делит пространство Java Heap между питомником и арендованным пространством
- Детские (YoungGen) космические объекты собираются отдельно через сборщик мусора GC
- Арендуемые космические объекты собираются через глобальный сборщик мусора
- Коллектор GC работает одновременно и использует преимущества любой машины с несколькими физическими ядрами.
Полученные результаты:
- Снижение основной частоты сбора (Full GC)
- Сокращенное время полного GC и время паузы
- Увеличить пропускную способность JVM
- Повысить производительность и емкость вашего приложения
Вы можете включить его, добавив этот параметр JVM ниже:
|
1
|
-Xgcpolicy:gencon |
Ниже, что вы можете ожидать в подробном журнале GC после включения этой политики GC:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
<af type="nursery" id="15" timestamp="Mar 08 05:34:06 2012" intervalms="1289096.227"> <minimum requested_bytes="40" /> <time exclusiveaccessms="0.085" meanexclusiveaccessms="0.085" threads="0" lastthreadtid="0x0000000118113900" /> <refs soft="18043" weak="204057" phantom="27" dynamicSoftReferenceThreshold="32" maxSoftReferenceThreshold="32" /> <nursery freebytes="0" totalbytes="530716672" percent="0" /> <tenured freebytes="1887422016" totalbytes="2013265920" percent="93" > <soa freebytes="1786758720" totalbytes="1912602624" percent="93" /> <loa freebytes="100663296" totalbytes="100663296" percent="100" /> </tenured> <gc type="scavenger" id="15" totalid="15" intervalms="1289097.271"> <flipped objectcount="1486449" bytes="129908000" /> <tenured objectcount="1176" bytes="184144" /> <finalization objectsqueued="3082" /> <scavenger tiltratio="73" /> <nursery freebytes="364304408" totalbytes="495208448" percent="73" tenureage="10" /> <tenured freebytes="1886766656" totalbytes="2013265920" percent="93" > <soa freebytes="1786103360" totalbytes="1912602624" percent="93" /> <loa freebytes="100663296" totalbytes="100663296" percent="100" /> </tenured> <time totalms="233.886" /> </gc> <nursery freebytes="364238872" totalbytes="495208448" percent="73" /> <tenured freebytes="1886766656" totalbytes="2013265920" percent="93" > <soa freebytes="1786103360" totalbytes="1912602624" percent="93" /> <loa freebytes="100663296" totalbytes="100663296" percent="100" /> </tenured> <refs soft="17992" weak="5344" phantom="27" dynamicSoftReferenceThreshold="32" maxSoftReferenceThreshold="32" /> <time totalms="236.858" /></af> |
Пожалуйста, имейте в виду, что все еще возможно, что ваше приложение может не получить выгоду от этой политики GC (большая площадь долгоживущих объектов и т. Д.), Поэтому я рекомендую вам всегда проявлять должную осмотрительность и выполнять надлежащее планирование емкости и нагрузочное тестирование Ваше приложение перед выполнением каких-либо серьезных рекомендаций по настройке.
Вывод
Я надеюсь, что эта статья помогла вам понять политику GC IBM JVM 1.5 / 1.6 по умолчанию и узнать, как ваше приложение Java EE может извлечь выгоду из этой рекомендации по настройке gencon политики GC.
Ссылка: настройка JVM IBM — политика GC gencon от нашего партнера по JCG Пьера-Хьюга Шарбонно в блоге « Шаблоны поддержки Java EE и учебник по Java» .