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

1. ОПТИМИЗАЦИЯ
ПОТРЕБЛЕНИЯ ПАМЯТИ В JAVA
делаем уборку правильно
12 ноября 2016

2. Евгений Берлог
EPAM Systems
Senior Software Engineer
2

3. 3

4. 4
ОСОБЕННОСТИ ЗАДАЧИ
# REST + MongoDB
# Жесткие требования к времени ответа
# Stateless

5. 5
УСЛОВИЯ ТЕСТИРОВАНИЯ
# 10000 URL с реального окружения
# ~30 вызовов в секунду (реальная нагрузка + 50%)
ЗАМЕРЫ УСПЕШНОСТИ
# Максимальная пауза
# Пропускная способность
# Частота Full GC

7. 7
Исходные замеры
Максимальнаяпауза Пропускнаяспособность ЧастотаFullGC
1918мс 99.0% 5развчас

8. НЕМНОГО ТЕОРИИ

9. 9
Распределение памяти

10. 10
Первая сборка

11. 11
Вторая сборка

12. 12
Как происходит старение

13. 13
Большая сборка

14. ГИПОТЕЗА
О СТАРЕНИИ ОБЪЕКТОВ

15. ГИПОТЕЗА О СТАРЕНИИ
ОБЪЕКТОВ
Время жизни
Размеробъектов

16. 16
НО РЕАЛЬНАЯ И
ТЕОРЕТИЧЕСКАЯ
СИТУАЦИИ РАЗЛИЧАЮТСЯ

17. 17
НО РЕАЛЬНАЯ И
ТЕОРЕТИЧЕСКАЯ
СИТУАЦИИ РАЗЛИЧАЮТСЯ

18. КАК
МОНИТОРИТЬ
СИТУАЦИЮ ?

19. 19
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintTenuringDistribution

20. 20
Вывод детализированного сообщения после каждого
запуска Garbage Collector’а.
-XX:+PrintGCDetails
dsc2016
[PSYoungGen: 1559493K->93696K(1610752K)] 2771413K->1379948K(5106176K),
0.1586049 secs]

21. 21
-XX:+PrintGCTimeStamps
dsc2016
1914.990: [GC
[PSYoungGen: 1559493K->93696K(1610752K)] 2771413K->1379948K(5106176K),
0.1586049 secs]
Добавление в каждую GC-запись времени
относительно старта JVM.

22. 22
-XX:+PrintTenuringDistribution
dsc2016
Desired survivor size 134217728 bytes, new threshold 15 (max 15)
Вывод в лог порога старения объектов и
необходимого размера Survivor региона.

23. 23
1914.990: [GC
Desired survivor size 134217728 bytes, new threshold 1 (max 15)
[PSYoungGen: 1559493K->93696K(1610752K)] 2771413K->1379948K(5106176K),
0.1586049 secs]
1932.209: [GC
Desired survivor size 136839168 bytes, new threshold 1 (max 15)
[PSYoungGen: 1569792K->53234K(1611776K)] 2856044K->1408182K(5107200K),
0.1083012 secs]
dsc2016
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintTenuringDistribution

25. ADAPTIVE SIZE POLICY

