aws-lambda - 对于 AWS Cloudwatch 中的 Lambda，overProvisioned Memory 意味着什么？

Question

我正在尝试了解有关在我的无服务器环境中监视和分析 lamda 函数的更多信息，以了解如何指出需要注意的“可疑”lambda。我在 Logs Insights 部分中运行了一些示例查询，并且我有一些具有此结果的 lambda。

我基本上是想了解这是否需要快速修复，或者如果有这么多的过度配置内存，这是否没什么大不了的？

我应该比这个指标更担心持续时间/并发问题吗？

标签： aws-lambdaamazon-cloudwatch

Answer 1

TLDR：过度配置的内存和持续时间会影响计费成本。在可能的情况下，这两个参数都可以控制为具有成本效益的值。

分配的内存以及每月执行 lambda 的持续时间和次数用于计算当月的计费成本。^[1]

目前，lambda 在最大负载下使用了大约 14% 的预置内存，剩余部分可以使用。

如果您要处理大量请求，则减少过度配置的内存和持续时间可能具有成本效益。

我的建议是提供内存sum of max load plus (50% - 75%) of max load并查看持续时间。

并发不计入每月计费成本。
一些数字：^[2]

• Default concurrency limit for functions = 100
• Hard set concurrency limit for account = 1000

减少持续时间意味着您可以一次处理更多请求。当向 AWS Support 提出请求时，可以提高每个账户的并发限制。

并发问题的另一个典型解决方法是使用队列限制请求。这可能成本更高。

1. 接收请求的 lambda 创建一个新的 SNS 主题，将其与请求一起封装，将其推送到消息队列并返回调用者该主题。
2. 调用者接收并订阅主题。
3. 另一个 lambda 处理队列并将作业的状态报告给主题。
4. 来电者收到消息。

主题数量的帐户限制设置为 100,000 ^[3]。
可以通过向 AWS Support 提出请求来增加此限制。尽管清理不再需要保留的主题可能更合适。

必须通过这种解决方法来设计并发限制可能意味着应用程序要求更适合由长期运行的服务器支持的传统 Web 应用程序。