Quarkus AWS Lambda原生镜像冷启动初始化耗时过长求助

我基于quarkus-amazon-lambda:3.12.0构建了AWS Lambda原生镜像函数，函数无复杂业务逻辑，执行速度达标，但冷启动初始化阶段耗时超出预期。Quarkus日志显示自身初始化仅约80毫秒，但Lambda执行报告的Init Duration却达到278.70毫秒，非冷启动执行则符合预期的快速。

日志信息 #

冷启动日志（含Quarkus初始化日志） #

2024-07-25 09:56:30,969 INFO  [io.quarkus] (main) my-function 0.1-SNAPSHOT native (powered by Quarkus 3.12.0) started in 0.085s. 
2024-07-25 09:56:30,970 INFO  [io.quarkus] (main) Profile prod activated. 
2024-07-25 09:56:30,970 INFO  [io.quarkus] (main) Installed features: [amazon-lambda, cdi]
START RequestId: <uid> Version: $LATEST
END RequestId: <uid>
REPORT RequestId: <uid> Duration: 73.61 ms  Billed Duration: 353 ms Memory Size: 512 MB Max Memory Used: 51 MB  Init Duration: 278.70 ms    

非冷启动日志 #

START RequestId: <uid> Version: $LATEST
END RequestId: <uid>
REPORT RequestId: <uid> Duration: 1.45 ms   Billed Duration: 2 ms   Memory Size: 512 MB Max Memory Used: 52 MB  

配置信息 #

• Quarkus 3.12.0，使用aws-lambda和cdi组件
• GraalVM原生镜像
• Lambda内存配置为512MB

耗时差异的核心原因 #

Lambda的Init Duration包含三个Quarkus日志未覆盖的阶段：

1. 容器启动阶段：AWS为Lambda分配、启动容器的系统级耗时
2. Runtime初始化阶段：Lambda运行时加载原生镜像二进制文件、完成系统层面初始化的时间
3. 应用初始化阶段：Quarkus自身启动逻辑（即日志中显示的80毫秒）

两者的耗时差，正是来自容器启动和Runtime初始化这两部分。

优化方案 #

1. 调整Lambda内存配置 #

Lambda的CPU、网络带宽与内存配置正相关，提升内存（如至1024MB）会分配更多CPU资源，加速二进制文件加载和容器初始化，通常能显著降低Init Duration。虽然内存成本上升，但冷启动效率提升可抵消部分成本。

2. 优化GraalVM原生镜像构建 #

• 添加quarkus.native.additional-build-args=--initialize-at-build-time参数，将可提前初始化的类在构建阶段完成，减少运行时工作量（注意避开依赖运行时环境的类）
• 启用quarkus.native.enable-reports生成镜像分析报告，定位耗时初始化路径进行针对性优化
• 升级至最新版GraalVM（如22.3+），新版本对Lambda冷启动场景有专门优化

3. 精简Quarkus依赖 #

执行quarkus.dependency-tree命令查看依赖树，移除不必要的隐性依赖，减少镜像体积和初始化负载。

4. 启用Lambda SnapStart #

Quarkus 3.x已支持原生镜像的SnapStart功能，AWS会预先初始化函数并创建快照，冷启动时直接恢复快照，大幅压缩Init Duration。

5. 调整部署配置 #

• 使用更精简的基础镜像：尝试基于scratch的镜像替代默认distroless镜像，减少容器启动时的资源加载
• 配置预留并发：若对冷启动有严格要求，预留并发可保持函数实例预热，彻底消除冷启动耗时，但成本较高

内容的提问来源于stack exchange，提问作者sys463