Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
© 2008 Oracle Corporation – Proprietary and Confidential
<Insert Picture Here>
Диагностирование проблем и настройка GC в HotSpot JVM
Владимир Иванов
Oracle Corporation
Vladimir.x....
The First Rule of Program Optimization:
Don't do it.
–Michael A. Jackson
(not the singer!)
The Second Rule of Program Optimization
(for experts only!):
Don't do it yet.
–Michael A. Jackson
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
Сборка мусора (GC)
• Находит и освобождает место, занимаемое
ненужными объектами
• Объекты вне транзитивного замыкания, вк...
Сборка мусора с поколениями (I)
• Слабая гипотеза о поколениях
• Большинство объектов временные
• Старые объекты редко ссы...
Сборка мусора с поколениями (II)
Молодое поколение
Старшее поколение
Продвижение объектов
Аллокация объектов
Необходимо
от...
GC в Hotspot
• SerialGC
• последовательная сборка молодого и старого поколений
• ParallelGC
• максимальный throughput
• па...
GC в Hotspot: о чем будем говорить
• SerialGC
• последовательная сборка молодого и старого поколений
• ParallelGC
• максим...
ParallelGC: описание
• Молодое поколение: параллельный копирующий GC
• Старшее поколение: параллельный Mark-Compact GC
• А...
Concurrent Mark Sweep: описание
• Молодое поколение: параллельный копирующий GC
• Старшее поколение: фоновый Mark-Sweep GC...
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
Диагностический вывод GC
• Параметры VM
• -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:<file>
• -XX:+PrintGCDateStam...
VisualVM / VisualGC
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
Идеальный сборщик мусора
• Не прерывает работу приложения
• Использует ровно столько оперативной памяти,
сколько нужно при...
Производительность GC
• 3 характеристики
• Throughput
• Объем вычислительных ресурсов, затрачиваемых на GC
• Предсказуемос...
Принципы настройки GC
• Чем больше доступно памяти GC, тем лучше
• Оптимизировать по 2 параметрам из 3
• Throughput
• Длит...
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
Критерии выбора размера хипа
• Чем больше памяти, тем лучше для GC
• Как для молодого, так и для старшего поколения
• Боле...
Размеры поколений
• Размер молодого поколения
• Определяет частоту малых сборок (Minor GC)
• Влияет на то, сколько объекто...
Управление размерами поколений
Survivor
Tenured PermGen
-XX:MaxNewSize
Survivor
Eden
-XX:PermSize-XX:NewSize
-XX:MaxPermSi...
Размер хипа: основные цели
• Объем используемой памяти не должен
превышать объем физической памяти
• Максимизировать объем...
Размер хипа: с чего лучше начать?
• LDS = Live Data Size
• размер множества достижимых объектов
• для приложение в стабиль...
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
Структура молодого поколения
Молодое поколение: сборка мусора (I)
Молодое поколение: сборка мусора (II)
Перемещение в старшее поколение
• Временные объекты
должны умирать в
молодом поколении
• Долгоживущие объекты
должны попад...
Время жизни объектов
Возраст
Живыеобъекты
Живыеобъекты
(размер)
Возраст
(кол-во GC)
1 2 3 4 5
Регион Eden (Young Gen)
Регион Survivor (Young Gen)
Старшее поколение ...
Время жизни объектов
• -XX:+PrintTenuringDistribution
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1...
Время жизни объектов
• -XX:+PrintTenuringDistribution
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1...
Время жизни объектов
• -XX:+PrintTenuringDistribution
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1...
Время жизни объектов
• -XX:+PrintTenuringDistribution
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1...
Время жизни объектов
• -XX:+PrintTenuringDistribution
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1...
Время жизни объектов
• -XX:+PrintTenuringDistribution
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1...
Время жизни объектов
• -XX:+PrintTenuringDistribution
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1...
Время жизни объектов
• -XX:+PrintTenuringDistribution
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1...
Время жизни объектов:
Как должно быть
Desired survivor size 6684672 bytes, new threshold 8 (max 8)
- age 1: 2315488 bytes,...
Время жизни объектов:
Как бывает (I)
Desired survivor size 3342336 bytes, new threshold 1 (max 6)
- age 1: 3956928 bytes, ...
Время жизни объектов:
Как бывает (I)
Вывод: размер Survivor слишком мал.
Решение: увеличить размер Survivor и/или Eden.
• ...
Время жизни объектов:
Как бывает (II)
Desired survivor size 3342336 bytes, new threshold 6 (max 6)
- age 1: 2483440 bytes,...
Время жизни объектов:
Как бывает (II)
Вывод: настройки не оптимальны.
Решение: 2 варианта:
• Увеличить MTT: 6 → [7...]
• У...
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
Паузы: Молодое поколение
• Продолжительность малых сборок
• Часто является причиной задержек, вызванных GC
• Важна как про...
Паузы: Старшее поколение (I)
• ParallelOldGC vs CMS
• ParallelOldGC может удовлетворять достаточно жестким
ограничениям на...
Паузы: Старшее поколение (II)
• -XX:+UseParallelOldGC
• -XX:ParallelGCThreads=<num>
Паузы: Старшее поколение (III)
• Частые полные сборки → ↑ размер старшего
поколения
• постарайтесь зафиксировать размер мо...
Паузы: Полные сборки
Как бывает
• Происходят только полные сборки
• Причина:
• дисбаланс размеров молодого и старшего поко...
Паузы: выбор GC для старшего
поколения (I)
• Продолжительность и частота малых и полных
сборок устраивает
→ ParallelOldGC
...
Паузы: выбор GC для старшего
поколения (II)
• Продолжительность малых сборок может
конфликтовать с требованиями приложения...
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
CMS: Concurrent Mark Sweep
• 3 режима GC
• GC в молодом поколении (Minor GC)
• Полная сборка (Major GC)
• Фоновая сборка (...
CMS: как стартовать фоновую сборку
• по пороговому наполнению поколения
• -XX:CMSInitiatingOccupancyFraction=<percent>
• -...
CMS: Фоновая сборка
Как должно быть
Полный цикл фоновой
сборки
Старшее
поколение
Пороговый
уровень
Наполнение
поколения
Пр...
CMS: Фоновая сборка
Как должно быть
Полный цикл фоновой
сборки
Старшее
поколение
Initial Mark
Sweep
Remark
Mark
Пороговый
...
CMS: Сценарии работы
Kак должно быть
• Скорость наполнения старшего поколения
сильно варьируется
• Старшее поколение может...
CMS: Сценарии работы
Как бывает (I)
• Цикл начинается слишком рано
• Частые циклы фоновой сборки
• Избыточные накладные ра...
CMS: Сценарии работы
Как бывает (II)
• Цикл начинается слишком поздно
• Высока вероятность полной сборки (Full GC)
Порогов...
CMS: Настройка
• Минимизируйте перемещение объектов в старшее
поколение
• Аллокация памяти в старшем поколении дорога (fre...
CMS: Фрагментация старшего
поколения
• Неизбежна
• Компактификация только при Full GC
• Можно минимизировать
• Как можно м...
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
G1: Описание
• Хип разбит на регионы
• Сборка мусора – эвакуация
регионов
• Основан на поколениях
• Сборка молодого поколе...
G1: Использование
• -XX:+UseG1GC
• Задаваемые цели на длительность и частоту пауз
• -XX:MaxGCPauseMillis=<num>
• -XX:GCPau...
Содержание
• Кратко о сборке мусора
• Мониторинг GC
• Настройка GC
• Объем используемой памяти
• Молодое поколение
• Паузы...
Подводим итоги
• Объем используемой памяти
• Конфигурация хипа
• Длительность пауз
• Конфигурация молодого поколения
• Кон...
Необычные конфигурации
• Размер молодого поколения = 80% хипа
• Размер старшего поколение = 1.2x от размера
долгоживущих ж...
Measure, don't guess!
“If you aren't assessing, you're guessing.”
- Fitness Industry
Q & A
QUESTIONS
ANSWERS&
© 2008 Oracle Corporation – Proprietary and Confidential
© 2008 Oracle Corporation – Proprietary and Confidential
Upcoming SlideShare
Loading in …5
×

"Диагностирование проблем и настройка GC в HotSpot JVM" (JEEConf, Киев, 2011)

4,720 views

Published on

Published in: Technology
  • Be the first to comment

"Диагностирование проблем и настройка GC в HotSpot JVM" (JEEConf, Киев, 2011)

  1. 1. © 2008 Oracle Corporation – Proprietary and Confidential
  2. 2. <Insert Picture Here> Диагностирование проблем и настройка GC в HotSpot JVM Владимир Иванов Oracle Corporation Vladimir.x.Ivanov@oracle.com 21.05.2011
  3. 3. The First Rule of Program Optimization: Don't do it. –Michael A. Jackson (not the singer!)
  4. 4. The Second Rule of Program Optimization (for experts only!): Don't do it yet. –Michael A. Jackson
  5. 5. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Выводы <Insert Picture Here>
  6. 6. Сборка мусора (GC) • Находит и освобождает место, занимаемое ненужными объектами • Объекты вне транзитивного замыкания, включающего roots (стеки потоков, статические поля классов и т.д.) • Автоматическая и безопасная • Проще, если граф объектов “заморожен” • Stop-the-world (STW) паузы • Возможны различные подходы • c дефрагментацией или без • Алгоритмы: copying, mark-sweep, mark-compact, ... • Аллокация: linear, free lists, ...
  7. 7. Сборка мусора с поколениями (I) • Слабая гипотеза о поколениях • Большинство объектов временные • Старые объекты редко ссылаются на молодые • Молодые и старые объекты содержатся отдельно • В пространствах называемых “поколения” (generations) • Возможны разные алгоритмы для молодого и старого поколения • Mолодое поколение можно собирать отдельно от старого
  8. 8. Сборка мусора с поколениями (II) Молодое поколение Старшее поколение Продвижение объектов Аллокация объектов Необходимо отслеживать ссылки
  9. 9. GC в Hotspot • SerialGC • последовательная сборка молодого и старого поколений • ParallelGC • максимальный throughput • параллельная сборка молодого и старого поколений • CMS • предсказуемость • по возможности, сборка мусора в фоновом режиме • G1 • предсказуемость • слабо подвержен фрагментации • прямой конкурент CMS
  10. 10. GC в Hotspot: о чем будем говорить • SerialGC • последовательная сборка молодого и старого поколений • ParallelGC • максимальный throughput • параллельная сборка молодого и старого поколений • CMS • предсказуемость • по возможности, сборка мусора в фоновом режиме • G1 • предсказуемость • слабо подвержен фрагментации • прямой конкурент CMS
  11. 11. ParallelGC: описание • Молодое поколение: параллельный копирующий GC • Старшее поколение: параллельный Mark-Compact GC • Аллокация: линейная • -XX:+UseParallelGC -XX:+UseParallelOldGC
  12. 12. Concurrent Mark Sweep: описание • Молодое поколение: параллельный копирующий GC • Старшее поколение: фоновый Mark-Sweep GC • Аллокация: free-листы • Компактификация только при Full GC • -XX:+UseConcMarkSweep
  13. 13. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Выводы <Insert Picture Here>
  14. 14. Диагностический вывод GC • Параметры VM • -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:<file> • -XX:+PrintGCDateStamps • -XX:+PrintHeapAtGC • Минимальные накладные расходы • Анализ диагностического вывода GC • PrintGCStats • GChisto: http://gchisto.dev.java.net/
  15. 15. VisualVM / VisualGC
  16. 16. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Выводы <Insert Picture Here>
  17. 17. Идеальный сборщик мусора • Не прерывает работу приложения • Использует ровно столько оперативной памяти, сколько нужно приложению • Не требует дополнительных вычислительных ресурсов
  18. 18. Производительность GC • 3 характеристики • Throughput • Объем вычислительных ресурсов, затрачиваемых на GC • Предсказуемость • На какое время прерывается работа приложения • Footprint • Объем используемой памяти
  19. 19. Принципы настройки GC • Чем больше доступно памяти GC, тем лучше • Оптимизировать по 2 параметрам из 3 • Throughput • Длительность пауз • Объем используемой памяти
  20. 20. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Выводы <Insert Picture Here>
  21. 21. Критерии выбора размера хипа • Чем больше памяти, тем лучше для GC • Как для молодого, так и для старшего поколения • Более редкие сборки • Ниже затраты на сборку мусора • Доступный объем памяти ограничен • Физическая память • 32-битный режим • Наличие других приложений в системе
  22. 22. Размеры поколений • Размер молодого поколения • Определяет частоту малых сборок (Minor GC) • Влияет на то, сколько объектов умирает, не покидая молодое поколении • Размер старшего поколения • Определяет частоту полных сборок (Full GC) • Не меньше суммарного размера долгоживущих объектов, используемых приложением в стабильном состоянии
  23. 23. Управление размерами поколений Survivor Tenured PermGen -XX:MaxNewSize Survivor Eden -XX:PermSize-XX:NewSize -XX:MaxPermSize -Xms -Xmx Молодое поколение (Young Gen) Старшее поколение (Old Gen) Permanent Generation (Perm Gen)
  24. 24. Размер хипа: основные цели • Объем используемой памяти не должен превышать объем физической памяти • Максимизировать объем памяти, освобождаемый при малых и полных GC • Относится ко всем GC
  25. 25. Размер хипа: с чего лучше начать? • LDS = Live Data Size • размер множества достижимых объектов • для приложение в стабильном состоянии • -Xms / -Xmx = 3-4x LDS • -XX:PermSize = 1.2-1.5x от макс. размера PermGen • Размеры поколений • Молодое поколение: -Xmn = 1-1.5x LDS • Старшее поколение: -Xmx = 2-3x LDS + -Xmn • Пример: Если LDS == 512m, тогда -Xmn768m -Xms2g -Xmx2g
  26. 26. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Выводы <Insert Picture Here>
  27. 27. Структура молодого поколения
  28. 28. Молодое поколение: сборка мусора (I)
  29. 29. Молодое поколение: сборка мусора (II)
  30. 30. Перемещение в старшее поколение • Временные объекты должны умирать в молодом поколении • Долгоживущие объекты должны попадать в старшее поколение как можно раньше
  31. 31. Время жизни объектов Возраст Живыеобъекты
  32. 32. Живыеобъекты (размер) Возраст (кол-во GC) 1 2 3 4 5 Регион Eden (Young Gen) Регион Survivor (Young Gen) Старшее поколение (Old / Tenured Gen) Время жизни объектов: Как должно быть
  33. 33. Время жизни объектов • -XX:+PrintTenuringDistribution Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total
  34. 34. Время жизни объектов • -XX:+PrintTenuringDistribution Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total • Возраст (age) – количество пережитых малых GC
  35. 35. Время жизни объектов • -XX:+PrintTenuringDistribution Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total • Суммарный размер объектов определенного возраста
  36. 36. Время жизни объектов • -XX:+PrintTenuringDistribution Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total • Суммарный размер объектов, не старше определенного возраста
  37. 37. Время жизни объектов • -XX:+PrintTenuringDistribution Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total • Общий размер объектов в Survivor пространстве
  38. 38. Время жизни объектов • -XX:+PrintTenuringDistribution Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total • Эффективный размер Survivor пространства • == (Размер Survivor) x TargetSurvivorRatio • -XX:TargetSurvivorRatio=<percent> ([1..100])
  39. 39. Время жизни объектов • -XX:+PrintTenuringDistribution Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total • Текущий пороговый возраст копирования в старшее поколение
  40. 40. Время жизни объектов • -XX:+PrintTenuringDistribution Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total • Максимальный пороговый возраст копирования • -XX:MaxTenuringThreshold (MTT)
  41. 41. Время жизни объектов: Как должно быть Desired survivor size 6684672 bytes, new threshold 8 (max 8) - age 1: 2315488 bytes, 2315488 total - age 2: 19528 bytes, 2335016 total - age 3: 96 bytes, 2335112 total - age 4: 32 bytes, 2335144 total
  42. 42. Время жизни объектов: Как бывает (I) Desired survivor size 3342336 bytes, new threshold 1 (max 6) - age 1: 3956928 bytes, 3956928 total
  43. 43. Время жизни объектов: Как бывает (I) Вывод: размер Survivor слишком мал. Решение: увеличить размер Survivor и/или Eden. • -XX:MaxNewSize / -Xmn • -XX:SurvivorRatio=<ratio> соотношение между Eden и Survivor Desired survivor size 3342336 bytes, new threshold 1 (max 6) - age 1: 3956928 bytes, 3956928 total
  44. 44. Время жизни объектов: Как бывает (II) Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total
  45. 45. Время жизни объектов: Как бывает (II) Вывод: настройки не оптимальны. Решение: 2 варианта: • Увеличить MTT: 6 → [7...] • Установить MTT = 2 Desired survivor size 3342336 bytes, new threshold 6 (max 6) - age 1: 2483440 bytes, 2483440 total - age 2: 501240 bytes, 2984680 total - age 3: 50016 bytes, 3034696 total - age 4: 49088 bytes, 3083784 total - age 5: 48616 bytes, 3132400 total - age 6: 50128 bytes, 3182528 total
  46. 46. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Выводы <Insert Picture Here>
  47. 47. Паузы: Молодое поколение • Продолжительность малых сборок • Часто является причиной задержек, вызванных GC • Важна как продолжительность, так и частота • Малые сборки продолжительны → ↓ размер молодого поколения часты → ↑ размер молодого поколения
  48. 48. Паузы: Старшее поколение (I) • ParallelOldGC vs CMS • ParallelOldGC может удовлетворять достаточно жестким ограничениям на длительность пауз • NB! прежде чем использовать CMS убедитесь, что ParallelOldGC не подходит
  49. 49. Паузы: Старшее поколение (II) • -XX:+UseParallelOldGC • -XX:ParallelGCThreads=<num>
  50. 50. Паузы: Старшее поколение (III) • Частые полные сборки → ↑ размер старшего поколения • постарайтесь зафиксировать размер молодого поколения • Продолжительные полные сборки → ParallelOldGC не подходит • изменение размера старшего поколения не поможет • Совет: • используйте CMS • исключите полные stop-the-world (STW) сборки (Full GC)
  51. 51. Паузы: Полные сборки Как бывает • Происходят только полные сборки • Причина: • дисбаланс размеров молодого и старшего поколений • после полной сборки в старшем поколении нет свободного места • Решение: • ↑ размер старшего поколения • оптимально ли настроено молодое поколение?
  52. 52. Паузы: выбор GC для старшего поколения (I) • Продолжительность и частота малых и полных сборок устраивает → ParallelOldGC • Продолжительность малых сборок устраивает; полные сборки слишком продолжительны/часты → CMS • Продолжительность малых сборок недопустима → требуется модификация приложения
  53. 53. Паузы: выбор GC для старшего поколения (II) • Продолжительность малых сборок может конфликтовать с требованиями приложения • Что стоит попробовать: • уменьшить количество объектов со средней продолжительностью жизни • Если возможно, запускать приложение в нескольких JVM с меньшим размером хипа
  54. 54. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Выводы <Insert Picture Here>
  55. 55. CMS: Concurrent Mark Sweep • 3 режима GC • GC в молодом поколении (Minor GC) • Полная сборка (Major GC) • Фоновая сборка (2 коротких STW паузы) • С остановкой приложения (Full GC)
  56. 56. CMS: как стартовать фоновую сборку • по пороговому наполнению поколения • -XX:CMSInitiatingOccupancyFraction=<percent> • -XX:CMSInitiatingPermOccupancyFraction=<percent> • System.gc() • -XX:+ExplicitGCInvokesConcurrent • -XX:+ExplicitGCInvokesConcurrentAndUnloadClasses
  57. 57. CMS: Фоновая сборка Как должно быть Полный цикл фоновой сборки Старшее поколение Пороговый уровень Наполнение поколения Приложение остановлено работает во время цикла % 0 100
  58. 58. CMS: Фоновая сборка Как должно быть Полный цикл фоновой сборки Старшее поколение Initial Mark Sweep Remark Mark Пороговый уровень Наполнение поколения Приложение остановлено работает во время цикла % 0 100
  59. 59. CMS: Сценарии работы Kак должно быть • Скорость наполнения старшего поколения сильно варьируется • Старшее поколение может заполняться очень быстро • Частые GC • Цикл фоновой сборки должен стартовать заблаговременно • В старшее поколение попадает мало объектов • Старшее поколение заполняется медленно и монотонно • GC редки • Цикл фоновой сборки безопасно начинать достаточно поздно
  60. 60. CMS: Сценарии работы Как бывает (I) • Цикл начинается слишком рано • Частые циклы фоновой сборки • Избыточные накладные расходы Пороговый уровень Наполнение поколения Приложение остановлено работает во время цикла % 0 60 # 1 # 2
  61. 61. CMS: Сценарии работы Как бывает (II) • Цикл начинается слишком поздно • Высока вероятность полной сборки (Full GC) Пороговый уровень Наполнение поколения Приложение остановлено работает во время цикла % 0 100 Full GC
  62. 62. CMS: Настройка • Минимизируйте перемещение объектов в старшее поколение • Аллокация памяти в старшем поколении дорога (free lists) • Фрагментация • -XX:ParallelCMSThreads=<num> • Количество потоков, участвующих в фоновом GC • Компромисс между: • длительностью цикла фоновой сборки • overhead фоновой сборки
  63. 63. CMS: Фрагментация старшего поколения • Неизбежна • Компактификация только при Full GC • Можно минимизировать • Как можно меньше копировать объектов в старшее поколение • Модифицировать приложение • Избегайте создания больших объектов разных размеров
  64. 64. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Резюме <Insert Picture Here>
  65. 65. G1: Описание • Хип разбит на регионы • Сборка мусора – эвакуация регионов • Основан на поколениях • Сборка молодого поколения • Эвакуация всех молодых регионов • Сборка старшего поколения • Эвакуация регионов с наибольшим количеством мусора Регион из молодого поколения Регион из старшего поколения Пустой регион
  66. 66. G1: Использование • -XX:+UseG1GC • Задаваемые цели на длительность и частоту пауз • -XX:MaxGCPauseMillis=<num> • -XX:GCPauseIntervalMillis=<num>
  67. 67. Содержание • Кратко о сборке мусора • Мониторинг GC • Настройка GC • Объем используемой памяти • Молодое поколение • Паузы • CMS • G1 • Выводы <Insert Picture Here>
  68. 68. Подводим итоги • Объем используемой памяти • Конфигурация хипа • Длительность пауз • Конфигурация молодого поколения • Контроль времени жизни объектов • Выбор сборщика для старшего поколения • ParallelOldGC • CMS • Настройка фонового режим • G1
  69. 69. Необычные конфигурации • Размер молодого поколения = 80% хипа • Размер старшего поколение = 1.2x от размера долгоживущих живых объектов • Начало фоновой сборки при 95% занятости старшего поколения
  70. 70. Measure, don't guess! “If you aren't assessing, you're guessing.” - Fitness Industry
  71. 71. Q & A QUESTIONS ANSWERS&
  72. 72. © 2008 Oracle Corporation – Proprietary and Confidential
  73. 73. © 2008 Oracle Corporation – Proprietary and Confidential

×