Введение

В предыдущих частях нашей серии мы измерили холодный запуск функции Lambda во время выполнения Java 21 без включенного SnapStart, с включенным SnapStart, а также применили оптимизацию первичного вызова DynamoDB с различными настройками памяти Lambda, размерами артефактов развертывания Lambda, Java параметры компиляции, (а) синхронные HTTP-клиенты и использование различных слоев Lambda. Для всех этих измерений мы использовали алгоритмы сборки мусора по умолчанию G1.

В этой статье мы хотели бы изучить влияние алгоритмов сборки мусора Java на производительность функции Lambda во время выполнения Java 21. Мы также переизмерим все, чтобы G1 имел сопоставимые результаты с той же второстепенной версией Java 21, используемой для всех алгоритмов сборки мусора.

Алгоритмы сборки мусора Java

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

• Сборщик мусора «Garbage-First» (G1). Это алгоритм сборки мусора, используемый по умолчанию. Вы можете задать его явно в шаблоне AWS SAM, добавив -XX: UseG1GC в переменную среды JAVA_TOOL_OPTIONS.
• Параллельный коллектор. Вы можете установить его явно в шаблоне AWS SAM, добавив -XX: UseParallelGC к переменной среды JAVA_TOOL_OPTIONS.
• Шенандоа GC. Oracle JDK не предоставляет этого, но Amazon Corretto 21 JDK предоставляет. Вы можете установить его явно в шаблоне AWS SAM, добавив -XX: UseShenandoahGC в переменную среды JAVA_TOOL_OPTIONS.
• Сборщик мусора Z. Существует 2 разных алгоритма ZGC: по умолчанию и более новый, относящийся к одному поколению. Вы можете задать его явно в шаблоне AWS SAM, добавив -XX: UseZGC или -XX: UseZGC -XX: ZGeneration к переменной среды JAVA_TOOL_OPTIONS.

Измерение холодных и теплых запусков с помощью Java 21 с использованием различных алгоритмов сборки мусора

В нашем эксперименте мы будем использовать слегка модифицированное приложение, представленное в части 9. Код приложения можно найти здесь. По сути, существует две функции Lambda, которые отвечают на запросы API-шлюза и извлекают продукт по идентификатору, полученному от API-шлюза из DynamoDB. Одну лямбда-функцию GetProductByIdWithPureJava21LambdaWithGCAlg можно использовать со SnapStart и без него, а вторая GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg использует инициализацию вызова SnapStart и DynamoDB.

Результаты эксперимента, приведенного ниже, были основаны на воспроизведении более 100 холодных и примерно 100 000 теплых запусков в ходе эксперимента, который длился примерно 1 час. Для этого (и экспериментов из моей предыдущей статьи) я использовал инструмент нагрузочного тестирования, но вы можете использовать любой инструмент, который захотите, например Serverless-artillery или Postman. Мы проводим эксперименты, предоставляя функциям Lambda 1024 МБ памяти и используя JAVA_TOOL_OPTIONS: "-XX: TieredCompilation -XX:TieredStopAtLevel=1" (компиляция Java-клиента без профилирования), что обеспечивает очень хороший компромисс между холодным и теплым временем запуска.

К сожалению, мне не удалось запустить функцию Lambda, когда сборщик мусора Z (как по умолчанию, так и по поколению) столкнулся с ошибкой:

Failed to commit memory (Operation not permitted)
[error][gc] Forced to lower max Java heap size from 872M(100%) to 0M(0%)
[error][gc] Failed to allocate initial Java heap (512M)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Он пробовал установить больший объем памяти: 1024, 2048 МБ и даже больше МБ, но ошибка все равно появлялась.

Давайте посмотрим на результаты наших измерений с помощью трех других алгоритмов сборки мусора.

Аббревиатура c означает холодный старт, а w означает теплый старт.

Время холодного (c) и теплого (w) запуска без включения SnapStart в мс:

Время холодного (c) и теплого (w) старта с включенным SnapStart без заполнения в мс:

Время холодного (c) и теплого (w) запуска с включенным SnapStart и запуском DynamoDB в мс:

Заключение

В этой статье мы исследовали влияние алгоритмов сборки мусора Java (G1, Parallel Collector и Shenandoah) на производительность функции Lambda во время выполнения Java 21. Мы увидели значительную разницу в производительности этих алгоритмов. Используя настройки по умолчанию с G1 (по умолчанию), мы получаем (иногда намного) наименьшее время холодного и теплого запуска. При использовании SnapStart с отправкой запроса DynamoDB результаты производительности, как и ожидалось, намного ближе друг к другу.

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