Что такое коэффициент распределения?

Такие фразы, как «неустойчивая скорость размещения» и «вам необходимо поддерживать низкий уровень распределения», по-видимому, относятся только к словарю Java Champions. Сложный, страшный и окруженный волшебной аурой.

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

Что такое коэффициент распределения и почему я должен заботиться?

Скорость выделения измеряется количеством памяти, выделенной на единицу времени. Часто это выражается в МБ / с, но вы можете использовать PB / в год, если хотите. Так что это все, что есть — никакой магии, только объем памяти, который вы выделяете в своем Java-коде, измеренный за определенный период времени.

Знание этого факта само по себе не слишком полезно. Если вы можете терпеть меня, я проведу вас через практическое использование концепции.

Столкновение с высокой скоростью выделения может привести к проблемам с производительностью вашего приложения. С практической точки зрения, воздействие мусора становится сборщиком мусора, ставшим узким местом. С аппаратной точки зрения даже обычное оборудование может поддерживать несколько ГБ / с выделенных ресурсов на ядро, поэтому, если ваши скорости не начинают превышать 1 ГБ / с / ядро, вам может быть довольно комфортно, что ваше оборудование на самом деле не станет узким местом.

Итак, сосредоточившись на GC, мы можем начать с аналогии, которая также верна в реальном мире — если вы создаете много вещей, вы, как правило, сталкиваетесь с большим количеством очистки после этого. Зная, что JVM построена с механизмом сбора мусора, необходимо выяснить, как скорость распределения изменяет частоту или продолжительность пауз GC.

Измерение уровня распределения

Давайте начнем с измерения уровня распределения. Для этого включим ведение журнала GC, указав -XX: + PrintGCDetails -XX: + PrintGCTimeStamps flags для JVM. JVM теперь начинает регистрировать паузы GC аналогично следующему фрагменту:

Из приведенного выше журнала GC мы можем рассчитать коэффициент распределения как разницу между размером молодого поколения после завершения последней коллекции и до начала следующей. Используя приведенный выше пример, мы можем, например, извлечь следующую информацию:

• Через 291 мс после запуска JVM было создано 33 280 тыс. Объектов. Первое небольшое событие GC очистило молодое поколение, после чего в молодом поколении осталось 5 088 тыс. Объектов.
• Через 446 мс после запуска, занятость Young gen выросла до 38368K, что привело к запуску следующего GC, что позволило снизить занятость Young Gen до 5120K .
• Через 829 мс после запуска размер Young gen составлял 71 680 К, и GC снова уменьшил его до 5120 КБ .

Эти данные затем могут быть выражены в следующей таблице для расчета коэффициента распределения как дельты занятости Юнга:

Наличие этой информации позволяет нам сказать, что этот конкретный фрагмент программного обеспечения имел скорость выделения 161 МБ / с в течение периода измерения.

Анализируя влияние

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

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

И действительно, при запуске одного и того же примера с разными размерами Eden с использованием параметров -XX: NewSize -XX: MaxNewSize & -XX: SurvivorRatio мы можем видеть двукратную разницу в скоростях распределения

• Выполнение приведенного выше примера с 100M Eden снижает скорость выделения до уровня ниже 100MB / sec
• Увеличение размера Eden до 1 ГБ увеличивает скорость выделения до чуть ниже 200 МБ / с.

Если вам все еще интересно, почему это может быть правдой — если вы реже останавливаете потоки приложений для GC, вы можете выполнять более полезную работу. Более полезная работа также происходит для создания большего количества объектов, таким образом поддерживая увеличенную скорость выделения .

Теперь, прежде чем вы сделаете вывод, что «чем больше Eden, тем лучше», вы должны заметить, что скорость выделения может и, возможно, не напрямую связана с фактической пропускной способностью вашего приложения. Это техническое измерение, способствующее пропускной способности. Скорость распределения может и будет влиять на то, как часто ваши второстепенные паузы в GC останавливают потоки приложений, но чтобы увидеть общее влияние, вам необходимо учитывать также большие паузы в GC и измерять пропускную способность не в МБ / с, а в бизнес-операциях вашего приложения. обеспечивает.