26. 26
ADAPTIVE SIZE POLICY – это попытка
JVM реорганизовать память с целью достичь
(#1) уменьшения GC паузы;
(#2) увеличения пропускной способности;
(#3) уменьшения footprint’а.
-XX:AdaptiveSizePolicyOutputInterval=1

27. 27
ЛОГИ GC С ВКЛЮЧЕННЫМ ASP
UseAdaptiveSizePolicy actions to meet *** reduced footprint ***
GC overhead (%)
Young generation: 1.26 (attempted to shrink)
Tenured generation: 0.00 (no change)
Tenuring threshold: (attempted to decrease to balance GC costs) = 2
dsc2016

28. 28
ЛОГИ GC С ВКЛЮЧЕННЫМ ASP
UseAdaptiveSizePolicy actions to meet *** reduced footprint ***
GC overhead (%)
Young generation: 1.26 (attempted to shrink)
Tenured generation: 0.00 (no change)
Tenuring threshold: (attempted to decrease to balance GC costs) = 2
dsc2016

30. 30
Эксперимент #1:
Указываем максимальную задержку
-XX:GCTimeRatio=999
// по умолчанию 99
-XX:MaxGCPauseMillis=100
// по умолчанию не ограничен

32. 32
Результат для максимальной
задержки
Максимальнаяпауза Пропускнаяспособность ЧастотаFullGC
2092мс 99.0% 5развчас

35. # Выключаем Adaptive Size Policy
# Уменьшаем Old Generation
# Максимум на Eden
# Экспериментально высчитываем Survivor Size
35
Эксперимент #2:
Дальше не по правилам

36. 36
Эксперимент #2:
Дальше не по правилам
-XX:-UseAdaptiveSizePolicy
-Xmx5G -Xms5G
-Xmn4300M
-XSurvivorRatio=6

38. 38
Результат c выключенным
Adaptive Size Policy
Максимальнаяпауза Пропускнаяспособность ЧастотаFullGC
1683мс 99.3% 1разв3.5часов

39. 39
Максимальнаяпауза Пропускнаяспособность ЧастотаFullGC
Базовыенастройки 1918МС 99.0% 5развчас
Максимальнаяпауза 2092МС 99.0% 5развчас
ВыключенныйASP 1683МС 99.3% 1разв3.5часов
Промежуточный результат

40. - Может пора остановиться?

41. Concurrent Mark Sweep
Collector

42. 42
Concurrent Mark Sweep (CMS) Collector
# То же распределение регионов, что и в Parallel
# Тот же алгоритм, что и в Parallel для младшего
поколения
# Часть работы в старшем поколении
выполняется параллельно
# Больше footprint, чем в Parallel

44. 44
Эксперимент #3:
Меняем GC!
-XX:+UseConcMarkSweepGC
-Xmx5G -Xms5G -Xmn4300M
-XX:SurvivorRatio=2

46. 46
Максимальнаяпауза Пропускнаяспособность ЧастотаFullGC
283мс 99.2% 1разв4часа
Результат c новым GC

47. 47
dsc2016
: 1460888K->10522K(1595776K), 0.0049030 secs] 1697910K->247592K(2210176K),
0.0049871 secs]
1195.459: [GC1195.459: [ParNew
Desired survivor size 74252288 bytes, new threshold 15 (max 15)
- age 1: 690016 bytes, 690016 total
- age 2: 148448 bytes, 838464 total
- age 3: 751056 bytes, 1589520 total
...
- age 13: 82512 bytes, 3801784 total
- age 14: 607816 bytes, 4409600 total
- age 15: 1348728 bytes, 5758328 total
Анализ логов CMS

48. ...
- age 13: 82512 bytes, 3801784 total
- age 14: 607816 bytes, 4409600 total
- age 15: 1348728 bytes, 5758328 total
15299.307: [GC [1 CMS-initial-mark: 581268K(839680K)] 1241313K(4142080K),
0.2830091 secs]
15306.520: [GC[YG occupancy: 1031447 K (3302400 K)]15306.520: [Rescan
(parallel) , 0.2487740 secs]15306.769: [weak refs processing, 0.0012183
secs]15306.770: [scrub string table, 0.0012292 secs] [1 CMS-remark:
581268K(839680K)] 1612715K(4142080K), 0.2518813 secs]

49. ...
- age 13: 82512 bytes, 3801784 total
- age 14: 607816 bytes, 4409600 total
- age 15: 1348728 bytes, 5758328 total
15299.307: [GC [1 CMS-initial-mark: 581268K(839680K)] 1241313K(4142080K),
0.2830091 secs]
15306.520: [GC[YG occupancy: 1031447 K (3302400 K)]15306.520: [Rescan
(parallel) , 0.2487740 secs]15306.769: [weak refs processing, 0.0012183
secs]15306.770: [scrub string table, 0.0012292 secs] [1 CMS-remark:
581268K(839680K)] 1612715K(4142080K), 0.2518813 secs]

50. 50
Максимальнаяпауза Пропускнаяспособность ЧастотаFullGC
cms 283МС 99.2% 1разв4часа
parallel 1681МС 99.3% 1разв3.5часов
CMS vs PARALLEL

51. 51
Почему не G1?
> G1 рекомендуется использовать при
размерах heap’а от 6ГБ

53. 53
Эксперимент #4:
Используем сборщик G1
-XX:UseG1GC

55. 55
Максимальнаяпауза Пропускнаяспособность ЧастотаFullGC
351мс 95.9% ?
Результат c использованием G1

57. 57
Максимальнаяпауза Пропускнаяспособность
Parallel 1681МС 99.3%
G1 351МС 95.9%
cms 283МС 99.2%
Долгожданный победитель

58. 58
Максимальнаяпауза ПРопускнаяспособность
Parallel 1681МС 99.3%
G1 351МС 95.9%
cms 283МС 99.2%
Долгожданный победитель