AWS Lambda中CPU性能间歇性突降的原因排查

背景信息 #

Lambda函数代码 #

import time
import pickle
import gc

def ms_now():
    return int(time.time_ns() / 1000000)

class Timer():
    def __init__(self):
        self.start = ms_now()

    def stop(self):
        return ms_now() - self.start

with open('model_embeddings.pkl', 'rb') as file:
    model_embeddings = pickle.load(file)

def get_embeddings(texts):
    timer = Timer()
    embeddings = model_embeddings.encode(texts)   # 关注的代码行
    print(f"Time: {timer.stop()}ms")
    return embeddings

def lambda_handler(event, _):
    gc.disable()                                  # 禁用垃圾回收
    result = get_embeddings(event['texts']).tolist()
    return {
        'statusCode': 200,
        'headers': {
            'Content-Type': 'application/json'
        },
        'result': result[0][0], 
    }

部署与运行情况 #

• 以镜像方式部署，分配10240 MB内存，实际仅使用800 MB
• 核心逻辑是调用HuggingFace Sentence Transformer的encode方法生成文本嵌入，属于CPU密集型操作
• 重复调用时，encode方法耗时通常约350ms，但偶尔骤升至2100ms，已排除冷启动、垃圾回收影响，本地WSL环境无此问题
• 额外现象：
  1. 返回完整result而非result[0][0]时，函数执行变慢
  2. 先传入短输入预热后，性能突降现象消失

现象原因分析 #

1. 间歇性性能突降（350ms→2100ms） #

Lambda的CPU资源分配和内存配置直接挂钩：内存越高，分配的CPU核心数越多（10240MB内存对应接近满配的vCPU核心数）。但Lambda的云端执行环境存在CPU资源动态节流/调度波动——当函数实例长时间空闲，或云端调度系统资源紧张时，即使内存配置拉满，实际可用的CPU核心数会被临时限制，导致CPU密集型的encode操作只能靠少量核心运行，耗时直接暴增。

本地WSL环境是独占本地CPU资源，不存在云端的动态调度限制，因此不会出现这类波动。

2. 返回完整result导致变慢 #

完整的result是高维度的嵌入向量数组，将其转为list并序列化为JSON返回时，会触发大量内存拷贝和序列化运算，这部分额外的CPU开销会叠加在核心的encode耗时上，整体执行时间自然变长。而返回result[0][0]只是单个数值，序列化和内存操作的开销可以忽略不计。

3. 短输入预热后性能突降消失 #

短输入的encode操作会“激活”Lambda执行环境的CPU资源——云端调度系统会为该函数实例分配足额的CPU核心，后续执行正常输入的encode时，实例能持续保持高CPU资源的活跃状态，跳过了调度系统的资源调整延迟，也就不会出现性能突降。

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