1
Mithril 307 天前 1
你看一下 log ,看看是不是冷启动了。Log 里面会有 Init Duration 。
不过就算你不停的 ping ,也不能保证它不会冷启动。如果那个可用区负载过高,你的 lambda 也可能被负载均衡搞出去,一样会冷启动。 如果你对这冷启动的时间很敏感,可以试试 Provisioned Concurrency 。或者干脆就用 EKS ,不要用 Lambda 。 |
2
Aygnh136 307 天前 1
就算你每秒都有请求,lambda 觉得自己需要扩容,或者超过最大持续时长了,都会开新的 lambda(需要冷起)
无论如何 15 分钟都会有一次冷启的 |
3
Aygnh136 307 天前 1
lambda 相当于执行你的代码之后,保留运行环境,并输出一个 handler(用于被调用),这个启动这个环境叫“冷启”。
当 lambda 被调起时,会分配一个 handler (没有可用的会新起一个)执行并返回结果。 它根据自己的设定(不同语言不同逻辑)来判断目前环境是否活跃,不活跃则释放。 lambda 保留的运行环境有最大时间限制(即使活跃也会被销毁),一般是 15 分钟。 我用的 node 至于 Python 的运行环境应该是同理。 |
4
lvhuiyang OP #1 @Mithril 非常感谢回复,看来我对 lambda 的冷启动理解有问题,查了下日志确实是大量 Init Duration
对冷启动时间倒是不是很敏感,敏感的是因为超时带来的请求错误。通过日志看冷启动时间不超过 1s ,业务处理逻辑应该在 200 ms 以内,因此设置了 5s 的超时时间应该是足够的。但是错误率确实和超时时间有关,我再定位一下吧,总之十分感谢提供的信息 日志查询 Init Duration: 错误率确实和允许时常有关 : |
6
BeautifulSoap 307 天前 1
lz 你的 Lambda 的负载难道只有 1rps ? 如果大于 1rps 你这做法当然会出现冷启动的问题
但再冷启动,11s 也太长了,Lambda 的冷启动时间撑死也就 2s~3s ,而 11s 的处理时间明显是程序内部哪里的问题,建议打 log 或者启用 xray 看看内部发生了什么 |
7
lvhuiyang OP #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 之后,原来的问题解决了。 |
8
BeautifulSoap 306 天前 1
@lvhuiyang 原来如此。其实不光是 ssm ,aws 的其他服务比如 dynamodb 之类通过 https 提供服务的都会出现可能性的超时。之前生产环境每几小时报错,查到后来发现是和 dynamodb 的通信超时了。
|