тема:
1、jvm调优原因 --- 为什么要进行jvm调优！（海恩法则，墨菲定律）
2、jvm调优原理 --- 垃圾回收算法，如何进行调优
3、jvm调优实战 --- 设置jvm调优参数，根据这些参数压力测试
4、jvm调优gc日志，根据日志情况，对服务进行再次调优
1 Зачем нужна настройка JVM?
Мысль 1: После того, как проект запущен, зачем нам выполнять настройку jvm
1) Слишком много мусора (java потоки, объекты занимают память), память переполнена и программа не запускается! !
2) Слишком много потоков сборки мусора и частая сборка мусора (сами потоки сборки мусора тоже занимают ресурсы: занимают память и ресурсы процессора), что приводит к снижению производительности программы
3) Частая сборка мусора приводит к STW
Следовательно, исходя из вышеперечисленных причин, после того, как программа находится в сети, ее необходимо настроить, иначе производительность программы не может быть улучшена, то есть после того, как программа находится в сети, необходимо установить разумную стратегию сборки мусора;
Отражение 2: какая натуральная настройка JVM? ?
Ответ: перерабатывать мусор, вовремя перерабатывать неиспользуемые объекты мусора и вовремя освобождать место в памяти.
Мысль 3. Основываясь на серверной среде, сколько памяти устанавливает приложение памяти кучи JVM?
1. 32-разрядная операционная система --- емкость адресации 2^32 = 4 ГБ, самая большая может поддерживать 4 ГБ, jvm может выделить 2 ГБ+
2. 64-разрядная операционная система --- емкость адресации 2^64 = 16384 ПБ, высокопроизводительный компьютер (IBM Z unix 128G 200+)
Память кучи JVM нельзя ставить слишком большой, иначе это приведет к долгой трате времени на адресацию, то есть к тому, что вся программа STW, не может быть установлена слишком маленькой, иначе это будет слишком часто приводить к мусору;
2 принципа настройки JVM
1), время gc достаточно мало (настройка кучи памяти должна быть достаточно маленькой)
2)количество gc достаточно мало(настройка памяти кучи достаточно велика)----мусор переполнен(долго заполняет пространство),и начинается сборка мусора
3) протекание полного цикла gc достаточно продолжительно
1）metaspace 永久代空间设置稍微合理一些，永久代一代扩容，立马发生full gc
2) 老年代设置空间大一些，如果老年代装不满的话，永远不会发生full gc
3) 尽量让垃圾再年轻代被回收掉
4）尽量少一些大对象
3 Принцип настройки JVM — GC
3.1 Что такое мусор?
В памяти нет объекта. Эти объекты являются мусором; в памяти стека, ссылка на объект не является, то этот объект должен быть переработан;
3.2 Как найти мусор?
В JVM есть 2 алгоритма поиска мусора (методы поиска мусора)
1. Алгоритм подсчета ссылок
2. Алгоритм достижимости корня
1) Алгоритм подсчета ссылокАлгоритм подсчета ссылок определяет, что объект является мусором, когда счетчик равен 0, объект считается мусором;
Есть проблема: проблема циклического подсчета ссылок не может быть решена;
Вышеуказанные объекты ссылаются друг на друга, так что счетчик ссылок всегда не равен 0, поэтому нельзя судить, что это мусор, но на эти объекты не ссылаются внешние объекты, поэтому они мусор;
2), алгоритм достижимости корня
Алгоритм доступа к корневому каталогу в настоящее время является основным алгоритмом сборки мусора, используемым jvm, этот алгоритм использует точка доступа компании oracle;
3.3 Как убрать мусор?
JVM предоставляет 3 метода (алгоритма) ----- 1. Развертка пометки --- Алгоритм развертки пометки 2. копирование – копирование 3. Алгоритм сжатия меток-компактных меток
1) Развертка пометки --- Алгоритм развертки пометки
1. Найдите мусор из пространства памяти и пометьте найденный мусор 2. Удалить отмеченный мусор Достоинства: Простой, эффективный Недостатки: имеется много прерывистых пространств памяти, а пространство памяти фрагментировано, что приводит к снижению эффективности адресации и производительности.
2), копировать - копировать
1. Выберите уцелевший объект 2. Скопируйте уцелевший объект в другую половину пространства, это непрерывное пространство памяти 3. После копирования всех уцелевших объектов сразу очистите верхнюю половину пространства, чтобы завершить сборку мусора;
Преимущества: простые, пространство памяти смежно, и нет необходимости беспокоиться о фрагментации пространства памяти Недостаток: отходы пространства памяти
3) алгоритм сжатия меток-компактных меток
1. Отметить мусор, не убирать мусор 2. Просканируйте еще раз и сдвиньте (скопируйте) уцелевшие объекты (объекты без меток) в один конец 3. Утилизировать мусор в пространстве памяти на другом конце
3.4 Доступные сборщики мусора
Особенность языка Java в том, что он имеет свой сборщик мусора, а сборщиков мусора много, поэтому разные сборщики мусора нужно выбирать по разным сценариям;
JVM предоставляет 10 видов сборщиков мусора; при таком количестве сборщиков мусора, какая комбинация сборщиков мусора используется в проекте? ?
1) серийный (сборка мусора молодого поколения) + serialOld (сборка мусора лет): сериализованный сборщик, поэтому, когда текущий многоядерный процессор, менее подходит только для сборки мусора одноядерного процессора;
2) parNew + CMS: параллельный; параллельные сборщики мусора; эта комбинация отдает приоритет комбинациям сборщиков мусора во времени отклика
3) Parallel Scavenge + Parallel Old (аббревиатура: ps+po): параллельный сборщик мусора, который является комбинацией сборщиков мусора по умолчанию для jdk.
4) сборщик мусора g1 (логическая генерация), который объединяет молодое поколение и старое поколение в одно для сборки мусора;
3.5 Последовательный сборщик мусора
Уведомление:
1. При сборке мусора все бизнес-потоки должны быть временно приостановлены для облегчения сборки мусора;
2. Безопасная точка — приостановить пользовательский поток, чтобы поток jvm мог безопасно пометить мусор;
3.6 Ps + po
3.7 parNew + CMS
3.8 Сборщик мусора G1
4 Модель генерации памяти
Вопрос: Что вы делаете, когда приходит крупный объект?
Может ли Иден подавить это? --- НЕТ --- (YGC)--- eden подойдет? --- нет ---- старый можно поставить ---- да --- можно поставить старый
-----нет---- fullgc oom
5 практика настройки JVM
5.1 Типовые настройки параметров настройки
Конфигурация сервера: 4 процессора, 8 ГБ памяти ---- настройка jvm фактически устанавливает разумный размер кучи памяти jvm (ни слишком большой, ни слишком маленький)
-Xmx3550m 设置jvm堆内存最大值 (经验值设置： 根据压力测试，根据线上程序运行效果情况)
-Xms3550m 设置jvm堆内存初始化大小，一般情况下必须设置此值和最大的最大的堆内存空间保持一致，防止内存抖动，消耗性能
-Xmn2g 设置年轻代占用的空间大小
-Xss256k 设置线程堆栈的大小；jdk5.0以后默认线程堆栈大小为1MB; 在相同的内存情况下，减小堆栈大小，可以使得操作系统创建更多的业务线程；
Параметры памяти кучи JVM:
nohup java -Xmx3550m -Xms3550m -Xmn2g -Xss256k -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&
Кривая производительности TPS:
5.2 Анализ журналов сборщика мусора
Если вам нужно проанализировать журнал gc, вы должны заставить службу gc ввести данные gc в файл журнала журнала, а затем использовать соответствующий инструмент анализа журнала gc для анализа журнала;
Вывод данных сборщика мусора в файл журнала gc.log для удобного анализа сборщика мусора
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log
Пропускная способность: время выполнения бизнес-потока / (время сборки + время бизнес-потока)
После анализа лога gc было установлено, что в самом начале произошло три fullgcs, очевидно проблема с настройкой параметров оптимизации jvm;Проверьте причину проблемы с fullgc: jstat -gcutil pid
Постоянная генерация метапространства: Начальный размер выделения 20 м. Когда метапространство заполнено, постоянная генерация должна быть расширена. Если метапространство расширяется каждый раз, fullgc нужно выполнить один раз; (fullgc освобождает все пространство кучи, что занимает много времени)
Настройте конфигурацию gc: измените размер инициализации пространства постоянной генерации:
nohup java -Xmx3550m -Xms3550m -Xmn2g -Xss256k -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&
После настройки исчезло явление fullgc:
5.3 Доля молодых и старых
Отношение молодого поколения к старому: 1:2 Параметры: -XX:NewRetio = 4, что указывает на то, что соотношение молодого поколения (eden, s0, s1) и старого поколения составляет 1:4.
1) -ХХ:НовыйРетио=4
Объем памяти, выделяемый молодому поколению, стал меньше, поэтому количество YGC увеличилось.Хотя fullgc не происходит, YGC занимает больше времени!
2) -ХХ:НовыйРетио=2
Количество вхождений YGC неизбежно уменьшится, потому что размер области рая становится больше, YGC будет уменьшаться;
5.4 Eden&S0S1
Для того, чтобы еще больше уменьшить YGC, вы можете установить соотношение enden, s area, метод настройки: -XX:SurvivorRatio=8
1) Установите соотношение: 8:1:1
2) Xmn2g 8:1:1
nohup java -Xmx3550m -Xms3550m -Xmn2g -XX:SurvivorRatio=8 -Xss256k -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&
Согласно настройке gc, количество сборок мусора, время и пропускная способность являются оптимальной конфигурацией;
5.5 Приоритет пропускной способности
Использование параллельных сборщиков мусора может в полной мере использовать многоядерные процессоры для облегчения сборки мусора; такой метод сборки мусора называется настройкой с приоритетом пропускной способности.
Комбинация сборщика мусора: ps (параллельная очистка) + po (параллельная старая) Этот сборщик мусора является комбинацией сборщиков мусора по умолчанию для Jdk1.8;
nohup java -Xmx3550m -Xms3550m -Xmn2g -XX:SurvivorRatio=8 -Xss256k -XX:+UseParallelGC -XX:UseParallelOldGC -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&
5.6 Приоритет времени отклика
Использование сборщика мусора cms представляет собой сочетание приоритета времени отклика; Сборщик мусора cms (сборка мусора и бизнес-потоки выполняются попеременно, и бизнес-поток не будет приостановлен stw), чтобы максимально сократить время stw, поэтому комбинация сборщика мусора cms является комбинацией приоритета времени отклика
nohup java -Xmx3550m -Xms3550m -Xmn2g -XX:SurvivorRatio=8 -Xss256k -XX:+UseParNewGC -XX:UseConcMarkSweepGC -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&
Можно обнаружить, что сборщик мусора cms занимает больше времени;
5.7 g1
Конфигурация выглядит следующим образом:
nohup java -Xmx3550m -Xms3550m -Xmn2g -XX:SurvivorRatio=8 -Xss256k -XX:+UseG1GC -XX:MetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location=application.yaml > jshop.log 2>&1 $&