【问题标题】:AWS lambda duration spike (nothing to do with cold start)AWS lambda 持续时间峰值(与冷启动无关)
【发布时间】:2020-06-06 11:49:05
【问题描述】:

我有几个 AWS Lambda 函数,但故障排除只针对其中一个。这个 Lambda 函数由消息队列触发,读取 DynamoDB,处理,写入 DynamoDB。它每秒最多调用 10 个请求,并且我设置了 Lambda 配置并发。平均 Lambda 持续时间是 60 毫秒,我对此非常满意。但是每天大约有 10 个 Lambda 函数持续时间超过 1 秒到 3 秒超时的实例。

我在我的 Lambda 中输入日志,在持续时间高峰期间,读/写 (getitem/putitem) DynamoDB 耗时超过 1 秒。 Dynamodb 设置为按需。这是一个非常简单的表,两列,ID(自动编号)和一个 json 字符串(大约 1KB)。我已经尝试过 Redis,但很奇怪,仍然有尖峰。 Lambda 没有放在 VPC 中。 Dynamo 连接已设置为 http 超时 500,最大重试次数为 2。

读取 DynamodDB 的代码

日志持续时间

【问题讨论】:

  • 作为测试,如果将 Lambda 函数的 RAM 大小增加到最大,这个问题会消失吗?
  • 不完全。随着 RAM 大小的增加,我可以看到平均持续时间下降。但是尖峰仍然存在,尽管不确定频率是否下降。谢谢。

标签: amazon-web-services aws-lambda duration


【解决方案1】:

当使用预置并发时,Lambda 服务将保持一定数量的底层容器“温暖”,以最大限度地减少启动时间。由于您提到您间歇性地面临更长的执行时间,请参考以下您可以执行的调试步骤:

  • 对照“持续时间”指标检查 Lambda 函数的“并发执行”指标:如果在特定时间执行的函数实例数高于设置的预置并发性,则意味着这些实例中的少数实例冷启动导致持续时间较长。

  • 启用X-Ray tracing for the Lambda function 并添加X-ray instrumentation to your code:这将全面了解哪个网络调用占用了太多时间,并为您提供冷启动“init”持续时间(如果有)。

【讨论】:

  • 我了解代码/热启动。但这不是我的原因。我已经配置了并发设置。同样从附加的代码中,您可以看到,我记录了我的 lambda 启动时的开始时间,然后记录了每个步骤所花费的每个持续时间。谢谢。
  • 好的,所以您已经选择了仅 DDB getItem 的响应时间。既然您提到一天中只有大约 10 个实例出现峰值,我倾向于这主要是与网络相关的简单延迟。但是,请查看 CloudWatch 上的 DDB 指标以了解 GetItem 操作(最大值)。如果这接近 1 秒标记,那么您就是罪魁祸首,否则剩下的就是网络延迟。
猜你喜欢
  • 2020-05-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-04-14
  • 2016-09-22
  • 2021-11-06
  • 2022-10-04
  • 2019-11-21
相关资源
最近更新 更多