AWS Lambda function 间接性超时

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 311 天前的主题，其中的信息可能已经有所发展或是发生改变。

使用 Python + sqlalchemy 容器化部署在 AWS 一个 lambda 函数，来实现某些特殊存储业务的服务，用于提供给 Web Server 后端来调用。

背景：目前部署在测试环境，因为测试环境流量不大，考虑到在一段时间没有调用 lambda 的时候可能会导致 “休眠”，于是添加一个 Amazon EventBridge 的 schedule 来每分钟调用一次 lambda 函数，同时在业务中也实现了一个 celery 定时任务每分钟调用一次。

但是发现了一个奇怪的现象，在 lambda 函数没有做任何改动的前提下，调用会接歇性的超时。如果某段时间 100% 超时的话，我认为是 lambda 函数休眠了，需要冷启动花费时间。但是现状是每分钟都有请求保证其“不休眠”，而且并非请求 100% 超时，在某几分钟内有的请求超时，有的是正常的。统计图如下

有没有比较懂的老哥解答一下，十分感谢 ~

lambda

调用

函数

休眠

8 条回复 • 2024-01-03 19:13:04 +08:00

Mithril

311 天前

你看一下 log ，看看是不是冷启动了。Log 里面会有 Init Duration 。
不过就算你不停的 ping ，也不能保证它不会冷启动。如果那个可用区负载过高，你的 lambda 也可能被负载均衡搞出去，一样会冷启动。

如果你对这冷启动的时间很敏感，可以试试 Provisioned Concurrency 。或者干脆就用 EKS ，不要用 Lambda 。

Aygnh136

311 天前

就算你每秒都有请求，lambda 觉得自己需要扩容，或者超过最大持续时长了，都会开新的 lambda(需要冷起)
无论如何 15 分钟都会有一次冷启的

Aygnh136

311 天前

lambda 相当于执行你的代码之后，保留运行环境，并输出一个 handler(用于被调用)，这个启动这个环境叫“冷启”。
当 lambda 被调起时，会分配一个 handler （没有可用的会新起一个）执行并返回结果。
它根据自己的设定(不同语言不同逻辑)来判断目前环境是否活跃，不活跃则释放。
lambda 保留的运行环境有最大时间限制(即使活跃也会被销毁)，一般是 15 分钟。
我用的 node 至于 Python 的运行环境应该是同理。

lvhuiyang

311 天前

#1 @Mithril 非常感谢回复，看来我对 lambda 的冷启动理解有问题，查了下日志确实是大量 Init Duration

对冷启动时间倒是不是很敏感，敏感的是因为超时带来的请求错误。通过日志看冷启动时间不超过 1s ，业务处理逻辑应该在 200 ms 以内，因此设置了 5s 的超时时间应该是足够的。但是错误率确实和超时时间有关，我再定位一下吧，总之十分感谢提供的信息

日志查询 Init Duration：

错误率确实和允许时常有关：

lvhuiyang

311 天前

#2 #3 @Aygnh136

明白了，我对 lambda 的理解确实有问题，我再去了解一下，十分感谢回复

BeautifulSoap

311 天前

lz 你的 Lambda 的负载难道只有 1rps ？如果大于 1rps 你这做法当然会出现冷启动的问题

但再冷启动，11s 也太长了，Lambda 的冷启动时间撑死也就 2s~3s ，而 11s 的处理时间明显是程序内部哪里的问题，建议打 log 或者启用 xray 看看内部发生了什么

lvhuiyang

310 天前

#6 @BeautifulSoap 十分感谢回复，经过排查确实是我的程序内部逻辑问题：在 lambda 内部使用 sdk 调用 secretsmanager client 的 get_secret_value 时候默认未设置超时时间，导致有一定概率会卡住：

```python
session = boto3.session.Session()
client = session.client(
service_name="secretsmanager",
region_name=REGION_NAME,
config=aws_client_config,
)
response = client.get_secret_value(SecretId=db_secret_id)
```

虽然还不清楚在 lambda 内部使用 sdk 调用 secretsmanager client 会啥可能卡住，目前换了其他的方式来避免调用 secretsmanager client 之后，原来的问题解决了。

BeautifulSoap

310 天前

@lvhuiyang 原来如此。其实不光是 ssm ，aws 的其他服务比如 dynamodb 之类通过 https 提供服务的都会出现可能性的超时。之前生产环境每几小时报错，查到后来发现是和 dynamodb 的通信超时了。