導入

シリーズの前の部分では、SnapStart を有効にしない場合と SnapStart を有効にした場合の Java 21 ランタイムで Lambda 関数のコールド スタートを測定し、さまざまな Lambda メモリ設定、Lambda デプロイメント アーティファクト サイズ、Java を使用した DynamoDB 呼び出しプライミングの最適化も適用しました。コンパイル オプション、(a) 同期 HTTP クライアント、およびさまざまな Lambda レイヤーの使用。 これらすべての測定では、デフォルトのガベージ コレクション アルゴリズム G1.

この記事では、Java 21 ランタイムでの Lambda 関数のパフォーマンスに対する Java ガベージ コレクション アルゴリズムの影響について調べていきたいと思います。また、すべてのガベージ コレクション アルゴリズムで使用されている同じマイナー Java 21 バージョンと同等の結果が得られるように、G1 のすべてを再測定します。

Java ガベージ コレクション アルゴリズム

測定では、次の Java 収集アルゴリズムをデフォルト設定で使用します (各アルゴリズムの詳細については、リンク先のドキュメントを参照してください):

• Garbage-First (G1) ガベージ コレクター。これは、デフォルトで使用されるガベージ コレクション アルゴリズムです。 JAVA_TOOL_OPTIONS 環境変数に -XX: UseG1GC を追加することで、AWS SAM テンプレートで明示的に設定できます。
• パラレルコレクター。 JAVA_TOOL_OPTIONS 環境変数に -XX: UseParallelGC を追加することで、AWS SAM テンプレートで明示的に設定できます。
• シェナンドーGC。 Oracle JDK はこれを提供しませんが、Amazon Corretto 21 JDK は提供します。 JAVA_TOOL_OPTIONS 環境変数に -XX: UseShenandoahGC を追加することで、AWS SAM テンプレートで明示的に設定できます。
• Zガベージコレクター。 ZGC アルゴリズムには、デフォルトと新しい 1 世代の 2 つの異なるアルゴリズムがあります。 -XX: UseZGC または -XX: UseZGC -XX: ZGenerational を JAVA_TOOL_OPTIONS 環境変数に追加することで、AWS SAM テンプレートで明示的に設定できます。

さまざまなガベージ コレクション アルゴリズムを使用した Java 21 でのコールド スタートとウォーム スタートの測定

私たちの実験では、パート 9 で紹介したわずかに変更されたアプリケーションを使用します。アプリケーション コードはここで見つけることができます。基本的に 2 つの Lambda 関数があり、どちらも API ゲートウェイ リクエストに応答し、API ゲートウェイから受け取った ID によって DynamoDB から製品を取得します。 1 つの Lambda 関数 GetProductByIdWithPureJava21LambdaWithGCAlg は SnapStart の有無にかかわらず使用でき、2 番目の GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg は SnapStart と DynamoDB リクエスト呼び出しプライミングを使用します。

以下の実験の結果は、約 1 時間実行された実験で 100 回を超えるコールド スタートと約 100,000 回のウォーム スタートを再現したことに基づいています。そのために (および前回の記事の実験で) 負荷テスト ツールを使用しましたが、Serverless-artillery や Postman など、好きなツールを使用できます。 Lambda 関数に 1024 MB のメモリを与え、JAVA_TOOL_OPTIONS: "-XX: TieredCompilation -XX:TieredStopAtLevel=1" (プロファイリングなしの Java クライアント コンパイル) を使用して実験を実行します。これは、コールド スタート時間とウォーム スタート時間の間に非常に良いトレードオフがあります。

残念ながら、Z ガベージ コレクター (デフォルトと世代の両方を使用) で Lambda 関数を開始できず、エラーが発生しました:

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 MB、さらにそれ以上の MB に設定してみましたが、やはり同じエラーが発生しました。

他の 3 つのガベージ コレクション アルゴリズムを使用した測定結果を見てみましょう。

略語 c はコールド スタート、w はウォーム スタートを表します。

SnapStart が有効になっていない場合のコールド (c) およびウォーム (w) のスタート時間 (ms:

プライミングなしでスナップスタートを有効にした場合のコールド (c) およびウォーム (w) スタート時間 (ミリ秒):

SnapStart を有効にし、DynamoDB 呼び出しプライミングを使用した場合のコールド (c) およびウォーム (w) の開始時間 (ms:

結論

この記事では、Java 21 ランタイムでの Lambda 関数のパフォーマンスに対する Java ガベージ コレクション アルゴリズム (G1、Parallel Collector、および Shenandoah) の影響を調査しました。これらのアルゴリズムのパフォーマンスにはかなりの違いがあることがわかりました。 G1 (デフォルト) でデフォルト設定を使用すると、(場合によっては断然) コールド スタート時間とウォーム スタート時間が最も短くなります。 DynamoDB リクエストのプライミングで SnapStart を使用すると、パフォーマンス結果は予想通り相互にかなり近くなります。

各ガベージ コレクション アルゴリズムのドキュメントを参照して、ミックスや最大メモリなどの設定を調整してパフォーマンスを大幅に向上させたり、独自の測定を行ったりしてください。