предисловие

Текст был включен в мой репозиторий GitHub, добро пожаловать, звезда:GitHub.com/bin39232820…
Лучшее время посадить дерево было десять лет назад, затем сейчас

Я знаю, что многие люди не играютqqДа, но с ностальгией, добро пожаловать в группу изучения Java для новичков Six Meridians Excalibur, номер группового чата:549684836Поощряйте всех вести блог на пути к технологиям

болтовня

предыдущая глава

• Механизм загрузки класса JVM от входа в JVM
• Структура файла класса JVM от входа в JVM
• JVM от входа в область данных времени выполнения JVM
• Стратегия выделения памяти JVM и сборщик мусора от входа в JVM
• Вопросы интервью JVM от входа в JVM

На самом деле, фронт — это всего лишь предзнаменование. Реальное грядет. Чтобы узнать, мул это или лошадь, нужно пройтись вокруг, поэтому давайте рассмотрим различные бизнес-сценарии и проанализируем конкретные предприятия для оптимизации.

Настройка JVM системы электронной коммерции с сотнями миллионов запросов в день

вводная информация

Наш фон - система электронной коммерции, Фактически, система электронной коммерции обычно делится на множество подсистем для независимого развертывания, таких как товарная система, система заказов, система деятельности, система статистики данных, система членства и т. Д.

Вот пример системы заказов

Сотни миллионов запросов в день, сколько у него будет активных пользователей

Как правило, каждый пользователь заходит в среднем 20 раз, поэтому в сотнях миллионов ежедневных активных действий около 500 Вт.

Затем продолжайте подсчитывать, сколько заказов можно разместить на DAU мощностью 500 Вт?

Если это 10%, вероятно, будет 50 Вт человек, размещающих заказы, тогда около 50 Вт заказов в день.

Если заказы по 50 Вт сосредоточены в пиковый период 4 часа, то в среднем всего несколько десятков заказов в секунду. новое поколение, чтобы получить память каждую секунду.Спустя долгое время, новое поколение будет полным, а затем выйдет память Minor GC, нет никакого давления

Но всплеск, большая рекламная сцена не такая

Если это Double 11, то за несколько минут будут сотни тысяч заказов, тогда количество заказов в секунду может исчисляться тысячами.

Требуется несколько машин, чтобы противостоять большому продвижению

В основном достаточно 3 машин, каждая машина размещает 300 заказов в секунду и развертывает 4 ядра и 8G.

Само по себе этого аппаратного ресурса хватает, чтобы выдержать 300 в секунду, что не является большой проблемой

Но проблема в том, что необходимо разумно распределять ограниченные ресурсы памяти JVM, чтобы уменьшить количество JVM GC, и стараться максимально избегать Full GC.

Модель использования памяти в системе больших рекламных заказов

В основном это оценивается при обработке заказов 300 в секунду, На самом деле, поскольку запросы интерфейса, связанные с размещением заказов, занимают много времени, обработка от 100 до 300 заказов в секунду примерно одинакова.

Тогда сущность my field каждого заказа вычисляется в соответствии с 1 КБ, и только на 300 заказов будет 300 КБ памяти.

Затем подсчитайте ряд других бизнес-объектов, которые имеют увеличение от 10 до 20 раз.

Кроме того, помимо размещения заказов, есть много других операций, связанных с заказами, например, запрос этих, мы расширим в 10 раз.

Тогда накладные расходы памяти 300 КБ * 20 * 10 = 60 МБ в секунду, эти накладные расходы памяти будут переработаны через 1 секунду, как показано на следующем рисунке.

Как распределяется память

Допустим у нас 4-ядерная 8G машина, тогда JVM вообще 4G, а остальное использует операционная система.Мы можем отдать 3G на heap memory, 1.5G на новое поколение и 1.5G на старое поколение.

Тогда стек виртуальной машины Java для каждого потока равен 1M, тогда, если JVM имеет сотни потоков, это, вероятно, сотни M

Потом бессмертное поколение дает 256 памяти, в принципе 4G почти тоже самое

На данный момент схематическая диаграмма JVM выглядит следующим образом.

Далее, очень ясно, что система заказов имеет около 300 заказов в секунду, и все они занимают 60 МБ памяти в новом поколении, поэтому новое поколение будет заполнено примерно через 25 секунд, как показано ниже.

Незначительная сборка мусора будет выполнена через 25 секунд. В это время из-за опции -XX:HandlePromotionFailure вы можете подумать, что проверка, которую необходимо выполнить, в основном заключается в сравнении размера свободного пространства старого поколения и среднего размера объекты, поступающие в старое поколение после минорного ГК предыдущих поколений.Поначалу я был уверен, что проверка пройдена.
Таким образом, Minor GC запускается напрямую, и 99% объектов нового поколения могут быть восстановлены сразу, поскольку большинство заказов уже обработано, за исключением запроса заказа в последнюю секунду, поэтому объекты, которые могут уцелеть в это время, 100 МБ.

