为何容器化AWS Lambda内存未满载且执行耗时更长？

测试背景 #

我们正在测试两个代码完全一致的AWS Lambda函数的运行时长：一个以脚本形式部署，另一个以容器镜像形式部署，目的是验证两者是否存在显著的运行时长差异。该Lambda的核心功能为从AWS SQL数据库中读取550000条数据。

Lambda业务代码 #

//import * as AWS from 'aws-sdk';
const Knex = require('knex');
//AWS.config.update({ region: 'us-east-1' });

const host = //hidden;
const user = //hidden;
const password=//hidden;
const database=//hidden;

const connection = {
  ssl: { rejectUnauthorized: false },
  host,
  user,
  password,
  database,
};

// create a connection
const knex = Knex({
  client:'mysql',
  connection,
});

exports.handler = async () => {
  try {
    var limit = 550000
    const res=await knex('ALM_AGGR_LQ_201231_210111_0600_A048_V3_75_GAI').select().limit(limit);
    console.log("RETRIEVING: " + limit);
    
    const response = {
            statusCode: 200,
            //body: JSON.stringify(res),
        };
        return response;
   }catch(err){
    console.error(err);
  }
};

配置与观测现象 #

我们已将两个版本的Lambda内存均配置为10240MB，但观测到以下差异：

• 非容器化Lambda：内存使用接近配置的10240MB，执行耗时76秒
• 容器化Lambda：仅使用10097MB内存，执行耗时83秒

疑问与解答 #

1. 为何容器化Lambda内存使用未达配置的10240MB？ #

容器化Lambda的内存显示值与配置值的微小偏差属于正常现象，原因是容器运行时本身会占用一部分内存资源。Lambda为容器版分配的总内存确实是10240MB，但容器运行环境（包括容器runtime、基础镜像中的系统进程等）会消耗约143MB的内存，因此留给业务代码的可用内存为10240-143=10097MB，这并非配置未生效。

2. 内存未充分利用是否是容器版耗时更长的原因？ #

内存剩余的143MB差距不足以导致7秒的耗时差，因此这并非直接原因。更可能的影响因素包括：

• 容器运行时额外开销：容器版Lambda的启动流程（冷启动/热启动）比原生脚本版更复杂，需要拉取镜像、初始化容器环境，即使热启动，容器runtime的初始化步骤也可能比原生Lambda runtime多，导致整体耗时增加。
• 网络与数据库连接差异：容器环境的网络配置、DNS解析或SSL握手流程可能与原生Lambda runtime存在细微差异，导致数据库连接或数据读取的延迟累积。
• 基础镜像性能冗余：如果使用的容器基础镜像包含不必要的依赖或后台进程，会占用额外的CPU、IO资源，间接影响数据读取效率。

建议排查方向 #

• 分别测试两个版本的冷启动与热启动耗时，确认差异是否来自冷启动阶段；
• 更换轻量化的容器基础镜像（如使用Alpine替代Debian/Ubuntu），减少运行时开销；
• 在代码中添加数据库连接、数据读取各阶段的耗时日志，定位具体的耗时差异点。

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