Но вот проблема: если параметр -XX:SuruvivorRatio по умолчанию равен 8, то Eden занимает около 1,2 ГБ памяти, а каждый Survivor занимает 150 МБ, как показано ниже.

Затем снова запустите его на 20 секунд, временно заполните область Eden и снова соберите объекты в Eden и S1.Выжившие объекты могут иметь размер около 100 МБ и войдут в S2, как показано ниже.

На данный момент параметры JVM следующие

Одна из оптимизаций сборки мусора нового поколения: достаточно ли места в Survivor?

Прежде всего, при оптимизации JVM первый вопрос, который необходимо рассмотреть, — достаточно ли вашего Survivor нового поколения по оценке.

По вышеизложенной логике, во-первых, сборка мусора нового поколения составляет каждый раз 100 МБ, а может и превышать 150 МБ.Так часто ли Minor GC не может быть помещен в Survivor, поэтому он будет часто заходить в старый поколение?

Кроме того, даже если объект после Minor GC меньше 150 МБ, даже если объект размером 100 МБ входит в область Survivor, поскольку это группа объектов одного возраста, которая непосредственно превышает 50% пространства, это также может вызвать объект для входа в зону Survivor Старость

Так согласно этой модели, пространство в устойчивости явно недостаточно

На самом деле, предложение здесь состоит в том, чтобы настроить новое поколение на 2G, а старое поколение на 1G, тогда Eden в настоящее время составляет 1,6G, а каждый Survivor - 200 МБ, как показано ниже.

В это время область Выжившего становится больше, что значительно снижает проблему, связанную с тем, что уцелевшие объекты нельзя положить в Выживший после GC нового поколения, или ситуацию, когда объекты одного возраста превышают 50%

Это значительно снижает вероятность того, что новое поколение войдет в старое поколение.

На данный момент параметры JVM следующие:

На самом деле, для любой системы, в первую очередь, аналогичную приведенной выше модели использования памяти и разумного распределения памяти, старайтесь сохранять объекты после каждого Minor GC в Survivor, не входить в старость, это первое место вам нужно оптимизировать

Сколько раз объект нового поколения избегает сборки мусора и попадает в старое поколение

Все мы знаем, что объект, избежавший 15 последовательных сборок мусора, автоматически устаревает.

На самом деле, согласно приведенной выше модели работы с памятью, Minor GC в основном запускается раз в 20 секунд, то есть объект перейдет в старое поколение, если он не был восстановлен в новом поколении в течение нескольких минут.

Кто-то написал в блоге, что параметр нужно ставить выше 20 30, на самом деле это утверждение неверно

Поскольку ваше рассмотрение этого параметра должно сочетаться с операционной моделью системы, если 15 GC избегаются в течение нескольких минут, если объект не перерабатывается в течение нескольких минут, это должна быть аннотация, такая как @Service в системе.

Поэтому тот, кто думает над проблемой, должен не следовать чужому мнению, а должен совмещать принципы работы, делать выводы и думать самостоятельно, а разные бизнес-системы все-таки разные.

На самом деле можно и соответствующим образом уменьшить значение этого параметра, например, в 5 раз, то есть объект может избегать 5 Minor GC, а если в новом поколении он превышает 1 минуту, то пусть входит в старое поколение как как можно скорее,и не использовать новое поколение.Занимает память

Короче говоря, этот параметр необходимо рассматривать в сочетании с конкретной операционной моделью вашей системы.В настоящее время параметры JVM следующие

Насколько велик объект непосредственно в старческом?

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

Например, некоторые данные могут кэшироваться в JVM, что обычно определяется тем, создаются ли в системе большие объекты.

Но в целом ему достаточно поставить 1Мб, потому что крупных объектов больше 1Мб очень мало.Если есть, то может быть он заранее выделен вами, типа большого Листа.

На данный момент параметры JVM следующие:

Укажите сборщик мусора

При этом не забудьте указать сборщик мусора.В новом поколении используется ParNew, а в старом поколении CMS.Следующие параметры JVM:

Суммировать

На самом деле, прочитав этот кейс, вы можете напрямую задать параметры JVM вашей собственной системы, увидеть размер вашего нового поколения, размер старого поколения, размер Eden и Survivor, а затем оценить операционную модель вашей системы.

• Сколько памяти он занимает в секунду?
• Как часто запускать Minor GC
• Сколько уцелевших объектов осталось после Minor GC
• Выживший подойдет?
• Будет ли объект часто стареть из-за того, что Выживший не может его отложить?
• Войдет ли он в старость из-за правил динамического суждения о возрасте?

конец

JVM Combat 1, это самая базовая настройка, вся настройка JVM основана на бизнес-оценках.

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

ежедневные комплименты

Хорошо всем, вышеизложенное является полным содержанием этой статьи. Люди, которые могут видеть это здесь, всенастоящий порошок.

Творить нелегко. Ваша поддержка и признание — самая большая мотивация для моего творчества. Увидимся в следующей статье.

Six Meridians Excalibur | Text [Original] Если в этом блоге есть какие-то ошибки, прошу покритиковать и посоветовать, буду очень признателен!